| « poprzedni punkt |
Protokół SSL (Secure Socket Layer) został opracowany przez firmę Netscape. Projektowany był jako protokół otwarty, czyli charakteryzujący się brakiem przywiązania do jednego algorytmu szyfrowania. Realizuje uwierzytelnienie (autoryzację), szyfrowanie oraz zapewnia integralność wiadomości. Posiada wbudowany mechanizm uwierzytelniania serwera i opcjonalnie klienta. Współpracuje z zaporami sieciowymi i połączeniami tunelowanymi. Bazuje na protokole zapewniającym niezawodną komunikację (np. TCP). Jest niezależny od aplikacji warstw wyższych. Dzięki temu może być wykorzystywany do zabezpieczania takich protokołów jak TELNET, FTP, HTTP. Na stosie protokołów TCP/IP SSL leży pomiędzy warstwą aplikacji zawierającą HTTP, SMTP, Telnet, FTP i inne a warstwą transportową, która zawiera protokół TCP.
SSL wykorzystuje dwa rodzaje kryptografii: symetryczną (z pojedynczym kluczem) oraz niesymetryczną (z kluczem prywatnym i publicznym).
Przebieg sesji:
Protokół SSL jest właściwie zestawem protokołów:
Protokół rekordu służy do zapewnienia bezpieczeństwa i integralności danych i w tych celach jest stosowany przez "wyższe" protokoły wchodzące w skład SSL. Celem protokołu rekordu jest podzielenie danych przesyłanych przez aplikację, opakowanie ich w odpowiednie nagłówki i stworzenie obiektu zwanego właśnie rekordem, który zostaje zaszyfrowany i może zostać przekazany do przesłania poprzez protokół TCP. Schemat procedury realizowanej przez ten protokół przedstawiono na rys. 5.
Rys. 5 Schemat procedury realizowanej przez SSL Record Protocol
Pierwszym krokiem realizowanym podczas przygotowania danych aplikacji do przesłania jest podzielenie ich na jednostki po 16 kB lub mniejsze. Taka porcja danych może zostać poddana dodatkowo kompresji, jednak w specyfikacji protokołu SSL 3.0 nadal nie został ustalony żaden protokół kompresji, więc w chwili obecnej kompresja danych nie jest stosowana.
Dla każdego fragmentu rozpoczyna się budowanie rekordu, poprzez dodanie:
Nagłówek rekordu, dodawany do każdej porcji danych, zawiera dwie elementarne informacje, a mianowicie długość rekordu i długość bloku danych dołożonych do danych podstawowych.
Kolejnym krokiem po stworzeniu nagłówka rekordu jest zbudowanie danych rekordu, które składają się z następujących elementów:
Znacznik MAC ma za zadanie zapewnić możliwość sprawdzenia integralności danych przesyłanych w rekordzie. Jest on wynikiem działania funkcji mieszającej według określonego w sesji algorytmu mieszania, na przykład MD5lub SHA-1. Schemat wywołania funkcji mieszającej:
MAC = Funkcja mieszająca (hasło, dane podstawowe, dane uzupełniające, numer sekwencji).
Jako hasło w procesie tworzenia MAC stosowane jest odpowiednio hasło zapisu MAC klienta lub serwera, w zależności od strony przygotowującej pakiet. Po odebraniu pakietu, strona odbierająca dokonuje własnego wyliczenia wartości znacznika MAC i porównuje go z przesłaną wartością. Długość uzyskanego znacznika zależy od metody jego uzyskania.
Dane połączone ze znacznikiem MAC poddawane są następnie szyfrowaniu przy użyciu ustalonego algorytmu szyfrowania symetrycznego, na przykład DES lub 3DES. Szyfrowaniu poddane są zarówno dane, jak i znacznik MAC. Do tak przygotowanych danych dodawane są pola nagłówka, a pomiędzy nimi:
Rekord jest następnie przesyłany do punktu docelowego. Protokół rekordu SSL jest używany do przesyłania wszelkich danych w ramach sesji, zarówno komunikatów pozostałych protokołów SSL (na przykład handshake), jak i do wszelkich przesyłanych danych aplikacji.
Protokół alarmu (SSL Alert Protocol) służy do przesyłania komunikatów związanych z wymianą danych i działaniem protokołu. Każdy komunikat wysyłany przez protokół alarmu składa się z dwóch bajtów. Pierwszy wskazuje stopień ważności przesyłanego komunikatu. Drugi zawiera jeden ze zdefiniowanych kodów błędu, które mogą wystąpić w trakcie komunikacji SSL.
Protokół SSL ChangeCipher Specl składa się tylko z jednego komunikatu, w którym przekazywana jest jedynie wartość 1. Celem przesłania tego komunikatu jest spowodowanie, aby ustanawiany właśnie stan sesji został uznany za ustalony. Komunikat taki musi zostać przesłany przez klienta do serwera oraz przez serwer do klienta. Po wymianie tych komunikatów stan sesji uznaje się za ustalony.
Protokół wymiany (SSL Handshake Protocol) jest najbardziej skomplikowaną częścią protokołu SSL. Służy on do nawiązania sesji pomiędzy serwerem a klientem. Umożliwia ustalenie takich elementów, jak na przykład algorytmy i klucze używane do szyfrowania danych. Umożliwia też uwierzytelnienie stron połączenia i wynegocjowanie odpowiednich parametrów sesji. Schemat procedury realizowanej przez ten protokół przedstawiono na rys. 6.
Rys. 6. Schemat procedury realizowanej przez protokół wymiany
Proces przebiegu negocjacji może zostać podzielony na 4 fazy. W pierwszej fazie pomiędzy klientem a serwerem musi zostać nawiązane logiczne połączenie i rozpoczęta zostaje negocjacja parametrów tegoż połączenia. Klient wysyła do serwera komunikat client - hello, zawierający takie dane, jak:
Serwer w odpowiedzi na komunikat client - hello przesyła komunikat server - hello, zawierający identyczny zestaw pól, jak komunikat przesłany przez klienta, wypełniając je następującymi danymi:
Następna faza negocjacji rozpoczyna się od wysłania przez serwer swojego certyfikatu w celu uwierzytelnienia u klienta. Przesyłana do klienta wiadomość zawiera jeden lub więcej certyfikatów X509 koniecznych do uwierzytelnienia serwera i ścieżki certyfikacji prowadzącej do zaufanego urzędu certyfikacji, który wystawił certyfikat serwera. Krok ten nie jest obowiązkowy i może być pominięty, jeżeli wynegocjowana metoda wymiany kluczy nie wymaga przesłania certyfikatu (w przypadku anonimowej metody Diffie-HelImana). W zależności od wynegocjowanej metody wymiany kluczy, serwer może wysłać dodatkowy komunikat server_key_exchange, który nie jest jednak wymagany w przypadku, gdy wynegocjowana została metoda Diffie- HelImana lub RSA key exchange. Dodatkowo serwer może zażądać od klienta przesłania jego certyfikatu. Ostatnim krokiem w drugiej fazie negocjacji jest przesłanie przez serwer komunikatu server_done, który nie niesie ze sobą żadnych parametrów, lecz jest jedynie sygnałem dla klienta, że serwer zakończył przesyłanie komunikatów i oczekuje na odpowiedź.
Po otrzymaniu tego komunikatu klient powinien zweryfikować certyfikat serwera, jego ważność i ścieżkę certyfikacji, jak również wszelkie inne parametry przesłane przez serwer w komunikacie server_hello. Potwierdzenie autentyczności i poprawności certyfikatu serwera po stronie klienta polega na:
Po prawidłowym przejściu wszystkich tych kroków, serwer uznawany jest za uwierzytelniony. Wówczas klient odpowiada serwerowi jednym lub wieloma komunikatami. Jedynym koniecznym komunikatem jest przesłanie do serwera kluczy klienta w komunikacie client_key_exchange, którego zawartość zależna jest od wynegocjowanej metody wymiany kluczy. Dodatkowo, jeżeli serwer tego zażądał, przesyłany jest certyfikat klienta i komunikat umożliwiający weryfikację tego certyfikatu. Wysłanie tych komunikatów kończy trzecią fazę negocjacji.
Czwarta faza stanowi potwierdzenie wysłanych wcześniej wiadomości i weryfikację poprawności wynegocjowanych danych. Rozpoczyna ją klient wysyłając komunikat change_cipher_spec (protokoł SSL ChangeCipher Spec), po czym ustanawia wynegocjowany zestaw parametrów algorytmów i kluczy jako obowiązujący. Następnie wysyła dodatkowy komunikat finished, zaszyfrowany z wykorzystaniem wynegocjowanych algorytmów i uzyskanych kluczy. Komunikat ten stanowi potwierdzenie poprawności uzyskanych w trakcie negocjacji parametrów i danych. Serwer odpowiada klientowi identyczną sekwencją komunikatów. Jeżeli komunikat finished został prawidłowo odczytany przez każdą ze stron, potwierdza to prawidłowość przesłanych danych i wynegocjowanych algorytmów i klucza sesji, co oznacza, że negocjacja została zakończona i możliwe jest rozpoczęcie przesyłania danych aplikacji pomiędzy serwerem a klientem z wykorzystaniem SSL. Po zakończeniu negocjacji połączenie TCP pomiędzy klientem a serwerem zostaje zakończone, jednakże po obu stronach zachowany zostaje stan sesji pozwalający na nawiązanie dalszych połączeń w ramach sesji, z wykorzystaniem wynegocjowanych parametrów.
Na podstawie wersji 3 SSL został opracowany protokół TLS (Transport Layer Security). Jest on nieco ulepszony i firmowany przez IETF. W 1996 roku w ramach IETF rozpoczęła prace grupa, która ma za zadanie opracowanie i wypromowanie jako standardu internetowego, protokołu zabezpieczenia transmisji w sieci. Grupa ta jako punkt wyjścia do dalszych prac przyjęła protokół SSL w wersji 3.0, a jako wynik prac, w 1999 roku opublikowała ona dokument RFC 2246, definiujący nowy protokół Transport Security Layer (TLS) w wersji 1.0.
Podstawowe zadania były podobne jak założenia protokołu SSL, a więc zapewnienie prywatności i integralności danych wymienianych pomiędzy dwoma aplikacjami w sieci. Dodatkowo tworzący go zespół przyjął dla niego wytyczne uzupełniające:
Protokół TLS również składa się z dwóch podstawowych warstw protokołów:
Specyfikacja zawarta w RFC 2246 nie określa jednak sposobu w jaki protokoły warstw wyższych mają wykorzystywać TLS do zabezpieczenia transmisji. Zespół pracujący nad TLS opracował dwa dodatkowe dokumenty RFC:
Przedstawiają one sposób implementacji TLS dla protokołu HTTP, zastępując nim wykorzystywany dotychczas protokół SSL. Dokumenty te przedstawiają między innymi sposób wykorzystania połączenia HTTP zabezpieczonego TLS, bez potrzeby używania dodatkowego portu dla połączenia szyfrowanego, tak jak to ma miejsce w przypadku wykorzystania protokołu SSL. Połączenie szyfrowane poprzez TLS nawiązywane jest z wykorzystaniem standardowego portu HTTP.
Kolejnym przykładem specyfikacji wykorzystania bezpiecznego połączenia z wykorzystaniem TLS jest dokument RFC 2487 "SMTP Service Extension for Secure SMTP over TLS", definiujący sposób nawiązania bezpiecznego połączenia dla protokołu SMTP z wykorzystaniem standardowego portu i rozszerzeń protokołu.
Protokół TLS jest już w chwili obecnej wspomagany przez część oprogramowania. Jest on wspomagany między innymi przez przeglądarkę Internet Explorer. Pomimo tego, że protokół SSL jest nadal najbardziej rozpowszechnioną metodą zabezpieczenia transmisji wykorzystywaną w Internecie, należy spodziewać się, że w przyszłości zostanie on zastąpiony właśnie przez TLS uznany za standard zabezpieczenia transmisji dla usług internetowych.
| « poprzedni punkt |