Jeśli kiedykolwiek przeglądałeś URL HTTPS przez przeglądarkę, doświadczyłeś SSL handshake. Nawet jeśli może nie zauważyć, przeglądarki i strony internetowej jest tworzenie połączenia HTTPS przy użyciu jednokierunkowego SSL handshake.
Głównym celem SSL handshake jest zapewnienie prywatności i integralności danych do komunikacji między serwerem a klientem. Podczas Handshake, serwer i klient wymieniają ważne informacje wymagane do ustanowienia bezpiecznego połączenia.
Istnieją dwa rodzaje handshake’ów SSL opisanych jako jednokierunkowy SSL i dwukierunkowy SSL (Mutual SSL). Różnica między nimi polega na tym, że w jednokierunkowym SSL, tylko klient sprawdza tożsamość serwera, podczas gdy w dwukierunkowym SSL, zarówno serwer jak i klient sprawdzają tożsamość siebie nawzajem. Zazwyczaj, gdy przeglądamy stronę internetową HTTPS, używany jest jednokierunkowy SSL, gdzie tylko nasza przeglądarka (klient) sprawdza tożsamość strony (serwera). Dwukierunkowy SSL jest najczęściej używany w komunikacji serwer-serwer, gdzie obie strony muszą potwierdzić tożsamość siebie nawzajem.
Podczas SSL handshake, serwer i klient wykonują poniższy zestaw kroków.
1. Client Hello
Klient wyśle informacje, które będą wymagane przez serwer do rozpoczęcia połączenia HTTPS.
W powyższym logu widzimy, że klient przywitał się z TLS v1.2. W ten sposób klient powiadamia serwer, że posiada wsparcie dla TLS w wersji 1.2 i niższych. Lista szyfrów, które są obsługiwane przez klienta może być również widoczna w powyższym logu. Z tej listy serwer wybierze zestaw szyfrów, które obsługuje. Jeśli na liście znajdują się szyfry, których serwer nie rozpoznaje, nie obsługuje lub nie chce używać, wówczas serwer zignoruje te szyfry. Jeśli nie zostaną znalezione żadne obsługiwane szyfry, serwer wyśle komunikat o niepowodzeniu i zamknie połączenie.
2. Server Hello
Serwer odpowie konfiguracją wybraną w Client Hello wraz z informacjami umożliwiającymi kontynuację handshake. Server Hello będzie wyglądało następująco.
Serwer wybierze wersję TLS zgodnie z niższą z sugerowanych przez klienta w wiadomości Client Hello i najwyższą obsługiwaną przez serwer. Serwer odeśle również pakiet szyfrów, który wybrał z listy szyfrów przedstawionej przez klienta.
Wraz z Server Hello, serwer prześle również certyfikat serwera wraz z łańcuchem certyfikatów. Łańcuch certyfikatów zostanie zweryfikowany względem certyfikatów w sklepie zaufania klienta.
3. Server Key Exchange Message
Ta wiadomość zostanie wysłana przez serwer do klienta zawierając wymagane szczegóły dla klienta w celu wygenerowania pre-master secret. Ta wiadomość nie będzie wysyłana, jeśli używany jest algorytm wymiany klucza RSA (więcej na ten temat później) lub jakikolwiek inny algorytm wymiany klucza, który nie wymaga informacji od serwera do wygenerowania pre-master secret.
W przypadku wymiany klucza Elliptic Curve Diffie Hellman(ECDH), następujące szczegóły dotyczące klucza publicznego ECDH serwera są przesyłane do klienta.
4. Żądanie certyfikatu
Jest to miejsce, w którym jednokierunkowy SSL różni się od dwukierunkowego SSL. W jednokierunkowym SSL, autentyczność klienta nie jest sprawdzana. Dlatego ten krok jest pomijany w jednokierunkowym SSL.
W tym kroku serwer wysyła żądanie certyfikatu od klienta z typem certyfikatu, algorytmami podpisu certyfikatu i urzędami certyfikacji obsługiwanymi przez serwer. Mogą zdarzyć się sytuacje, w których lista urzędów certyfikacji może być pusta. W takich scenariuszach klient może wybrać, czy chce wysłać lub uniknąć wysłania certyfikatu klienta (zależy od implementacji klienta)
Na koniec serwer wysyła wiadomość Server Hello Done wskazującą na zakończenie Server Hello. Po wysłaniu tego komunikatu serwer będzie oczekiwał na odpowiedź klienta.
5. Certyfikat klienta
Klient przedstawia serwerowi swój łańcuch certyfikatów. Certyfikat musi być odpowiedni dla wynegocjowanego algorytmu wymiany kluczy pakietu szyfrów oraz wszelkich wynegocjowanych rozszerzeń.
6. Client Key Exchange Message
Ta wiadomość musi być wysłana przez klienta po wiadomości Client Certificate. Jeśli certyfikat klienta nie jest prezentowany (w jednokierunkowym SSL), wiadomość Client Key Exchange powinna być wysłana po otrzymaniu przez klienta wiadomości ServerHelloDone.
Jak wiadomo dane przesyłane pomiędzy serwerem a klientem w połączeniu HTTPS będą zaszyfrowane. Szyfrowanie symetryczne jest używane do tego celu, ponieważ koszt obliczeniowy jest znacznie niższy niż szyfrowanie asymetryczne. Aby użyć szyfrowania symetrycznego, musi istnieć wspólny klucz pomiędzy dwoma końcami. Celem tej wiadomości jest wygenerowanie tego wspólnego klucza pomiędzy klientem a serwerem bez ujawniania go osobom postronnym.
W specyfikacji TLS v1.2 opisane są dwie metody wymiany klucza klienta. Są to RSA i Diffie-Hellman.
Jeśli RSA jest używany jako algorytm wymiany klucza, klient generuje 48-bajtowy sekret pre-master. Klient szyfruje sekret pre-master za pomocą klucza publicznego certyfikatu i wysyła do serwera. Tylko serwer będzie miał odpowiedni klucz prywatny, aby odszyfrować i uzyskać wygenerowany przez klienta sekret główny.
Jeśli używany jest algorytm Diffie-Hellman, parametry Diffie-Hellman są przekazywane, aby umożliwić zarówno klientowi, jak i serwerowi wygenerowanie tego samego sekretu głównego.
Potem obie strony wygenerują sekret główny przy użyciu sekretu głównego, a sekret główny zostanie użyty do wygenerowania klucza symetrycznego do zaszyfrowania danych sesji
7. Finished
Po udanym uwierzytelnieniu i wygenerowaniu pre-master secret/master secret, zarówno klient jak i serwer wyślą wiadomość change cipher spec wskazującą, że reszta komunikacji będzie zaszyfrowana.
Komunikat Finished nastąpi bezpośrednio po wiadomości change cipher spec. Będzie to pierwsza wiadomość zaszyfrowana przy użyciu wynegocjowanych algorytmów. Dane aplikacji zostaną przesłane dopiero po wysłaniu przez obie strony komunikatu finished i zweryfikowaniu treści komunikatu.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/