Transport Layer Security

TLS (ang. Transport Layer Security) – przyjęte jako standard w Internecie rozwinięcie protokołu SSL (ang. Secure Socket Layer), zaprojektowanego pierwotnie przez Netscape Communications. TLS zapewnia poufność i integralność transmisji danych, a także uwierzytelnienie serwera, a niekiedy również klienta. Opiera się na szyfrowaniu asymetrycznym oraz certyfikatach X.509. W sierpniu 2018 r. wprowadzono wersję 1.3 tego protokołu jako aktualną^[1].

Według modelu OSI, TLS działa w warstwie prezentacji, dzięki czemu może zabezpieczać protokoły warstwy najwyższej – warstwy aplikacji, np.: telnet, HTTP, gopher, POP3, IMAP, NNTP, SIP.

SSL – informacje ogólne

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].

Wersje protokołu

• 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 na wcześniejszej wersji, 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 ↓

Algorytmy szyfrowania

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

Zabezpieczenie szyfru przed publicznie znanymi możliwymi atakami

Szyfr			Wersja protokołu						Status
Typ	Algorytm	Nominalna siła (w bitach)	SSL 2.0	SSL 3.0 [6][7][8][9]	TLS 1.0 [6][8]	TLS 1.1 [6]	TLS 1.2 [6]	TLS 1.3
Szyfr blokowy z Trybem wiązania	AES GCM[10][11]	256, 128	N/A	N/A	N/A	N/A	zabezpieczone	zabezpieczone	Zdefiniowany dla TLS 1.2 w RFC
	AES CCM[12][11]		N/A	N/A	N/A	N/A	zabezpieczone	zabezpieczone
	AES CBC[13]		N/A	niezabezpieczone	zależy od środków zaradczych	zależy od środków zaradczych	zależy od środków zaradczych	N/A
	Camellia GCM[14][11]	256, 128	N/A	N/A	N/A	N/A	zabezpieczone	N/A
	Camellia CBC[15][13]		N/A	niezabezpieczone	zależy od środków zaradczych	zależy od środków zaradczych	zależy od środków zaradczych	N/A
	ARIA GCM[16][11]	256, 128	N/A	N/A	N/A	N/A	zabezpieczone	N/A
	ARIA CBC[16][13]		N/A	N/A	zależy od środków zaradczych	zależy od środków zaradczych	zależy od środków zaradczych	N/A
	SEED CBC[17][13]	128	N/A	niezabezpieczone	zależy od środków zaradczych	zależy od środków zaradczych	zależy od środków zaradczych	N/A
	3DES EDE CBC[13][19]	112[22]	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A
	GOST 28147-89 CNT[23][24]	256	N/A	N/A	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	zdefiniowany w RFC 4357 ↓
	IDEA CBC[13][24][25][26]	128	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	N/A	Usunięte z TLS 1.2
	DES CBC[13][24][25]	056	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	N/A
		040[27]	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	N/A	N/A	zakazany w TLS 1.1 and later
	RC2 CBC[13][24]	040[27]	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	N/A	N/A
Szyfr strumieniowy	ChaCha20-Poly1305[28][11]	256	N/A	N/A	N/A	N/A	zabezpieczone	zabezpieczone	Zdefiniowany dla TLS 1.2 w RFC
	RC4[29]	128	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	Zakazany we wszystkich wersjach TLS przez RFC 7465 ↓
		040[27]	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	N/A	N/A
Brak	Null[30]	–	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	niezabezpieczone	N/A	Zdefiniowany dla TLS 1.2 w RFC

Certyfikaty

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

Długość klucza

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.

Zasada działania SSL

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.

Przypisy

1. RFC 8446The Transport Layer Security (TLS) Protocol Version 1.3 (ang.) [dostęp 2121-04-18]
2. Dziura w protokołach SSL i TLS. Security Standard, 2009. [dostęp 2009-11-11]. [zarchiwizowane z tego adresu (2009-11-15)].
3. SSL/TLS Authentication Gap – Status of Patches. Phone Factor. [zarchiwizowane z tego adresu (2013-05-14)].
4. E. Rescorla, M. Ray, S. Dispensa, N. Oskov: Transport Layer Security (TLS) Renegotiation Indication Extension. 2009.
5. Marcin Karbowski: Podstawy Kryptografii, wydanie drugie.
6. Konieczna jest implementacja RFC 5746 ↓ w celu naprawy błędu renegocjacji, który w innym przypadku spowodowałby złamanie tego protokołu.
7. Jeśli biblioteki implementują poprawki wymienione w RFC 5746 ↓, narusza to specyfikację SSL 3.0, której IETF nie może zmienić (w przeciwieństwie do TLS). Jednak większość obecnych bibliotek implementuje tę poprawkę i ignoruje powodowane przez nią naruszenie.
8. Tzw. „atak bestii” łamie wszystkie szyfry blokowe (szyfry CBC) wykorzystywane w SSL 3.0 oraz TLS 1.0 (o ile nie zostanie złagodzony przez klienta i/lub serwer).
9. Tzw. „atak POODLE” łamie wszystkie szyfry blokowe (szyfry CBC) wykorzystywane w SSL 3.0 (o ile nie zostanie złagodzony przez klienta i/lub serwer).
10. RFC 5288 5289 ↓ 
11. Szyfry z rodziny AEAD, takie jak GCM oraz CCM) mogą być używane tylko w TLS w wersji 1.2 oraz późniejszych.
12. RFC 6655 7251 ↓ 
13. Szyfry CBC są podatne na tzw. „Lucky Thirteen attack”, jeśli biblioteka nie zostanie zaimplementowana starannie w celu uniknięcia ataków kanałami bocznymi.
14. RFC 6367 ↓
15. RFC 5932 6367 ↓ 
16. RFC 6209 ↓
17. RFC 4162 ↓
18. On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN. 2016-10-28. [dostęp 2017-06-08]. [zarchiwizowane z tego adresu (2017-04-24)].
19. Atak Sweet32 łamie szyfry blokowe o rozmiarze bloku 64 bitów.^[18]
20. NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised). 2007-03-08. [dostęp 2014-07-03]. [zarchiwizowane z tego adresu (6 czerwca 2014)].
21. Qualys SSL Labs: SSL/TLS Deployment Best Practices. [dostęp 2015-06-02]. [zarchiwizowane z tego adresu (4 lipca 2015)].
22. Pomimo że długość klucza 3DES wynosi 168 bitów, efektywna siła tego algorytmu wynosi tylko 112 bitów,^[20] co jest wartością poniżej rekomendowanej minimalnej długości - 128 bitów.^[21]
23. draft-chudov-cryptopro-cptls-04 – GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)
24. On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN. 2016-10-28. [dostęp 2017-06-08]. [zarchiwizowane z tego adresu (2017-04-24)]. (ang.).
25. IDEA oraz DES zostały usunięte z TLS 1.2.
26. RFC 5469 ↓
27. 40-bitowe zestawy szyfrów zostały celowo zaprojektowane ze zmniejszoną długością klucza, aby zachować zgodność z amerykańskimi przepisami zakazującymi eksportu oprogramowania kryptograficznego zawierającego pewne silne algorytmy szyfrowania (patrz Eksport kryptografii ze Stanów Zjednoczonych). Te słabe zestawy algorytmów zostały zakazane w TLS w wersji 1.1 oraz późniejszych.
28. RFC 7905 ↓
29. Wykorzystanie RC4 we wszystkich wersjach TLS jest zabronione przez RFC 7465 ↓, gdyż ataki na RC4 osłabiają bądź zupełnie łamią RC4, używany w SSL/TLS.
30. Brak szyfrowania, tylko uwierzytelnianie.
31. KrystianK. Grabianowski KrystianK., Protokół HTTP i HTTPS – podstawowe różnice [online], Blog widzialni.pl - pozycjonowanie i SEO, 19 grudnia 2018 [dostęp 2020-07-10] (pol.).

Linki zewnętrzne

• 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.).

Encyklopedie internetowe (protokół kryptograficzny):

• SNL: TLS