Zanim protokoły warstwy aplikacji będą mogły wymieniać dane w bezpieczny sposób, musi nastąpić nawiązanie sesji SSL (ang. SSL handshake). Na SSL handshake składa się kilka faz negocjacji, które przedstawiono kolejno w punktach.

1. Klient łączy się z serwerem i wysyła pakiet początkowy Hello, a wraz z nim numer obsługiwanej wersji SSL, obsługiwane algorytmy szyfrujące, algorytmy kompresji oraz losowy numer związany z rozpoczętą sesją (ID).

2. Serwer w odpowiedzi wysyła klientowi numer obsługiwanej wersji SSL, obsługiwane algorytmy szyfrujące, a także swój certyfikat (klucz publiczny).

3. Na tym etapie klient sprawdza certyfikat serwera — czy jest ważny oraz czy wystawił go zaufany urząd (CA). Protokół SSL przewiduje także możliwość wysłania przez serwer żądania o uwierzytelnienie klienta. Uwierzytelnianie to jest opcjonalne i stosuje się je w określonych warunkach.

4. W przypadku pozytywnego uwierzytelnienia serwera klient generuje 48-bajtową liczbę zwaną „pre-master secret” i szyfruje ją, używając przy tym klucza publiczne go serwera (zawartego w certyfikacie serwera). Liczba „pre-master” składa się z 2 bajtów identyfikujących klienta oraz 46 bajtów losowych.

5. Serwer po otrzymaniu liczby „pre-master” odszyfrowuje ją, używając do tego swojego klucza prywatnego, i porównuje pierwsze 2 bajty identyfikujące klienta z danymi, które otrzymał w inicjacyjnym pakiecie Hello.

6. Jeśli jest wymagane uwierzytelnienie klienta, jest to robione w tej chwili. Wówczas klient musi przesłać swój certyfikat.

7. Na podstawie już wymienionych danych (m.in. pre-master key, losowe dane wygenerowane w punkcie 1.) serwer i klient generują tzw. master key (znany tylko im).

8. Zarówno klient, jak i serwer na podstawie master-key generują symetryczne klucze sesyjne, które umożliwiają im szyfrowanie i sprawdzanie integralności przesyłanych danych.

9. Kończąc handshake, klient przesyła do serwera wiadomość zaszyfrowaną ustalonym kluczem sesyjnym. Wiadomość ta, nazywana końcowym uzgodnieniem (ang. finished handshake), jest jako pierwsza szyfrowana tajnym kluczem.

10. Serwer odpowiada także wiadomością zaszyfrowaną za pomocą wspólnego klucza. Od tej pory sesja SSL jest nawiązana.

Co w praktyce oznacza, że dany certyfikat jest zaufany?
Oznacza to tylko (aż) tyle, że został wystawiony przez wiarygodne (zaufane) Centrum Certyfikacji CA. Wszystkie popularne przeglądarki internetowe, programy pocztowe i inne aplikacje korzystające z protokołu SSL mają „zaszytą” w sobie na stałe listę zaufanych wystawców CA (ich certyfikaty). Dzięki temu podczas nawiązywania połą- czenia SSL aplikacja nie zgłasza błędu, rozpoznając, że certyfikat został wystawiony przez któryś z zaufanych CA.
Certyfikaty wystawione przez zaufane CA mają znaczenie głównie dla publicznych serwerów WWW, gdzie rozproszeni po całym świecie klienci muszą mieć pewność, że serwer, z którym się łączą, jest na pewno tym, za jaki się podaje (np. sklep internetowy). W przypadku tworzenia połączeń VPN nic nie stoi na przeszkodzie, abyś stworzył swoje CA i sam wystawiał certyfikaty na własne potrzeby. Możesz przecież ufać certyfikatom, które sam wygenerowałeś, i instalować je na laptopach pracowników. W przeciwieństwie do serwera WWW i przeglądarek internetowych w zastosowaniach VPN-owych często ważne jest uwierzytelnienie klienta przez serwer (bramę VPN). Nie chcemy przecież, aby do sieci korporacyjnej mógł podłączyć się ktokolwiek na świecie posiadający klienta VPN, a jedynie osoby posiadające odpowiednie certyfikaty.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.