Transport Layer Security

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacji, wyszukiwania

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.

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[edytuj | edytuj kod]

W 1994 roku firma Netscape stworzyła 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 większych kluczy. Obecnie 40-bitowe klucze wyszły z użycia i zostały zastąpione przez zapewniające większe 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)[1][2]. 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[3].

Wersje protokołu[edytuj | edytuj kod]

  • Capture1.JPG
    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, zalecana przez IETF jako standard i coraz częściej używana. 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.

Algorytmy szyfrowania[edytuj | edytuj kod]

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, POP, 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[4]
  • 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: 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 przesyłany przy wykorzystaniu algorytmu niesymetrycznego (RSA, Diffiego-Helmana). Integralność zapewniają podpisy elektroniczne.

Certyfikaty[edytuj | edytuj kod]

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.

Długość klucza[edytuj | edytuj kod]

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” oraz „SSL 40 bitów” określające długość użytego klucza symetrycznego.

Zasada działania SSL[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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. Dziura w protokołach SSL i TLS. Security Standard, 2009.
  2. SSL/TLS Authentication Gap – Status of Patches. Phone Factor.
  3. E. Rescorla, M. Ray, S. Dispensa, N. Oskov: Transport Layer Security (TLS) Renegotiation Indication Extension. 2009.
  4. Marcin Karbowski: Podstawy Kryptografii, wydanie drugie

Linki zewnętrzne[edytuj | edytuj kod]