What Is an SSL/TLS Handshake?
An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection. Określa on, jaka wersja SSL/TLS będzie używana w sesji, jaki zestaw szyfrów będzie szyfrować komunikację, weryfikuje serwer (a czasami także klienta) i ustala, że bezpieczne połączenie jest na miejscu przed przesłaniem danych.
To wszystko dzieje się w tle, na szczęście – za każdym razem, gdy kierujesz swoją przeglądarkę na bezpieczną stronę, ma miejsce złożona interakcja, aby upewnić się, że Twoje dane są bezpieczne.
To jest prosta wersja. Można zauważyć, że każdy tuzin opisów będzie mniej więcej w tym formacie, a jednocześnie będzie się różnił szczegółami na kilkanaście różnych sposobów – czasem mylących. Rzućmy wykres, który pokazuje szeroki model tego, jak działa TLS handshake, dobrze?
ZAMÓW TERAZ
Obligatory SSL/TLS Handshake Graphic
Wszystkie strony związane z SSL/TLS mają swoją własną wersję diagramu handshake – oto nasza! (Click to enbiggen.)
Let’s Clear Up Some Confusion, If We Can
Część nieporozumień związanych z tym, jak działają uściski dłoni SSL/TLS jest spowodowana tym, że uścisk dłoni jest tylko wstępem do właściwej, zabezpieczonej sesji. Spróbujmy odnieść się do kilku powszechnych punktów:
Szyfrowanie asymetryczne vs symetryczne
Sam handshake wykorzystuje szyfrowanie asymetryczne – używane są dwa oddzielne klucze, jeden publiczny i jeden prywatny. Ponieważ systemy szyfrowania asymetrycznego mają znacznie wyższy narzut, nie nadają się do zapewnienia pełnego bezpieczeństwa w świecie rzeczywistym. Dlatego też, klucz publiczny jest używany do szyfrowania, a klucz prywatny do odszyfrowywania tylko w czasie handshake’u, co pozwala obu stronom na poufną konfigurację i wymianę nowo utworzonego „klucza współdzielonego”. Sama sesja używa tego pojedynczego klucza współdzielonego do wykonywania szyfrowania symetrycznego, i to jest to, co sprawia, że bezpieczne połączenie jest wykonalne w praktyce (narzut jest znacznie niższy). Tak więc pełna i poprawna odpowiedź na pytanie „Czy szyfrowanie SSL/TLS jest asymetryczne czy symetryczne?” brzmi „Najpierw jedno, potem drugie.”
Co to jest „zestaw szyfrów”?
Sam proces handshake składa się z wielu etapów, z których każdy zarządzany jest według innych zasad. Szczegóły można znaleźć tutaj, ale chodzi o to, że zamiast serii oddzielnych negocjacji tam i z powrotem (o tym, jakich kluczy użyć, jak zaszyfrować sam handshake, jak uwierzytelnić handshake i tak dalej) strony mogą zgodzić się na użycie „zestawu szyfrów” – wcześniej istniejącego wyboru lub zestawu uzgodnionych komponentów. (Należy pamiętać, że szyfrowanie asymetryczne jest kosztowne pod względem czasu i zasobów – użycie zestawu szyfrów jako skrótu przyspiesza sam handshake). Specyfikacja TLS pozwala na całkiem sporą liczbę zestawów szyfrów, a klient i serwer prawie zawsze mają dostęp do takiego, który mogą zastosować.
Podstawowy vs wzajemnie uwierzytelniony handshake
Kolejnym mylącym punktem jest to, że podstawowy model, który opisaliśmy powyżej pozwala klientowi zweryfikować serwer, a zdecydowana większość sesji zabezpieczonych przez TLS tylko tego wymaga. Jednakże, niektóre zestawy szyfrów będą wymagały od klienta przesłania certyfikatu i klucza publicznego w celu wzajemnego uwierzytelnienia obu stron. To dwukierunkowe uwierzytelnienie oczywiście zwiększy obciążenie handshake’u – jednak w niektórych przypadkach (na przykład, gdy dwa banki negocjują bezpieczne połączenie do transferu funduszy) zestaw szyfrów będzie na to nalegał, a dodatkowe bezpieczeństwo jest tego warte.
Różne sesje będą miały różne parametry bezpieczeństwa
Każdy nowy handshake tworzy nową sesję, a ustawienia użyte w jednej z nich mogą się drastycznie różnić od innych w zależności od wybranego zestawu szyfrów. Jest to jeden z powodów istnienia tak wielu różnych iteracji tego przeklętego wykresu handshake, i dlaczego dajemy tutaj dość szeroki przegląd. Wiedz również, że sesje mogą ustawiać parametry, które mogą nie być dokładnie takie, jakich oczekujesz. W zależności od zestawu szyfrów, niektóre kroki mogą być dodane (jak wymóg dwukierunkowego uwierzytelniania) lub nieobecne. W rzeczywistości, istnieją zestawy szyfrów, które negocjują sesję, aby nie używać żadnego szyfrowania. (Tak, wiemy, połączenie HTTPS na porcie 443, które decyduje się na wysyłanie danych w sposób jawny też nie ma dla nas sensu. SSL.com zdecydowanie zaleca, abyś tego nie robił – po prostu bądź świadomy, że jest to w sferze możliwości.)
.