
Po co nam certyfikaty SSL / TLS?
Cześć! W tym wpisie chciałbym podzielić się z Wami wiedzą na temat działania certyfikatów SSL/TLS. Dlaczego są one istotne, do czego służą urzędy certyfikujące, co to jest tzw. „Chain of Trust”, jaka jest różnica między kluczami symetrycznymi, a asymetrycznymi. Temat ten może wydawać się dość złożony, ale postaram się przedstawić go w sposób zrozumiały korzystając z ilustracji, aby lepiej zobrazować komunikację pomiędzy poszczególnymi elementami tego procesu. Na zakończenie przeanalizujemy jeden z prawdziwych certyfikatów i omówimy jego kluczowe elementy. Zapraszam!
Spis treści
HTTP vs HTTPS
Zanim zajmiemy się szczegółowym omówieniem certyfikatów w pierwszej kolejności warto zrozumieć, dlaczego są one niezbędne. Jak wszyscy wiemy komunikacja ze stronami internetowymi może odbywać się poprzez protokół HTTP lub HTTPS gdzie litera 'S’ oznacza 'secure’ (bezpieczny). W pasku adresu większości przeglądarek często możemy zauważyć małą kłódkę, która sygnalizuje, że strona jest bezpieczna. To oznacza, że połączenie z daną stroną jest szyfrowane.

Wiem, że większość z Was dobrze wie o co chodzi, ale warto przypomnieć, że połączenia HTTP nie są szyfrowane. Oznacza to, że każdy, kto przechwyci takie komunikaty, może mieć pełny wgląd we wszystko, co przesyłamy przez internet – nasze nazwy użytkowników, hasła, dane karty płatniczej itp. Dlatego istotne jest, abyśmy zawsze byli świadomi tego, co dzieje się w sieci podczas przeglądania internetu. Obecnie przeglądarki często same ostrzegają nas, gdy strona nie zapewnia szyfrowanego połączenia.
Klucz symetryczny i asymetryczny
W procesie szyfrowania naszego połączenia z docelową stroną internetową biorą udział dwa rodzaje kluczy szyfrujących: symetryczne i asymetryczne. Klucz symetryczny to taki, który umożliwia zarówno zaszyfrowanie, jak i późniejsze odszyfrowanie tej samej wiadomości. Natomiast klucz asymetryczny składa się z pary kluczy (key pair), z których jeden służy do szyfrowania wiadomości (zazwyczaj jest to klucz publiczny), a drugi (klucz prywatny) do ich odszyfrowywania. Klucz publiczny, jak sama nazwa wskazuje może być swobodnie dystrybuowany, ponieważ jego ujawnienie jest bezpieczne – służy jedynie (w większości przypadków) do zaszyfrowywania wiadomości.
A co gdyby nie było certyfikatów ?
Aby odpowiedzieć na pytanie po co potrzebujemy certyfikatów SSL przedstawię przykład, w którym zobrazowany będzie proces komunikacji użytkownika z przeglądarką, gdyby certyfikaty nie istniały. Uprzedzam, że poniższe rysunki nie obejmują szczegółowej wymiany komunikacji między klientem, a serwerem. Są jedynie ogólnym schematem mającym na celu zrozumienie odgrywanych ról poszczególnych elementów.
Happy Path
Poniżej w punktach wypisałem co dzieje się gdy Pan Jan Kowalski chce wejść na swoją ulubioną stronę internetową w przypadku, w którym nie istniałyby certyfikaty.
- Użytkownik chce wejść na stronę X, żądanie wędruje po internecie i dociera do serwera strony X, który przetwarza żądanie.
- Serwer zwraca do przeglądarki swój klucz publiczny, który zostanie użyty do zaszyfrowania połączenia.
- Następnie przeglądarka odsyła swój klucz asymetryczny zaszyfrowany publicznym kluczem serwera. Dzięki temu klucz przeglądarki jest bezpieczny podczas przesyłania do serwera, ponieważ w przypadku przechwycenia przez osobę trzecią, nie będzie ona w stanie go wykorzystać. Wymagałoby to posiadania klucza prywatnego, który jest dostępny tylko dla serwera.

- Serwer wykorzystując klucz prywatny odszyfrowuje wiadomość.
- Serwer informuje przeglądarkę, że posiada jej asymetryczny klucz oraz, że można nawiązać obustronne bezpieczne połączenie.

To połączenie wydaje się być bezpieczne. Przeglądarka i serwer mogą ze sobą rozmawiać, a potencjalny złodziej nie byłby w stanie podsłuchać wiadomości gdyż połączenie w jedną i w drugą stronę jest zabezpieczone. Po co nam zatem certyfikaty?
Man-in-the-middle (MitM) attack
Rozważmy inny scenariusz. W tym przypadku osoba trzecia mogła chwilowo przekierować nasze początkowe żądanie tak, że zostało ono skierowane na fałszywą stronę.
- Przeglądarka odpytuje system DNS o adres IP, gdzie znajduje się witryna X, w wyniku manipulacji zwrócony został fałszywy adres IP hosta.
- Fałszywy serwer zwraca klucz publiczny, który użytkownik użyje do zaszyfrowania swojego klucza asymetrycznego.
- Przeglądarka wysyła zaszyfrowany klucz asynchroniczny do fałszywego serwera. Osoba trzecia wchodzi w posiadanie klucza asynchronicznego przeglądarki.

- Następuje ponowne przekierowanie do prawdziwego serwera strony oraz ponowna wymiana kluczy i nawiązanie szyfrowanego połączenia.
Różnica jest taka, że tym razem osoba trzecia jest w stanie odszyfrować przechwycone wiadomości.

Wszystkie te kroki dzieją się transparentnie dla użytkownika i zajmują zazwyczaj ułamki sekund. Opisana powyżej metoda wyłudzenia danych ma swoją nazwę – jest to atak typu man-in-the-middle. W takim razie, jak się przed tym bronić?
Certificate authoryty
Odpowiadając na pytanie „po co nam te certyfikaty” można powiedzieć, że służą one do zapewnienia, że dany klucz publiczny pochodzi z prawidłowego serwera, a nie z fałszywego. Instytucje certyfikujące (Certificate Authority – CA) to zaufane podmioty, którym przeglądarki ufają. Aby stać się takim podmiotem trzeba spełnić szereg rygorystycznych i skomplikowanych wymagań. Na tej stronie znajdziemy listę największych CA które znaczoąco pokrywają cały rynek. Nie trudno zauważyć, że lista jest dość krótka.
Proces certyfikacji
Zanim przejdziemy do właściwego mechanizmu komunikacji między klientem, a serwerem z wykorzystaniem certyfikatów warto wspomnieć o procesie uzyskiwania certyfikatu przez serwer. Zawartych jest w nim bowiem kilka ważnych operacji. Poniżej generalny opis tego procesu.
- Serwer wysyła do urzędu certyfikacji prośbę o podpis certyfikujący pod swoim kluczem publicznym.
- CA sprawdza czy my jesteśmy właścicielem domeny. Może to zrobić na różne sposoby: prosząc nas o umieszczanie danej informacji w rekordzie domeny lub kontaktując się bezpośrednio z firmą. CA szyfruje swoim kluczem prywatnym (to bardzo ważny krok dlatego powtórzę: swoim kluczem prywatnym, a nie publicznym) nasz klucz publiczny. Następnie przygotowuje certyfikat, w którym znajdują się m.in.: informacje kto go wydał, dla kogo został wydany, nasz zaszyfrowany klucz publiczny, termin ważności certyfikatu i kilka innych danych.
- Certyfikat jest odsyłany do podmiotu, który sie o niego ubiegał.

Prawdziwa komunikacja ze stroną po https
Opiszę teraz jak wygląda cały proces komunikacji. Nasza domena posiada już certyfikat podpisany przez CA.
- Przegladarka internetowa wysyłając żadnie do strony prosi o jej certyfikat.
- Serwer zwraca podpisany certyfikat, w którym zawarty jest m.in. jej zaszyfrowany klucz publiczny.
- Przegladarka w razie konieczoności odpytuje CA o jej publiczny klucz.
- CA zwraca swój klucz publiczny, który posłuży do odszyfrowania zaszyfrowanego klucza serwera.

Następnie, gdy przeglądarka otrzymuje klucz publiczny CA deszyfruje nim zaszyfrowany klucz publiczny serwera, co prowadzi do uzyskania klucza publicznego serwera. Przeglądarka porównuje oba klucze (rozszyfrowany i publiczny serwera) i jeśli są one zgodne wówczas oznacza to, że certyfikat jest ważny, ponieważ zaszyfrować mogła go tylko prawdziwa i legalnie działająca instytucja certyfikująca.

Dodam, że klucze publiczne CA i serwera mogą być przechwycone, ponieważ, jak już wspomniałem na początku służą one jedynie do weryfikacji poprawności certyfikatu lub szyfrowania połączenia, więc ich wyciek nie stanowi zagrożenia.
Brawo! Dotarliśmy do końca! Mam nadzieję, że zrozumieliście jaką role odgrywa CA w tej układance, oraz dlaczego klucz prywatny jest używany do szyfrowania w przeciwieństwie do domeny, która używa w tym celu klucza publicznego.
Chain of Trust
Wracając jeszcze do tematu CA. Jak łatwo można się domyślić, ponieważ mamy tylko kilka/kilkanaście urzędów certyfikujących na całym świecie, każdy z CA ma wiele domen, które są przez niego certyfikowane. Klucze prywatne takich CA nie mogą wpaść w niepowołane ręce i muszą być bardzo bardzo dobrze zabezpieczone, ponieważ ewentualny wyciek byłby katastrofą. Z tego powodu, aby nieco odsunąć CA od czyhających zagrożeń wymyślono pośrednie urzędy certyfikacji (Intermediate Certificate Authority – ICA), które sprawiają, że domeny nie kontaktują się bezpośrednio z głównymi CA (tzw. Root CA) w celu uzyskania certyfikatów.
Działa to tak, że zwykła domena prosi o certyfikację ICA, która podpisuje się pod naszym kluczem publicznym, podobnie jak wcześniej. Z kolei ICA podpisuje swój klucz publiczny w Root CA, dzięki czemu przeglądarka może również sprawdzić wiarygodność ICA. Root CA także posiada swój certyfikat potwierdzający wiarygodność, który jest podpisany przez niego samego, ponieważ to on stoi na samym szczycie zaufania. Przeglądarka sprawdza wszystkie 3 poziomy certyfikacji: serwera (najniższy), ICA (pośredni) oraz CA Root (najwyższy).

Na powyższym obrazku zaznaczyłem, którym kluczem możemy zweryfikować odpowiedni certyfikat. W tym przypadku do sprawdzenia certyfikatu serwera użyjemy klucza publicznego ICA, natomiast aby zweryfikować wiarygodność certyfikatu ICA skorzystamy z klucza publicznego Root CA. Sam certyfikat dla Root CA będzie podpisany przez niego samego, więc użyjemy klucza publicznego Root do weryfikacji.
Warto wiedzieć
Występuje kilka rodzajów certyfikatów, z którymi jako devops możemy się spotkać. Zazwyczaj będą to certyfikaty wielodomenowe (Multi-Domain Certificate lub Subject Alternative Name Certificate), które pozwalają na zabezpieczenie różnych domen. Mamy też certyfikaty tzw. Wildcard (np. *.red-devops.pl), które służą do zabezpieczenia wszystkich subdomen danej domeny. Rzadziej spotykane są certyfikaty dla pojedynczych domen. Istnieje jeszcze kilka innych rodzajów, ale uważam, że ta wiedza jest wystarczająca.
Warto wiedzieć, że im wyższy jest poziom certyfikatu, tym zazwyczaj dłuższy jest jego okres ważności. Np. zwykłe certyfikaty dla serwerów ubiegajacych się ICA są ważne od kilku miesięcy do zazwyczaj roku, ale istnieją także certyfikaty o kilkuletnim okresie ważności. Okres ważności certyfikatu dla ICA zazwyczaj wynosi od kilku do kilkunastu lat, natomiast certyfikat CA ma okres ważności nawet do 20 lat.
Na koniec chciałbym przyjrzeć się certyfikatowi jednej ze stron internetowych. Na tapetę bierzemy certyfikat strony https://www2.deloitte.com/.

W zakładce „General” znajdziemy informacje takie jak: dla kogo został wydany certyfikat, kto jest jego wydawcą, daty ważności certyfikatu oraz użyty algorytm szyfrowania do zabezpieczenia klucza publicznego.

Po przejściu do zakładki „Details” możemy sprawdzić więcej informacji na temat całego łańcucha certyfikacji, zawartych rozszerzeń certyfikatu, takich jak alternatywne nazwy domen, które są uwzględnione w tym certyfikacie i wiele innych informacji.

Przy okazji sprawdzając certyfikat Root CA, czyli w tym przypadku DigiCert Global Root CA zauważymy, że został on wystawiony przez niego samego, tak jak to widać na powyższym rysunku. Zachęcam do samodzielnego sprawdzenia 🙂
Na koniec chciałbym dodać, że pola zawarte w certyfikatach są ściśle określone przez standard X.509, z którym wcześniej lub później spotkacie się w pracy.
Podsumowanie
Mam nadzieję, że zawarta w tym artykule wiedza pomoże Wam zrozumieć mechanizmy kryjące się za certyfikatami SSL/TLS. Starałem się przedstawić poszczególne kroki tego procesu w jak najprostszy sposób, czasami pomijając niektóre mikrodetale, które z mojego punktu widzenia są zbędne, jeśli chcemy ogólnie poznać sposób działania. Niemniej jednak, główny sens został zachowany. Dodatkowo, przedstawiłem kilka ciekawych informacji na temat rodzajów certyfikatów, a na końcu pokazałem prawdziwy certyfikat ilustrując to, o czym wcześniej mówiliśmy.