Zielona kłódka zdemistyfikowana: jak działa uścisk dłoni SSL?

Codziennie podczas przeglądania sieci z myślą o bezpieczeństwie myślisz o słynnej zielonej kłódce obok adresu URL strony w przeglądarce i wersji protokołu przesyłania danych HTTPS. W tym artykule dowiemy się, dlaczego protokół HTTPS jest naprawdę bezpieczny i jak komunikacja jest chroniona przed podsłuchem przez osoby trzecie.

Najpierw krótko przedstawimy dwie podstawowe koncepcje kryptograficzne: podpis cyfrowy i szyfrowanie. Zagłębimy się w proces zwany uzgadnianiem SSL , który jest wykonywany przed rozpoczęciem wymiany komunikacji między klientem a serwerem i służy do ustanowienia bezpiecznego kontekstu kryptograficznego. Zakończymy informacją o tym, jak jeszcze bardziej zwiększyć bezpieczeństwo za pomocą opcjonalnego kroku zwanego uwierzytelnianiem certyfikatu klienta.

Kryptografia klucza publicznego 101: Para kluczy

Poznaj Alice i Boba, dwie osoby, które zdecydowały się wykorzystać metody kryptograficzne do bezpiecznej wymiany prywatnych wiadomości. Pierwszym wyborem, z którym muszą się zmierzyć, jest wybór pomiędzy dwoma różnymi typami kryptografii: kryptografią z kluczem symetrycznym i asymetrycznym (zwaną również kryptografią z kluczem publicznym).

Ale czekaj, co to za klucze ? Zasadniczo możemy uprościć, że klucz jest losową sekwencją znaków. Możemy użyć tej sekwencji do przekształcenia (wykonania określonej operacji kryptograficznej) na wiadomości – zajmiemy się tym wkrótce.

Kryptografia klucza symetrycznego

Podczas korzystania z krypto klucza symetrycznego nadawca generuje klucz, a następnie duplikuje go dla odbiorcy. Nadawca zapisuje oryginalny klucz, a duplikat jest dostarczany do odbiorcy. Ten sam klucz jest używany do operacji kryptograficznych na obu końcach komunikacji.

Jakie są główne zalety i wady kryptografii klucza symetrycznego?

Kryptografia klucza asymetrycznego

Podczas korzystania z krypto klucza asymetrycznego zarówno nadawca, jak i odbiorca generują parę kluczy – klucz publiczny i klucz prywatny. Klucze są ze sobą matematycznie połączone, aby współpracować w różnych operacjach kryptograficznych. Zarówno nadawca, jak i odbiorca bezpiecznie zapisują swoje klucze prywatne, ale mogą wymieniać klucze publiczne bez specjalnych środków ostrożności. Mogą nawet używać swego rodzaju „żółtych stron z kluczami publicznymi” – serwera kluczy publicznych, aby wysyłać swoje klucze publiczne, aby każdy mógł mieć do nich dostęp.

Jakie są zalety i wady kryptografii klucza asymetrycznego?

Ponieważ asymetryczna konfiguracja krypto jest bezpieczniejsza, Alice i Bob zdecydowali się na to! Teraz mogą to wykorzystać i zacząć myśleć o zapewnieniu bezpieczeństwa i integralności komunikacji.

Kryptografia klucza publicznego 101: Szyfrowanie

Kiedy Alicja wysyła wiadomość do Boba, chce mieć pewność, że nikt inny nie może zobaczyć treści. Postanawia zaszyfrować wiadomość. Aby to osiągnąć, Alicja musi najpierw uzyskać klucz publiczny Boba z serwera kluczy lub bezpośrednio od Boba za pośrednictwem kanału komunikacyjnego. Gdy Alicja uzyska klucz, może zastosować operację szyfrowania przy użyciu klucza publicznego Boba w wiadomości, którą chce wysłać.

Ogólnie rzecz biorąc, w tym procesie wiadomość jest pobierana przez algorytm kryptograficzny (aka szyfr) w blokach (najczęściej) i wykonywane są pewne operacje bitowe między wiadomością a kluczem, co daje wynik, który jest zaszyfrowaną wiadomością (aka tekst zaszyfrowany) . Kiedy Bob otrzymuje zaszyfrowaną wiadomość, jest jedyną osobą, która może ją odszyfrować za pomocą swojego klucza prywatnego.

Notatka:

• Szyfrowanie wiadomości – nadawca szyfruje wiadomość kluczem publicznym odbiorcy
• Odszyfrowanie wiadomości – odbiorca odszyfrowuje wiadomość swoim kluczem prywatnym

Kryptografia klucza publicznego 101: Podpis

Oprócz uniemożliwienia ujawnienia treści wiadomości równie ważna jest możliwość potwierdzenia tożsamości nadawcy i zweryfikowania, czy wiadomość nie została zmieniona. Podpis cyfrowy (osobny obiekt dołączony do wiadomości) jest używany właśnie z tych dwóch powodów.

Alicja najpierw używa algorytmu mieszającego do opracowania skrótu wiadomości, aby wygenerować swój podpis. Haszowanie polega na obliczeniu jednokierunkowej funkcji matematycznej na komunikacie, która daje krótszą, stałą wartość wyjściową – inną dla różnych danych wejściowych. Następnie używa swojego klucza prywatnego do zaszyfrowania (podpisania) wygenerowanego skrótu.

Następnie, gdy Bob otrzyma wiadomość i podpis, może najpierw odszyfrować podpis za pomocą klucza publicznego Alicji . Kiedy to się powiedzie, wie, że podpis naprawdę został wygenerowany przez Alicję (w przeciwnym razie odszyfrowanie za pomocą jej klucza publicznego nie powiedzie się).

Po drugie, Bob może wziąć wiadomość i zahaszować ją przy użyciu tego samego algorytmu, który miała wcześniej Alicja, i potwierdzić, że jego skrót wiadomości jest taki sam, jak ten wygenerowany przez Alicję. Kiedy hashe się zgadzają, wie, że wiadomość nie została naruszona.

Notatka:

• Generowanie podpisu – nadawca szyfruje (podpisuje) hash wiadomości swoim kluczem prywatnym i tworzy podpis
• Weryfikowanie podpisu – odbiorca najpierw odszyfrowuje hash wiadomości z podpisu i sprawdza, czy obliczony przez niego hash zgadza się z hashem z podpisu
• Szyfrowania i podpisu można używać osobno , ale dla najwyższego bezpieczeństwa zwykle łączy się je. Dlatego większość funkcji kryptograficznych, które możesz spotkać, nazywa się encryptSignMessage() , decryptVerifyMessage() , itp.

Mam nadzieję, że nie masz problemów z nadążaniem za historią Alicji i Boba. Pozwolę sobie jeszcze raz zilustrować cały przepływ, aby upewnić się, że wszystko jest jasne i podsumować.

1. Alicja chce wysłać wiadomość do Boba
2. Alicja bierze swój klucz prywatny i generuje podpis
3. Alicja pobiera klucz publiczny Boba i szyfruje wiadomość
4. Alicja wysyła wiadomość do Boba
5. Bob bierze klucz publiczny Alicji i weryfikuje podpis
6. Bob używa swojego klucza prywatnego do odszyfrowania wiadomości

Dobra, dość teorii. Zobaczmy teraz, jak to wszystko jest używane w HTTPS!

Uzgadnianie SSL

Przywitaj się proszę

Kiedy klient inicjuje połączenie z serwerem, najpierw należy dokonać odpowiedniego wprowadzenia w celu ustanowienia kontekstu kryptograficznego dla reszty komunikacji. Można to zrobić w kroku HTTPS CONNECT, przed analizowaniem nagłówków i treści żądania. Wszystko zaczyna się od wysłania przez klienta wiadomości powitalnej .

Co najważniejsze, wiadomość zawiera algorytmy kryptograficzne, które klient rozumie i dodatkowe materiały, takie jak obsługiwane algorytmy kompresji, wersje protokołów, identyfikator sesji itp. Ponieważ serwer lubi być uprzejmy, odpowiada również komunikatem powitania serwera, który jest najbardziej zauważalny zawiera certyfikat serwera z kluczem publicznym serwera (tak, proces opiera się na kryptografii klucza publicznego – tej samej metodzie, którą wybrali Alice i Bob).

Urząd certyfikacji

Teraz czas powitać na scenie naszego kolejnego gościa: urząd certyfikacji (CA). Nazwa brzmi poważnie – ale to tylko podmiot zewnętrzny z dużym uznaniem ulicznym, który jest zasadniczo uważany za godny zaufania na całym świecie. Taka jednostka może zweryfikować tożsamość serwera i umieścić swój podpis cyfrowy wraz z certyfikatem serwera (podobnie jak Alicja, gdy wysyła wiadomość do Boba).

Weryfikacja certyfikatu

Rozważmy teraz tytułową zieloną kłódkę obok adresu URL przeglądarki.

Każdy klient WWW ma dołączoną listę kluczy publicznych znanych i zaufanych urzędów certyfikacji . Być może pamiętacie, że na początku artykułu wspomniałem, że podpis jest generowany przy użyciu klucza prywatnego nadawcy i można go zweryfikować za pomocą klucza publicznego nadawcy. Cóż, dokładnie to robi klient . Przechodzi przez dołączoną listę zaufanych urzędów certyfikacji i sprawdza, czy podpis certyfikatu serwera należy do jednego z zaufanych urzędów certyfikacji. Jeśli tak, to akceptuje certyfikat – i wtedy kłódka zmienia kolor na zielony .

Ale to tylko pierwszy krok, który nie ma jeszcze nic wspólnego z bezpieczeństwem. Każdy może skopiować dowolny certyfikat klucza publicznego, umieścić go na serwerze i zaprezentować łączącemu się klientowi, prawda?

Gdy klient zweryfikuje certyfikat serwera, tworzy klucz symetryczny do szyfrowania komunikacji. Ale, jak wspomniałem na początku, problem z kluczami symetrycznymi polega na tym, że są one podatne na przechwycenie podczas transportu. Na tym etapie klient i serwer nie mają wspólnego kontekstu kryptograficznego. Tak więc klient wysyła klucz symetryczny do serwera, ale najpierw szyfruje go kluczem publicznym serwera. Następnie serwer otrzymuje go i potrzebuje możliwości odszyfrowania go, aby nawiązać bezpieczne połączenie.

Dlatego nawet gdyby ktoś przedstawił skradziony certyfikat klucza publicznego , jest to krok, w którym by się nie powiódł. Prawidłowy klucz prywatny powiązany z kluczem publicznym certyfikatu serwera jest niezbędny do odszyfrowania klucza symetrycznego. Oczywiście nie stanowi to problemu dla legalnego serwera, ponieważ ma on bezpiecznie zapisany klucz prywatny. Może służyć do odszyfrowywania klucza symetrycznego i szyfrowania dalszej komunikacji.

Podsumowując, uzgadnianie SSL to proces, w którym wykorzystywane są zarówno symetryczne, jak i asymetryczne typy kryptografii . Najpierw para kluczy asymetrycznych inicjuje połączenie i zapewnia bezpieczny sposób przemieszczania się klucza symetrycznego. Jak wspomnieliśmy na początku, operacje kryptografii symetrycznej są szybsze, więc korzystanie z niej do całej komunikacji po konfiguracji jest korzystne. Ponadto po ustanowieniu bezpiecznego połączenia jest ono ponownie używane aż do wygaśnięcia, więc konfiguracja klucza asymetrycznego nie jest wykonywana przed każdym żądaniem klienta.

Warto również wspomnieć, że w rzeczywistości certyfikaty nie są podpisywane bezpośrednio przez najbardziej znane zaufane urzędy certyfikacji (tzw. root ). Jednak główne urzędy certyfikacji podpisują certyfikaty pośrednie, które następnie ostatecznie podpisują certyfikat serwera – tworząc w ten sposób łańcuch certyfikatów, który łączący się klient sprawdza, aż do uzyskania prawidłowego podpisu. Z pewnością zapewnia większe bezpieczeństwo – gdy jeden z pośrednich urzędów certyfikacji zostanie naruszony, dotyczy to mniejszej liczby osób.

Walidacja certyfikatu klienta

Teraz jest jeden opcjonalny krok, o którym możemy pokrótce wspomnieć, ponieważ mamy całą wiedzę potrzebną do jego zrozumienia. Serwer można skonfigurować tak, aby żądał i weryfikował certyfikat klienta po ustanowieniu bezpiecznego połączenia w celu uzyskania dodatkowego bezpieczeństwa.

Działa to w ten sam sposób – ale tym razem klient wysyła swój certyfikat , a serwer przegląda ich listę zaufanych urzędów certyfikacji i weryfikuje ją. Warto również zauważyć, że serwer jest pod kontrolą programistów (przeciwnie do klienta, czyli przeglądarki internetowej lub mobilnego systemu operacyjnego), dzięki czemu programiści backendu mogą łatwo modyfikować listę zaufanych certyfikatów.

Sieci korporacyjne powszechnie wykorzystują ten mechanizm. Najczęściej certyfikaty klienta są generowane przez system zarządzania urządzeniami zainstalowany na urządzeniu pracownika i są podpisywane certyfikatem głównym wygenerowanym przez firmę. Ten sam certyfikat jest również dodawany do środowiska zaplecza. W ten sposób korporacyjny backend może łatwo zweryfikować certyfikat, gdy klient się łączy.

Przejrzyjmy nasze rozwiązania backendowe

Czytaj więcej

Teraz, podsumowując, spójrzmy na diagram dla całego przepływu:

Streszczenie

Dotarłeś do końca artykułu! Mamy nadzieję, że rozumiesz już mechanizm implementacji konfiguracji szyfrowania w HTTPS oraz metody aplikacji w procesach podpisywania i szyfrowania.

Ponieważ wiesz, jak to działa, z pewnością powinieneś czuć się pewniej, jeśli chodzi o szyfrowanie danych. Pamiętaj jednak, że zielona kłódka w Twojej przeglądarce nie gwarantuje jeszcze bezpieczeństwa . W kontekście wrażliwym na bezpieczeństwo należy również dokładnie przyjrzeć się certyfikatowi. Jak mówią, uprzedzony jest uzbrojony!