Protokół SSL

Daniel Rychcik
14-04-2001

0. Wstęp

Dokument ten opisuje protokół SSL używany do bezpiecznej komunikacji w sieci z użyciem metod kryptografii asymetrycznej opisanych w innym miejscu - zostaną tylko wypisane z uwzględnieniem zastosowań i różnic pomiędzy nimi.


SSL (Secure Socket Layer) został opracowany przez firmę Netscape i był przez nią rozwijany aż do wersji 3.0, kiedy to kontrolę nad nim przejęła niezależna organizacja IETF (Internet Engineering Task Force). Pod nazwą TLS (Transport Layer Security) i w wersji 1.0 jest dziś podstawowym standardem bezpiecznego przesyłania danych w sieci Internet.

1. Podstawy

W modelu sieciowym OSI SSL został umiejscowiony w warstwie sieci, tuż ponad warstwą transportową TCP/IP. Działa on zatem przezroczyście dla protokołów warstwy aplikacji takich jak HTTP, LDAP, czy IMAP. Umożliwia to łatwe dostosowanie istniejącego oprogramowania TCP/IP do połączeń szyfrowanych.

SSL wykorzystuje techniki kryptografii asymetrycznej z użyciem kluczy publicznych. Nie będą one tutaj szczegółowo opisywane - zakładam, że Czytelnik zapoznał się ze stosownym dokumentem. Podobnie problematyka infrastruktury kluczy publicznych (PKI) jest opisana gdzie indziej

Główne cele jakie stawiali sobie twórcy protokołu SSL to:

1.1. Autentyfikacja serwera

Autentyfikacja serwera pozwala użytkownikowi na upewnienie się, że ma do czynienia z właściwym serwerem. Jest to ważne w przypadku elektronicznej bankowości, czy realizacji płatności przy pomocy kart kredytowych (e-commerce).

1.2. Autentyfikacja klienta

Autentyfikacja klienta pozwala serwerowi na upewnienie się co do tożsamości użytkownika. Używając podobnych technik jak w poprzednim przypadku serwer może np. mieć pewność, że przesyłane w sieci poufne dane dochodzą rzeczywiście do właściwej osoby

1.3. Bezpieczne połączenia sieciowe

Technika ta pozwala na całkowite zabezpieczenie połączenia sieciowego przed podsłuchem (man-in-the-middle attack) - serwer i klient szyfrują na bieżąco wszystkie przesyłane dane algorytmem na tyle mocnym, że niemożliwe jest ich roszyfrowanie w dającym się przewidzieć czasie.

2. Nawiązywanie połączenia i transmisja danych w protokole SSL

2.1. Zasada działania

Podstawową wadą algorytmów kryptografii asymetrycznej jest ich szybkość (a raczej powolność). W praktycze niemożliwe jest zrealizowanie szyfrowania "w locie" (on-the-fly) z użyciem algorytmów z kluczem publicznym. Stosuje się zatem rozwiązanie mieszane, polegające na tym, że tylko początkowa część transmisji (negocjacja) odbywa się z ich użyciem. Następnie serwery negocjują ze sobą klucze do algorytmów symetrycznych używanych we właściwej transmisji.

Oczywistą zaletą jest w tym momencie szybkość: algorytmy symetryczne są z reguły bardzo szybkie, a ponadto istnieją dla nich wydajne implementacje sprzętowe. Poza tym takie podejście nie zmniejsza znacząco bezpieczeństwa całego systemu. Stosowana jest bowiem okresowa zmiana kluczy algorytmu symetrycznego (zwanych kluczami sesji), której częstość może zostać dostosowana do stopnia poufności przesyłanych danych.

2.2. Schemat nawiązywania połączenia w protokole SSL.

Zanim dwie maszyny zaczną się porozumiewać w sposób szyfrowany muszą zatem uzgodnić klucze sesji i dokonać ewentualnej autentyfikacji partnera. Schemat postępowania przez strony wygląda następująco:

  • K -> S ClientHello
    Klient wysyła do serwera zgłoszenie zawierające m.in. numer obsługiwanej wersji protokołu SSL, dozwolone algorytmy szyfrowania i kompresji danych oraz identyfikator sesji. Komunikat ten zawiera również liczbę losową używaną przy generowaniu kluczy sesji.
  • 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 ServerKeyExchange
    Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i długość tego klucza jest określony przez typ algorytmu przesłany uprzednio.
  • 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 krokach 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.
    (Wygenerowany klucz jest kluczem algorytmu symetryczneo - zgodnie z tym co było opisane w punkcie 2.1.)
  • 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 będzie wysyłał tylko zaszyfrowane dane
  • K <- S Finished
    ... i od razu wypróbowuje mechanizm - ten komunikat jest już wysyłany bezpiecznym kanałem!

2.3. Autentyfikacja klienta

W standardzie SSL domyślnie nie przewiduje się autentyfikacji klienta, jednak właśnie to jest jednym z jego podstawowych zastosowań. Potrzebne są do tego trzy dodatkowe komunikaty, wymieniane między klientem i serwerem w trakcie fazy nawiązywania połączenia:

  • K <- S CertificateRequest
    Serwer żąda od klienta autoryzacji z użyciem certyfikatu
  • K -> S Certificate
    Klient przesyła swój certyfikat
  • K -> S CertificateVerify
    Klient udowadnia że ma klucz prywatny odpowiadający certyfikatowi, szyfrując nim dotychczas ustalone dane na temat sesji (jeśli serwer odszyfruje je kluczem publicznym klienta, to znaczy, że wszystko jest w porządku).

Aby sprawdzić otrzymany certyfikat klienta i zweryfikować jego autentyczność serwer musi sprawdzić następujące warunki:

  • Czy klient jest w stanie udowodnić, że posiada klucz prywatny odpowiadający kluczowi publicznemu zawartemu w certyfikacie?
  • Czy aktualna data zawiera się w okresie ważności certyfikatu?
  • Czy certyfikat jest podpisany przez zaufaną instytucję?
    (Może się to odbywać z użyciem łańcuchów certyfikatów, opisanych dokładniej w dokumencie RFC opisującym m.in. standard X.509
  • Czy podpis CA pod kluczem publicznym klienta jest prawdziwy?
  • Czy podmiot na który jest wystawiony certyfikat znajduje się w bazie danych użytkowników danego serwera?
  • Czy klient o ustalonej w ten sposób tożsamości rzeczywiście ma prawo dostępu do żądanych danych?

2.4. Autentyfikacja serwera

Co prawda nie jest to ściśle zastrzeżone w standardzie SSL, jednak większośc dostępnych implementacji zawsze zakłada autentyfikację serwera do systemu klienta. Oznacza to, że serwer musi wysłać swój certyfikat. Odbywa się to przy użyciu komunikatu:

  • K <- S Certificate

Aby sprawdzić otrzymany certyfikat serwera i zweryfikować jego autentyczność klient musi sprawdzić następujące warunki:

  • Czy aktualna data zawiera się w okresie ważności certyfikatu?
  • Czy certyfikat jest podpisany przez zaufaną instytucję?
    (Może się to odbywać z użyciem łańcuchów certyfikatów, opisanych dokładniej w dokumencie opisującym standard X.509
  • Czy podpis CA pod kluczem publicznym serwera jest prawdziwy?
  • Czy nazwa własna podmiotu certyfikatu (DN - Designated name) zgadza się z adresem DNS serwera?

Ostatni etap zabezpiecza przed atakami typu man-in-the-middle w których ktoś mógłby np. przeprogramować któryś z pośrednich serwerów DNS i podszyć się pod szukany serwer.

2.5. Odtwarzanie 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 protokole HTTP w wersji 1.1 - stosowane są tam połączenia trwałe - persistent connections)

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

3. Typy i przeznaczenie algorytmów kryptograficznych stosowanych w SSL

3.1. Spis algorytmów

  • DES (Data Encryption Standard) - algorytm używany i zalecany przez rząd USA.
  • DSA (Digital Signature Algorithm) - algorytm cyfrowego podpisu używany przez rząd USA.
  • SHA (Secure Hash Algorithm) - algorytm funkcji skrótu (Message digest) używany przez rząd USA
  • KEA (Key Exchange Algorithm) - algorytm wymiany kluczy używany przez rząd USA.
  • MD5 (Message Digest) - algorytm funkcji skrótu opracowany przez A. Rivesta.
  • RC2, RC4 (Rivest Cipher) - algorytmy szyfrowania opracowane przez firmę RSA Security.
  • RSA (Rivest-Shamir-Adleman) - asymetryczny algorytm szyfrowania danych z wykorzystaniem kluczy publicznych i prywatnych.

3.2. Ograniczenia eksportowe

Rząd USA wprowadził ograniczenia w zakresie dystrybucji programów używających najmocniejszych technik kryptograficznych - ma to teoretycznie na celu zapobieganie używaniu ich do celów przestępczych, w praktyce głównie utrudnia życie twórcom oprogramowania. Ze względu na "siłę" szyfrowania można algorytmy podzielić na trzy grupy:

  • Najmocniejsze - odpowiednie dla banków, instytucji rządowych i innych organizacji wymagających największej ochrony poufności danych. Takim algorytmem jest TripleDES - kombinacja trzykrotnego szyfrowania algorytmem DES połączonego z powiększoną długością klucza. Innymi "mocnymi" algorytmami są: 128-bitowy RC4, 128-bitowy RC2 (używające MD5 do autentyfikacji danych) oraz 56-bitowy DES (autentyfikacja z użyciem SHA-1)
    Ograniczenia eksportowe zakazują dystrybucji oprogramowania umożliwiającego stosowanie tej grupy algorytmów poza teren USA.
  • Średniej mocy - możliwe do eksportu w oprogramowaniu. Należą tu m.in. 40-bitowy RC4 i 40-bitowy RC2. Jak widać słabsze szyfry wykorzystują te same algorytmy, ale używają krótszych kluczy, co (teoretycznie) pozwala na odszyfrowanie danych przez organizacje dysponujące odpowiednio dużymi mocami obliczeniowymi (np. agencje rządowe :-)
  • Słabe - zapewniają tylko autentyfikację i wykrywanie przekłamań/fałszerstwa. Nie zapewniają natomiast szyfrowania przesyłanych danych. Przykładem takiego algorytmu jest samo MD5.

Innym standardem stosowanym wyłącznie w USA jest Fortezza - jest on używany do szyfrowania danych przy użyciu specjalnych urządzeń i nie będzie tutaj omawiany

4. Narzędzia

Pozostaje wspomnieć o narzędziach stosowanych w komunikacji przy użyciu protokołu SSL. Skupię się tu na narzędziach darmowych - pakiety komercyjne są trudno dostępne i rzadziej używane. Szczegółowe procedury instalacji i konfiguracji są opisane w odrębnym dokumencie.


Podstawowym i najczęściej stosowanym narzędziem umożliwiającym komunikację z użyciem protokołu SSL jest pakiet OpenSSL. Zawiera on programy służące do generowania kluczy, poświadczania i unieważniania certyfikatów, eksportowania ich do wszystkich popularnych formatów (DER, PEM, PKCS#12, PKCS#7.

Pakiet OpenSSL jest darmowy i dostępny w postaci kodu źródłowego. Działa na większości dostępnych platform sprzętowych i systemów operacyjnych.


Naturalnym uzupełnieniem OpenSSL jest pakiet mod_ssl. Jest to biblioteka (moduł) która po dołączeniu do serwera WWW Apache umożliwia realizację bezpiecznych połączeń WWW.

Ważnym elementem układanki jest program stunnel. Służy on do przystosowywania do bezpiecznej komunikacji pakietów oprogramowania, które nie przewidują takiej możliwości. Działa on na zasadzie tworzenia "połączenia wirtualnego" (tunnel) które jest widziane przez program użytkowy jako zwykłe połączenie TCP. Przykładem takiego rozwiązania może być bezpieczny serwer poczty IMAP.

Inną metodą udostępniania połączeń bezpecznych zwykłym aplikacją są ssl-wrappery. Jest to technika, która dopiero się rozwija, ale w perspektywie zapewnia nieco większą elastyczność - działa bowiem na nieco niższym poziomie niż stunnel: ingeruje bezpośrednio w deskryptory plików.