Technologie zapewniające bezpieczeństwo w systemach operacyjnych.

SSL - secure sockets layer

Protokół SSL

Transmission Control Protocol/Internet Protocol (TCP/IP) jest protokołem odpowiedzialnym za transmisję danych w Internecie. Inne protokoły jak HyperText Transport Protocol (HTTP), Lightweight Directory Access Protocol (LDAP) czy Internet Messaging Access Protocol (IMAP), są ponad TCP/IP - używają TCP/IP przy dostarczaniu innych usług, jak wyświetlanie stron www czy zarządzanie serwerami email.

Tymczasem protokół SSL działa pomiędzy TCP/IP a protokołami wyższego rzędu. Pośredniczy on pomiędzy niskopoziomową transmisją w sieci a aplikacjami na poziomie użytkownika, aby zapewnić bezpieczeństwo usług w sieci.

SSL dostarcza trzy podstawowe funkcje:

• uwierzytelnianie serwera - zapewnia użytkownikowi, że dany serwer jest wiarygodny, że jego certyfikat został wydany przez CA znajdujące się na liście zaufanych CA u klienta; ta funkcja jest istotna np. podczas wysyłania przez klienta numeru karty kredytowej do serwera banku;
• uwierzytelnianie klienta - na tej samej zasadzie co uwierzytelnianie serwera - pozwala serwerowi zweryfikować tożsamość klienta poprzez sprawdzenie czy CA, które wydało certyfikat klienta znajduje się na liście zaufanych CA serwera; ta funkcja jest istotna np. podczas przesyłania poufnych informacji przeznaczonych dla określonego klienta;
• szyfrowanie przesyłanych danych - które są następnie rozszyfrowane przez odbiorcę; przez sieć przechodzi informacja zakodowana i zabezpieczona przez haszowanie.

Algorytmy szyfrujące w SSL

Protokół SSL używa szeregu różnych algorytmów szyfrujących. Również klienci i serwery mogą obsługiwać określone algorytmy lub zbiory algorytmów, zależnie od oprogramowania, siły kodowania, wymagań prawnych czy wymagań danej firmy. W początkowym "uścisku dłoni" (handshake) klient i serwer ustalają m. in. które algorytmy będą użyte przy uwierzytelnianiu, przesyłaniu certyfikatów i ustalaniu kluczy dla danej sesji.

Używane algorytmy to:

• DES Data Encryption Standard,
• DSA Digital Signature Algorithm - część procesu uwierzytelniania,
• KEA Key Exchange Algorithm - do wymiany kluczy,
• MD5 Message Digest - algorytm kompresji,
• RC2 i RC4 algorytmy szyfrowania oparte na RSA,
• RSA algorytm szyfrowania z kluczem publicznym, używany zarówno do szyfrowania jak i uwierzytelniania,
• RSA key exchange wymiana kluczy oparta na RSA,
• SHA-1 Secure Hash Algorithm - funkcja haszująca,
• SKIPJACK algorytm szyfrujący z kluczem symetrycznym,
• Triple-DES potrójnie zastosowany DES.

SSL 2.0 i SSL 3.0 pozwalają administratorom na wybór algorytmów, których będzie używał dany serwer. Administrator, chcąc zapewnić bezpieczeństwo swojego serwisu, może wyłączyć komunikację z użyciem słabszych algorytmów kodowania. Z drugiej strony, jeśli chce udostępnić dany serwer do użytku większej liczbie klientów, może pozwolić na użycie szerszej gamy algorytmów, a podczas komunikacji klient i serwer ustalą najsilniejszy algorytm jaki obie strony potrafią obsłużyć.

Handshake

Protokół SSL używa kombinacji szyfrowania z kluczem publicznym i symetrycznym. Początkowy "uścisk dłoni" pozwala na uwierzytelnienie klienta i serwera techniką z kluczem publicznym i następnie współpracę w celu stworzenia kluczy symetrycznych do szyfrowania i rozszyfrowywania informacji oraz wykrywania cudzej ingerencji w treść przesyłanych komunikatów.

Uścisk dłoni przebiega według następującego schematu:

1. Klient wysyła serwerowi numer swojej wersji SSL, ustawienia algorytmu kodującego, jakieś losowe dane i inne informacje, które serwer potrzebuje do komunikacji z klientem przez SSL.
   
   
2. Serwer przesyła klientowi numer swojej wersji SSL, ustawienia algorytmu szyfrującego, i inne informacje jakie klient potrzebuje do komunikacji z serwerem przez SSL. Serwer przesyła również swój certyfikat i - jeśli klient żąda zasobu, który wymaga uwierzytelnienia odbiorcy - również zapytanie o certyfikat klienta.
   
   
3. Klient używa informacji przesłanej przez serwer do uwierzytelnienia serwera (opisane niżej). Jeśli serwer nie może zostać uwierzytelniony, komunikacja zostaje zerwana, jeśli może to klient kontynuuje (punkt 4).
   
   
4. Klient szyfruje za pomocą klucza publicznego serwera pewne wstępne dane (premaster secret) i przesyła je do serwera.
   Jeśli serwer żądał uwierzytelnienia klienta, klient wysyła swój certyfikat razem z podpisem elektronicznym (czyli z losowymi danymi unikatowymi dla tej sesji, znanymi obu stronom komunikacji, zaszyfrowanymi kluczem prywatnym klienta).
   
   
5. Jeśli serwer żądał uwierzytelnienia klienta, sprawdza przysłane przez klienta dane (opis niżej), jeśli klient nie może zostać uwierzytelniony, komunikacja zostaje zerwana. Jeśli sesja trwa dalej, serwer używa swojego klucza prywatnego do rozkodowania danych przesłanych przez klienta (premaster secret), a następnie wykonuje szereg kroków w celu wygenerowania tzw. master secret. Te same kroki wykonuje równocześnie klient.
   
   
6. Master secret jest używany przez serwer i klienta do wygenerowania kluczy sesji - symetrycznych kluczy do szyfrowania i rozszyfrowywania danych i do zapewnienia ich integralności (wykrywania cudzej ingerencji w treść przesyłanych komunikatów).
   
   
7. Klient przesyła serwerowi komunikat o gotowości swojego klucza i oddzielny, zaszyfrowany komunikat, że etap "uścisku dłoni" po stronie klienta zakończył się.
   
   
8. Serwer przesyła klientowi komunikat o gotowości swojego klucza i oddzielny, zasyzfrowany komunikat, że etap "uścisku dłoni" po stronie serwera zakończył się.
   
   
9. Etap "uścisku dłoni" zakończył się, teraz klient i serwer używają wygenerowanego klucza do przesyłania informacji między sobą.

Uwierzytelnienie serwera

Protokół SSL wymaga uwierzytelnienia serwera w każdej sesji. Klient dokonuje tego w czterech krokach:

1. Czy przedział czasu dla ważności certyfikatu obejmuje aktualną datę? Jeśli nie, komunikacja zostaje zerwana.
   
   
2. Czy CA, które wydało ten certyfikat jest wiarygodnym CA? Każdy klient trzyma u siebie listę wiarygodnych CA, jeśli znajduje się na niej DN (distinguished name) danego serwera to uwierzytelnianie jest kontynuowane, jeśli nie, to jest on szukany w łańcuchu CA, do momentu znalezienia tego, którego DN znajduje się na liście zaufanych CA klienta.
   
   
3. Czy klucz publiczny wydawcy certyfikatu serwera (lub certyfikatu tego CA który się znalazł na końcu przeszukiwanego łańcucha CA) zatwierdza podpis elektroniczny tego CA (zawarty w jego certyfikacie)? Klient za pomocą klucza publicznego z trzymanej u siebie listy zaufanych CA weryfikuje podpis elektroniczny dołączony do certyfikatu serwera (lub sprawdzanego CA). Wszelka rozbieżność powoduje zerwanie połączenia.
   
   
4. Czy nazwa domeny na certyfikacie serwera zgadza się z domeną samego serwera? Nie jest to technicznie częścią protokołu SSL ale zapobiega niebezpieczeństwu Man-in-the-Middle - programowi, który umiejscawia się pomiędzy serwerem i klientem , generuje odrębny zestaw kluczy dla każdego z nich i pośredniczy w komunikacji, dając złudzenie obu stronom, że komunikują się bezpośrednio ze sobą.

Po tych krokach uwierzytelnienia, serwer musi jeszcze skutecznie rozszyfrować swoim kluczem prywatnym premaster secret przesłany przez klienta. Jeśli to się nie powiedzie, serwer nie wygeneruje tego samego klucza symetrycznego co klient i komunikacja nie powiedzie się. Przesłanie premaster secret jest zatem kolejną częścią procesu uwierzytelnienia.

Uwierzytelnienie klienta

Serwer SSL może zostać skonfigurowany tak, by wymagał uwierzytelnienia klienta. Komunikując się z takim serwerem, klient musi mu przesłać swój certyfikat i podpisane elektronicznie dane (punkt 4 uścisku dłoni). Uwierzytelnienie klienta odbywa się według następującego schematu:

1. Czy klucz publiczny klienta potwierdza jego podpis elektroniczny? Serwer sprawdza zgodność podpisu klienta z kluczem publicznym w jego certyfikacie.
   
   
2. Dalszy ciąg weryfikacji odbywa się według schematu dla uwierzytelnienia serwera (punkty 1 - 3).
   
   
3. Czy certyfikat klienta znajduje się w serwerze LDAP? Jest to opcjonalny krok pozwalający na dodatkową weryfikację okresu ważności certyfikatu klienta, ponieważ niektóre serwery mogą samodzielnie określać te przedziały ważności dla swoich klientów.
   
   
4. Czy dany klient ma prawo dostępu do żądanych zasobów? Ostatni krok weryfikacji polega na sprawdzeniu praw dostępu tego klienta w ACL (access control lists) i ustala połączenie według określonych praw.