TLS () – przyjęte jako standard w Internecie rozwinięcie protokołu SSL (ang. ), 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ąRFC 8446The Transport Layer Security (TLS) Protocol Version 1.3 [dostęp 2121-04-18].
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 (), 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ą , 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). 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.
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 . TLS 1.1 – opisana w . Wyjaśnia ona pewne niejednoznaczności i dodaje nowe zalecenia wynikające z praktyki użycia – opisano to w , i . TLS 1.2 – opisana w 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
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 SSLMarcin Karbowski: Podstawy Kryptografii, wydanie drugie. 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 atakamiSzyfr Wersja protokołu Status Typ Algorytm Nominalna siła (w bitach) SSL 2.0 SSL 3.0Konieczna jest implementacja w celu naprawy błędu renegocjacji, który w innym przypadku spowodowałby złamanie tego protokołu.Jeśli biblioteki implementują poprawki wymienione w , 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.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).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). TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3Szyfr blokowyzTrybem wiązaniaAES GCMSzyfry z rodziny AEAD, takie jak GCM oraz CCM) mogą być używane tylko w TLS w wersji 1.2 oraz późniejszych. 256, 128 Zdefiniowany dla TLS 1.2 w RFCAES CCM AES CBC Camellia GCM 256, 128 Camellia CBC ARIA GCM 256, 128 ARIA CBC SEED CBC 128 3DES EDE CBCSzyfry CBC są podatne na tzw. „”, jeśli biblioteka nie zostanie zaimplementowana starannie w celu uniknięcia ataków kanałami bocznymi. 112 GOST 28147-89 CNTdraft-chudov-cryptopro-cptls-04 – GOST 28147-89 Cipher Suites for Transport Layer Security (TLS) 256 zdefiniowany w IDEA CBCIDEA oraz DES zostały usunięte z TLS 1.2. 128 Usunięte z TLS 1.2 DES CBC 56 4040-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. zakazany w TLS 1.1 and laterRC2 CBC 40 Szyfr strumieniowyChaCha20-Poly1305 256 Zdefiniowany dla TLS 1.2 w RFC RC4Wykorzystanie RC4 we wszystkich wersjach TLS jest zabronione przez , gdyż ataki na RC4 osłabiają bądź zupełnie łamią RC4, używany w SSL/TLS. 128 Zakazany we wszystkich wersjach TLS przez 40 Brak NullBrak szyfrowania, tylko uwierzytelnianie. – 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 ( – ). 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 ( – ). 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:
() – podstawowa forma zabezpieczenia bez weryfikacji danych podmiotu () – z weryfikacją domeny i podmiotu () – 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 ClientHelloKlient 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 ServerHelloSerwer 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 CertificateSerwer 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 ServerKeyExchangeSerwer 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 ServerHelloDoneSerwer zawiadamia, że klient może przejść do następnej fazy zestawiania połączenia. K → S ClientKeyExchangeKlient 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 ChangeCipherSpecKlient zawiadamia, że serwer może przełączyć się na komunikację szyfrowaną. K → S Finished... oraz że jest gotowy do odbierania danych zaszyfrowanych K ← S ChangeCipherSpecSerwer 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 CertificateRequestPo przesłaniu swojego certyfikatu serwer zawiadamia, że chciałby otrzymać certyfikat klienta. K → S CertificatePo otrzymaniu komunikatu ServerHelloDone klient odsyła swój certyfikat. K → S CertificateVerifyKlient 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