Transport Layer Security

Article on other languages:

• Transport_Layer_Security
• Transport_Layer_Security
• Transport_Layer_Security
• Transport_Layer_Security
• Transport_Layer_Security
• TLS
• Transport_Layer_Security
• Transport_Layer_Security
• TLS
• Transport_Layer_Security
• TLS
• Transport_Layer_Security
• Transport_Layer_Security

	del.icio.us
	Digg
	Furl
	Reddit
	Rojo
	Add to OnlyWire

TLS (ang. Transport Layer Security) – przyjęte jako standard w Internecie rozwinięcie protokołu SSL (ang. Secure Socket Layer), w swojej pierwotnej wersji zaprojektowanego przez firmę Netscape Communications Corporation. TLS ma na celu zapewnienie poufności i integralności transmisji danych oraz zapewnienie uwierzytelnienia, opiera się na szyfrach asymetrycznych oraz certyfikatach standardu X.509.

Zaletą protokołu jest fakt, że działa on na warstwie TCP, więc można go łatwo zastosować do zabezpieczenia protokołów warstwy aplikacyjnej (np.: telnet, HTTP, gopher, POP3, IMAP, NNTP).

SSL - informacje ogólne

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ę wersja v3 tego protokołu. W 1996 roku Internet Engineering Task Force (IETF) powołało grupę roboczą pod nazwą TLS (Transport Layer Security), której zadaniem było rozwijanie protokołu SSL. W 1999 roku został opublikowany standard TLS 1.0, który jest również czasem określany jako SSL 3.1. SSL jest więc protokołem typu klient-serwer pozwalającym na nawiązanie bezpiecznego połączenia z użyciem certyfikatów. Jest on zorientowany 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ść autoryzacji klienta.

Ciekawostka

Niektóre wczesne wersje protokołu używały szyfrowania 40-bitowym kluczem ze względu na ograniczenia nałożone przez rząd USA na eksport technologii kryptograficznych. Rząd specjalnie nałożył ograniczenie 40-bitowe aby rządowe agencje były w stanie złamać hasło za pomocą ataku brute-force a jednocześnie było zbyt skomplikowane dla zbyt ubogich hakerów. Po kilku latach publicznej debaty, lepszemu rozpoznaniu dłuższych kluczy przez agencje rządowe oraz kilku sprawach sądowych, rząd złagodził nieco swoje stanowisko wobec stosowania dłuższych kluczy. Obecnie 40-bitowe klucze wyszły praktycznie z użycia, zastąpione przez o wiele bezpieczniejsze klucze 128-bitowe

Wersje protokołu

• SSL 1 – ta wersja miała poważną dziurę w bezpieczeństwie biorącą się z nieweryfikowania procedury uzgadniania szyfru. Atakujący mógł wymusić używanie przez strony najsłabszego szyfru obsługiwanego przez obie strony, ze złamaniem którego mógł sobie poradzić znacznie łatwiej niż z szyfrem, który strony wybrałyby normalnie.
• SSL 2 – ta wersja weryfikuje procedurę negocjacyjną.
• SSL 3 – wersja obecnie najczęściej używana.
• TLS 1.0 – rozwinięcie SSL 3 opisane w RFC 2246.
• TLS 1.1 – wersja obecnie rozwijana, 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.

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 zakodowaną 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, ale może służyć do szyfrowania wielu innych protokołów, m.in.: Telnet, SMTP, POP, IMAP czy FTP. Ponieważ protokoły te nie zapewniają szyfrowania transmisji, warto w nich zastosować SSL, który oferuje szyfrowanie, uwierzytelnianie (algorytmami RSA lub Diffiego-Hellmana, zapewnianie integralności danych oraz opcjonalnie również uwierzytelnienie klienta.

SSL składa się z dwóch podprotokołów, gdzie SSL Handshake, SSL Alert Protocol i SSL Change Cipher stanowią pierwszy podprotokól 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 (źródło "Podstawy Kryptografii" Marcin Karbowski, wydanie drugie)
• SSL Alert Protocol - protokół alarmowy SSL

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

SSL v3 dopuszcza m.in. algorytmy szyfrowania: DES, 3DES, IDEA, RC2, RC4, RSA, DSS, Diffiego-Hellmana

W kodowanym 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

Podstawowym problemem podczas uwierzytelniania jest upewnienie się, że klucz publiczny, który otrzymaliśmy, rzeczywiście pochodzi od danej osoby. Aby wyeliminować możliwość podłożenia czyjegoś klucza (podszycia się pod kogoś) stworzony został system certyfikatów. Certyfikat jest to zbiór danych jednoznacznie identyfikujących pewną jednostkę (na przykład osobę, lub komputer) oraz pozwalający stwierdzić, czy ta jednostka, która się nim legitymuje jest rzeczywiście tym, za kogo się podaje. Jest on potwierdzony przez zaufaną organizację, zwaną w protokole SSL Certificate Authority (CA). Certyfikat zawiera:

• Nazwę certyfikowanego obiektu
• Identyfikator obiektu
• Klucz publiczny obiektu
• Czas ważności
• Nazwę wystawcy certyfikatu
• Identyfikator wystawcy
• Podpis wystawcy (To pole zawiera jednoznaczny skrót całego certyfikatu zaszyfrowany przy pomocy klucza prywatnego wystawcy.)

Istnieją trzy rodzaje certyfikatów:

• certyfikat CA – informacje opisujące tożsamość danej instytucji certyfikującej
• certyfikat serwera – informacje opisujące tożsamość danego serwera
• certyfikat osobisty – informacje opisujące tożsamość danej osoby; musi być podpisany certyfikatem CA

Długość klucza

Krytycznym parametrem określającym siłę szyfrowania SSL jest długość użytych kluczy. Oczywiście im dłuższy klucz, tym trudniej jest dokonać deszyfracji transmisji. Dla kluczy asymetrycznych długością sugerowaną jest 1024 bitów. Powszechnie używane są określenia „SSL 128 bitów” (sugerowane stosowanie) oraz „SSL 40 bitów”. Podana w bitach długość określa 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 na podstawie ustalonych w poprzednich komunikatach dwóch liczb losowych (swojej i serwera) 
generuje klucz sesji używany do faktycznej wymiany danych.
Następnie wysyła go serwerowi używając jego klucza publicznego. 
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 zakodowanych. 

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.

Linki zewnętrzne

• (en) Strona internetowa darmowej implementacji SSL