Transport Layer Security

W 1994 roku przedsiębiorstwo Netscape stworzyło protokół służący do bezpiecznej transmisji zaszyfrowanego strumienia danych, nazwany SSL (Secure Socket Layer), a już rok później pojawiła się trzecia jego wersja. W 1996 roku Internet Engineering Task Force powołało grupę roboczą pod nazwą Transport Layer Security, której zadaniem było rozwijanie protokołu SSL. W 1999 roku został opublikowany standard TLS 1.0, który jest czasem określany jako SSL 3.1. Całość działa w architekturze klient-serwer, pozwalając na nawiązanie bezpiecznego połączenia z użyciem certyfikatów. Architektura jest zorientowana głównie na uwierzytelnianie serwera (np. sklepu internetowego, do którego klient wysyła numer karty kredytowej i chce mieć pewność co do odbiorcy), ale przewiduje również możliwość uwierzytelniania klienta.

Z powodu ograniczeń w eksporcie technologii kryptograficznych ze Stanów Zjednoczonych, większość implementacji protokołu SSL nie mogła wykorzystywać kluczy symetrycznych dłuższych niż 40 bitów. Dzięki temu rządowe agencje bezpieczeństwa dysponujące odpowiednio dużą mocą obliczeniową (m.in. NSA) były w stanie złamać szyfr metodą brute-force. Po kilku latach publicznej debaty, lepszemu poznaniu dłuższych kluczy przez zainteresowane strony oraz kilku sprawach sądowych, rząd złagodził swoje stanowisko wobec stosowania dłuższych kluczy. Obecnie 40-bitowe klucze wyszły z użycia i zostały zastąpione przez zapewniające wyższe bezpieczeństwo klucze o długości 128 i więcej bitów.

W 2009 w protokole SSL odkryto podatność na atak w procesie renegocjacji sesji. Błąd umożliwiał wysłanie danych do serwera przed użytkownikiem bez jego wiedzy (zobacz: Atak man in the middle)^[2][3]. W związku z tym, że podatność dotyczyła protokołu, a nie jednej implementacji, jedyną metodą jej obejścia było wyłączenie możliwości renegocjacji w ogóle. Równocześnie zaproponowana została poprawka do specyfikacji protokołu w postaci rozszerzenia^[4].

• SSL 1 – wersja miała poważną dziurę w bezpieczeństwie. Procedury uzgadniania szyfru nie były zabezpieczone, więc atakujący mógł wymusić używanie najsłabszego szyfru obsługiwanego przez komunikujących się, ze złamaniem którego mógł sobie poradzić znacznie łatwiej niż z szyfrem, który strony wybrałyby normalnie.
• SSL 2 – wersja zmienia procedurę negocjacyjną.
• SSL 3 – popularna wersja, obecnie wypierana przez TLS 1.0.
• TLS 1.0 – rozwinięcie SSL 3 opisane w RFC 2246 ↓.
• TLS 1.1 – opisana w RFC 4346 ↓. Wyjaśnia ona pewne niejednoznaczności i dodaje nowe zalecenia wynikające z praktyki użycia – opisano to w RFC 4366 ↓, RFC 4680 ↓ i RFC 4681 ↓.
• TLS 1.2 – opisana w RFC 5246 ↓ i oparta o wcześniejszą wersję, czyli TLS 1.1.
• TLS 1.3 – zaproponowana w dokumencie IETF z 21 marca 2018, oparta na poprzedniej wersji czyli TLS 1.2 jako nowy standard. Opisana w RFC 8446 ↓

SSL nie jest żadnym nowym algorytmem szyfrującym. To ustandaryzowany zestaw wcześniej znanych algorytmów, technik i schematów używanych do zapewnienia bezpieczeństwa. Wykorzystuje on algorytmy szyfrowania:

• symetryczne – do szyfrowania i deszyfrowania danych używany jest ten sam klucz; znając klucz szyfrujący, możemy dokonać również deszyfracji danych (wyznaczyć klucz deszyfrujący)
• asymetryczne (z kluczem publicznym) – do szyfrowania i deszyfrowania używane są różne klucze; znając klucz szyfrujący, nie możemy odszyfrować wiadomości (klucza deszyfrującego nie da się w prosty sposób wyznaczyć z klucza szyfrującego); klucz służący do szyfrowania jest udostępniany publicznie (klucz publiczny), ale informację nim zaszyfrowaną może odczytać jedynie posiadacz klucza deszyfrującego (klucz prywatny), który nie jest nikomu ujawniany.

SSL jest najczęściej kojarzony z protokołem HTTP (HTTPS), ale może służyć do zabezpieczania wielu innych protokołów, m.in.: Telnet, SMTP, POP3, IMAP czy FTP, gdyż protokoły te same w sobie nie zapewniają szyfrowania transmisji.

SSL składa się z dwóch podprotokołów, gdzie SSL Handshake, SSL Alert Protocol i SSL Change Cipher stanowią pierwszy podprotokół natomiast SSL Record Protocol stanowi osobny podprotokół SSL:

• SSL Handshake – definiuje metody negocjowania parametrów bezpiecznej sesji, czyli algorytmów szyfrowania danych, algorytmów uwierzytelniania i integralności informacji
• SSL Change Cipher – protokół zmiany specyfikacji szyfru SSL^[5]
• SSL Alert Protocol – protokół alarmowy SSL

• SSL Record – definiuje format przesyłanych pakietów danych

SSL v3 dopuszcza m.in. następujące algorytmy i protokoły: AES, DES, 3DES, IDEA, RC2, RC4, RSA, DSS, Diffiego-Hellmana.

W szyfrowanym kanale transmisji SSL może być przenoszonych wiele sesji HTTP. Dane podczas transmisji są szyfrowane kluczem symetrycznym, jednak na początku sesji sam klucz symetryczny jest uzgadniany przy wykorzystaniu algorytmu niesymetrycznego (RSA, Diffiego-Helmana). Integralność zapewniają podpisy elektroniczne.

Szyfr

Certyfikaty używane w protokole SSL zawierają m.in. nazwę domeny, dla której zostały wystawione. Ponieważ każda osoba może stworzyć dowolny certyfikat, utworzono tzw. Infrastrukturę Klucza Publicznego. Na jej szczycie znajdują się Urzędy Certyfikacji (Certificate Authority – CA). Są to zaufane instytucje weryfikujące prawo do posługiwania się domeną. Osoba uprawniona wysyła do wybranego urzędu swój klucz publiczny, nazwę domeny i inne dane niezbędne do wygenerowania certyfikatu w postaci żądania podpisania certyfikatu (Certificate Signing Request – CSR). Po przejściu procedury sprawdzającej, certyfikat jest podpisywany. Jeśli serwer przedstawi certyfikat niepodpisany przez CA, w większości przeglądarek i klientów pocztowych w czasie próby połączenia użytkownik zobaczy odpowiednie ostrzeżenie.

Rodzaje certyfikatów

Zasadniczo certyfikaty dzielą się na 3 różne klasy różniące się poziomem weryfikacji^[31]:

• DV (Domain Validation) – podstawowa forma zabezpieczenia bez weryfikacji danych podmiotu
• OV (Organization Validation) – z weryfikacją domeny i podmiotu
• EV (Extended Validation) – ze szczegółową weryfikacją podmiotu wnioskującego oraz domeny

Krytycznym parametrem określającym siłę szyfrowania SSL jest długość użytych kluczy. Im dłuższy klucz, tym trudniej jest go złamać, a przez to odszyfrować transmisję. Dla kluczy asymetrycznych, zgodnie z zaleceniami organizacji NIST, długością sugerowaną jest obecnie 2048 bitów. Powszechnie używane są wyrażenia „SSL 128 bitów” lub „SSL 256 bitów” określające długość użytego klucza symetrycznego.

Schemat działania protokołu wygląda następująco (jako K oznaczamy klienta, a jako S – serwer):

• K → S ClientHello
  Klient wysyła do serwera zgłoszenie zawierające m.in. obsługiwaną wersję protokołu SSL, dozwolone sposoby szyfrowania i kompresji danych oraz identyfikator sesji. Komunikat ten zawiera również liczbę losową używaną potem przy generowaniu kluczy.
• K ← S ServerHello
  Serwer odpowiada podobnym komunikatem, w którym zwraca klientowi wybrane parametry połączenia: wersję protokołu SSL, rodzaj szyfrowania i kompresji, oraz podobną liczbę losową.
• K ← S Certificate
  Serwer wysyła swój certyfikat, pozwalając klientowi na sprawdzenie swojej tożsamości (ten etap jest opcjonalny, ale w większości przypadków występuje)
• K ← S ServerKeyExchange
  Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i długość tego klucza jest określony przez typ algorytmu przesłany w poprzednim komunikacie.
• K ← S ServerHelloDone
  Serwer zawiadamia, że klient może przejść do następnej fazy zestawiania połączenia.
• K → S ClientKeyExchange
  Klient wysyła serwerowi wstępny klucz sesji, zaszyfrowany za pomocą klucza publicznego serwera. Na podstawie ustalonych w poprzednich komunikatach dwóch liczb losowych (klienta i serwera) oraz ustalonego przez klienta wstępnego klucza sesji obie strony generują klucz sesji używany do faktycznej wymiany danych. Uwaga: wygenerowany klucz jest kluczem algorytmu symetrycznego (typowo DES)! Jest on jednak ustalony w sposób bezpieczny i znany jest tylko komunikującym się stronom.
• K → S ChangeCipherSpec
  Klient zawiadamia, że serwer może przełączyć się na komunikację szyfrowaną.
• K → S Finished
  ... oraz że jest gotowy do odbierania danych zaszyfrowanych
• K ← S ChangeCipherSpec
  Serwer zawiadamia, że wykonał polecenie – od tej pory wysyłał będzie tylko zaszyfrowane informacje...
• K ← S Finished
  ...i od razu wypróbowuje mechanizm – ten komunikat jest już wysyłany bezpiecznym kanałem

Uwierzytelnianie klienta

Jak widać na schemacie z poprzedniego punktu, w protokole SSL domyślna sytuacja zakłada tylko uwierzytelnianie serwera. Istnieją jednak metody pozwalające na uwierzytelnienie klienta. W tym celu korzysta się z trzech dodatkowych komunikatów:

• K ← S CertificateRequest
  Po przesłaniu swojego certyfikatu serwer zawiadamia, że chciałby otrzymać certyfikat klienta.
• K → S Certificate
  Po otrzymaniu komunikatu ServerHelloDone klient odsyła swój certyfikat.
• K → S CertificateVerify
  Klient musi potwierdzić, że faktycznie posiada klucz prywatny odpowiadający wysłanemu certyfikatowi. W tym celu klient podpisuje swoim kluczem prywatnym skrót wszystkich dotychczas ustalonych danych o połączeniu i wysyła go, korzystając z tego komunikatu.

Odtwarzanie poprzedniej sesji

Nawiązanie połączenia SSL jest procesem dość długotrwałym i wymagającym skomplikowanych obliczeń. W przypadku wielu krótkich połączeń pożądana byłaby możliwość kontynuowania połączenia bez ponownej wymiany kluczy publicznych, ustalania klucza sesji itp. (podobna sytuacja ma miejsce w przypadku protokołu HTTP – stosowane są tam tzw. połączenia trwałe – persistent connections).

Protokół SSL przewiduje taką możliwość. Jeżeli w komunikacie ClientHello klient poda SessionId równy identyfikatorowi jednej z poprzednich sesji, to serwer przyjmie, że klient chce kontynuować połączenie z użyciem poprzednio używanego klucza.

• OpenSSL – otwarta implementacja SSL (ang.)
• Strona projektu „Puls SSL” na witrynie Trustworthy Internet Movement. trustworthyinternet.org. [zarchiwizowane z tego adresu (2017-05-15)]. (ang.) [dostęp 4 września 2015 r.]
• Witryna niekomercyjnego przedsięwzięcia badawczego gromadząca kolekcje dokumentów, narzędzi i pomysłów związanych z SSL (ang.) [dostęp 4 września 2015 r.]
• „Lucky thirteen” – atak na TLS zaprezentowany w lutym 2013 r.
• „SSL jest do bani” – krytyczna analiza modelu zaufania w SSL/TLS i X.509
• T.T. Dierks T.T., C.C. Allen C.C., The TLS Protocol Version 1.0, RFC 2246, IETF, styczeń 1999, DOI: 10.17487/RFC2246, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Dierks T.T., E.E. Rescorla E.E., The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346, IETF, kwiecień 2006, DOI: 10.17487/RFC4346, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Blake-Wilson S.S. i inni, Transport Layer Security (TLS) Extensions, RFC 4366, IETF, kwiecień 2006, DOI: 10.17487/RFC4366, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Santesson S.S., TLS Handshake Message for Supplemental Data, RFC 4680, IETF, październik 2006, DOI: 10.17487/RFC4680, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Santesson S.S., A.A. Medvinsky A.A., J.J. Ball J.J., TLS User Mapping Extension, RFC 4681, IETF, październik 2006, DOI: 10.17487/RFC4681, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Dierks T.T., E.E. Rescorla E.E., The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, IETF, sierpień 2008, DOI: 10.17487/RFC5246, ISSN 2070-1721, OCLC 943595667  (ang.).
• The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, IETF, sierpień 2018, DOI: 10.17487/RFC8446, ISSN 2070-1721, OCLC 943595667  (ang.).