Sieci > Bezpieczeństwo > Model TCP/IP > Warstwa internetowa
Secure Sockets Layer (SSL) Transport Layer Security (TLS)
Zestaw protokołów TCP/IP jest niezawodnym, ale niezabezpieczonym środkiem transportu. Z tego powodu powstają protokoły działające ponad TCP/IP, które zabezpieczają warstwę transportową. Celem jest zapewnienie prywatności, uwierzytelniania i integralności. Najbardziej znanym protokołem bezpieczeństwa warstwy transportu jest SSL, ale do grupy tej zalicza się również protokół SOCKS i SSH [6]. Protokół SSH jest dokładniej omówiony w kolejnym podrozdziale, ponieważ wersja 2 Secure Shell Protocol używa TLS [23]. Protokół SOCKS (ang. socket security) jest natomiast przykładem protokołu pośredniczącego, który pozwala wygodnie i bezpiecznie używać firewalla. Usługi pośredniczenia szerzej omówione są w rozdziale poświęconym ścianom ogniowym.
Protokół SSL został zaprojektowany przez firmę Netscape. Konkurentem dla SSL był początkowo podobny protokół nazywany S-HTTP. Przeglądarki obsługujące S-HTTP nie były jednak darmowe i to zadecydowało o zdobyciu dominującej pozycji przez SSL [10]. Pierwotnie jego zadaniem była więc ochrona sesji HTTP, ale obecnie jest stosowany w szerszym zakresie. TLS (ang. Transport Layer Security) to standard IETF oparty na SSL [6]. Warstwa bezpiecznych gniazd działa ponad TCP/IP chroniąc w ten sposób protokoły takie jak HTTP, czy IMAP (rysunek 2.16).
Rysunek 2.16 SSL zabezpiecza protokoły z warstwy aplikacji
Uwierzytelnianie serwera (ang. SSL server authentication) pozwala użytkownikowi potwierdzać tożsamość serwera. Do uwierzytelniania wykorzystywana jest kryptografia asymetryczna. Klient sprawdza czy certyfikat serwera i jego publiczne ID są ważne oraz czy są podpisane przez zaufany przez niego urząd certyfikujący (ang. Certificate Authority - CA).
Uwierzytelnianie klienta (ang. SSL client authentication) pozwala serwerowi potwierdzić tożsamość klienta. W tym przypadku to serwer sprawdza certyfikat klienta.
Szyfrowanie połączeń (ang. encrypted SSL connection) pomiędzy klientem i serwerem zapewnia tajność komunikacji. Do szyfrowania danych używane są symetryczne metody kryptograficzne. Jednocześnie sprawdzana jest integralność przesyłanych danych za pomocą MAC. Do wyliczania MAC wykorzystywane są bezpieczne funkcje mieszające.
Architekturę protokołu SSL przedstawia rysunek 2.17.
Rysunek 2.17 Dwie warstwy protokołu SSL
Usługi SSL realizowane są za pomocą następujących protokołów [10]:
- SSL Handshake Protocol – uwierzytelnianie i negocjacja parametrów,
- SSL Change CipherSpec Protocol – negocjowanie parametrów dotyczących szyfrowania,
- SSL Alert Protocol – sygnalizacja o wystąpieniach błędów,
- SSL Application Data Protocol – interfejs pozwalający na dostęp do SSL Record Protocol,
- SSL Record Protocol – używany do wymiany danych warstwy aplikacji.
Protokół ten jest odpowiedzialny za przesyłanie danych. Jego budowę pokazuje rysunek 2.18.
Rysunek 2.18 SSL Record Protocol
Pierwsze pole informuje o zawartości, może to być Change CipherSpec (20), Alert (21), Handshake (22) lub Application Data (23). Kolejne pole przenosi informacje o używanej wersji protokołu SSL. Długość przesyłanych danych wyrażona jest w bajtach i nie może ona przekraczać 214 bajtów. Wysyłane dane są najpierw dzielone na rekordy, każdy o maksymalnej wielkości 214 bajtów. W przypadku wiadomości tego samego typu kilka może być przesyłanych w tym samym rekordzie. Po fragmentacji dane są kompresowane (domyślnie stosowany jest algorytm NULL – brak kompresji). Następnie do każdego rekordu danych dopisywane są informacje uwierzytelniające. Do obliczenia MAC wykorzystywane są funkcje mieszające SHA-1 lub MD5. W ostatnim kroku rekord danych i MAC są szyfrowane wynegocjowanym algorytmem. Może to być IDEA, RC2-40, DES-40, DES, 3DES, FORTEZZA [6], RC4-40, RC4-128. Wykorzystywana jest kryptografia z kluczem symetrycznym, ponieważ szyfrowanie danych jest o wiele szybsze, niż w przypadku kryptografii z kluczem asymetrycznym. Strona odbierająca odszyfrowuje rekordy, a następnie sprawdza ich integralność. Następnie rekordy są dekompresowane i defragmentowane.
Protokół SSL Handshake pozwala na uwierzytelnienie każdej ze stron. Protokół ten odpowiada również za negocjację parametrów dotyczących szyfrowania i uwierzytelniania oraz za wymianę kluczy kryptograficznych. Realizowane jest to poprzez wymianę serii komunikatów pomiędzy klientem i serwerem. Ustanowiona sesja może być później powielona, co jest istotne podczas zabezpieczania ruchu HTTP. Zwykle bowiem każdy element strony WWW jest transportowany indywidualnym połączeniem TCP. Kolejną możliwością jest kontynuowanie przerwanej sesji przez określony okres czasu. W przypadku kontynuowania lub duplikacji istniejącej sesji stosowana jest skrócona wymiana komunikatów (ang. abbreviated handshake). Działanie protokołu Handshake można podzielić na cztery etapy.
Połączenie rozpoczynane jest przez klienta przesłaniem wiadomości „Client Hello”. Wiadomość ta zawiera następujące informacje:
- wersja (numer wersji protokołu SSL obsługiwanego przez klienta),
- identyfikator sesji (wartość zero w przypadku nowej sesji),
- algorytmy kryptograficzne obsługiwane przez klienta.
W odpowiedzi na żądanie klienta serwer odpowiada wiadomością „Server Hello”. Przesyłany jest nowy lub istniejący identyfikator sesji oraz wybrane przez serwer algorytmy kryptograficzne.
Rysunek 2.19 Negocjowanie zabezpieczeń
Serwer uwierzytelnia się przed klientem przesyłając mu swój certyfikat. Do szyfrowania ustanowionej sesji potrzebne są współdzielone klucze. SSL obsługuje trzy metody ustanawiania kluczy sesyjnych: RSA, Diffie-Hellman, FORTEZZA. W przypadku RSA klucz pre-master jest losowo wybierany przez klienta. Następnie przed wysłaniem do serwera jest on szyfrowany jego publicznym kluczem. Zastosowanie algorytmu Diffiego-Hellmana umożliwia wynegocjowanie wspólnego, tajnego klucza, nawet jeśli obie strony porozumiewają się poprzez niezabezpieczony kanał [6]. Protokół SSL umożliwia również uwierzytelnianie klienta. W tym przypadku serwer wysyła do klienta żądanie uwierzytelnienia. Ciąg wiadomości serwera kończy „Server Hello Done”.
Rysunek 2.20 Uwierzytelnianie serwera i wymiana kluczy
Klient wykorzystuje przesłane informacje w celu uwierzytelnienia serwera. Kiedy serwer nie może być uwierzytelniony to ostrzegany jest o tym problemie użytkownik i może on przerwać nawiązywanie połączenia. Następnym krokiem jest sprawdzenie czy serwer wymaga uwierzytelniania klienta. Jeśli tak, to klient wysyła mu swój certyfikat wraz z wiadomością podpisaną prywatnym kluczem. Potem uzgadniany jest klucz pre-master.
Rysunek 2.21 Uwierzytelnianie klienta i wymiana kluczy
Serwer uwierzytelnia klienta. Następnie obie strony generują klucz master na podstawie klucza pre-master. Klucz master jest z kolei wykorzystywany do utworzenia kluczy sesji. Są to symetryczne klucze wykorzystywane później do szyfrowania i odszyfrowywania danych wymienianych w trakcie trwania sesji SSL. Używane są one również do sprawdzania integralności przesyłanych danych. Obie strony informują się nawzajem, że dalsza komunikacja będzie szyfrowana kluczami sesyjnymi. Na koniec przesyłane są zaszyfrowane wiadomości informujące o zakończeniu działania protokołu Handshake.
Rysunek 2.22 Zakończenie protokołu Handshake
Oficjalnie protokół TLS (ang. Transport Layer Security) powstał na podstawie SSL, SSH i PTC (ang. Private Communication Technology) [10]. Protokół PTC był rozwijany przez firmę Microsoft po wykryciu pewnych słabości w wersji 2 protokołu SSL. Po opublikowaniu specyfikacji TLS 1.0 okazało się jednak, że protokół ten jest bardzo podobny do SSL 3.0. Wprowadzono niewielkie zmiany, ale sposób działania TLS i SSL jest taki sam.