Protokoły stworzone na bazie SSL są coraz szybsze, bezpieczniejsze i doskonalsze koncepcyjnie. Jednak i one nie są i zapewne jeszcze długo nie będą wolne od błędów implementacyjnych.

Wyobraźmy sobie sytuację, że mamy przez telefon przekazać bardzo ważną i poufną informację osobie, której osobiście nie znamy i dysponujemy tylko jej imieniem i nazwiskiem. W tej sytuacji większość ludzi sięga po książkę telefoniczną i odnajduje właściwy numer. Ale wtedy przypominamy sobie, że wiadomość jest poufna i nie chcemy, aby rozmowa była podsłuchana - ani celowo, ani przypadkiem. Telefon komórkowy z szyfratorem powinien to zagwarantować. Dzwonimy. Osoba po drugiej stronie przedstawia się właściwym imieniem i nazwiskiem. Przekazujemy informację i sprawa zakończona.

Czy na pewno? Gdzieś w głębi duszy kołacze się jednak wątpliwość: czy numer w książce telefonicznej rzeczywiście był właściwy? Problem w tym, że poza książką telefoniczną nie istnieje żaden inny sposób weryfikacji tożsamości osoby, z którą kontakt rzeczywiście miał miejsce. Inaczej mówiąc, nie ma nic, co wcześniej łączyłoby nas z tą osobą i teraz pozwalało stwierdzić, czy to rzeczywiście ta osoba. Dochodzimy więc do wniosku, że niezależnie od tego, jakie środki techniczne zastosujemy do ochrony komunikacji, nie możemy mieć pewności, że osoba po drugiej stronie linii jest tą, za którą się podaje.

Analogiczne dylematy występują w sytuacji, gdy program - zwykle przeglądarka - ma nawiązać przez Internet bezpieczne połączenie z serwerem. Zna wprawdzie jego nazwę, nie zna jednak adresu IP - odpytuje więc lokalny serwer DNS. I także tu pojawia się ten sam problem: czy DNS "mówi" prawdę? Oszukanie serwera DNS (DNS Spoofing), polegające na zmianie mapowania nazw domen na ich domyślne adresy IP, w hakerskim rzemiośle nie jest trudnym zadaniem.

Ze względu na to, że DNS składa się z wielu współpracujących ze sobą serwerów, możliwe jest "podrzucenie" serwerom podrzędnym fałszywego wpisu, co określa się mianem zatrucia bufora DNS (DNS cache poisoning). Ataki przeprowadzone skutecznie na tym etapie połączenia mogą spowodować, że klient będzie komunikować się z komputerem kontrolowanym przez atakującego, sądząc, że ma do czynienia z właściwym serwerem. W tym świetle usługi DNS trudno uznać za "wiarygodną książkę telefoniczną" dla krytycznych aplikacji, np. bankowych.

Trzeci do pary

Ataki wykorzystujące serwery DNS nie wyczerpują potencjalnych możliwości wejścia w posiadanie poufnych informacji. W następnym etapie, po zdobyciu adresu IP poszukiwanego serwera, komputer użytkownika stara się z nim połączyć za pomocą protokołu TCP. To również świetna okazja do ataku: pasywnego podsłuchu, przejęcia połączenia albo modyfikowania oryginalnych pakietów (Sniffing, TCP Connection Hijacking, Packet Replay).

Wymienionym zagrożeniom, powstającym na poziomie połączenia TCP, można stosunkowo łatwo zaradzić. Problem sfałszowanej książki telefonicznej jest natomiast nieusuwalny, chyba że znajdzie się ktoś, kto niezależnie będzie potrafił wiarygodnie poświadczyć tożsamość stron wobec siebie - trzecia zaufana strona łącząca tożsamość serwera w znaczeniu kryptograficznym i sieciowym z jego tożsamością w świecie realnym. Jedynym takim rozwiązaniem jest na razie infrastruktura klucza publicznego PKI (Public Key Infrastructure) wykorzystująca certyfikaty elektroniczne w formacie X.509. PKI opiera się na założeniu, że skoro trzecia strona zwana urzędem certyfikacyjnym CA (Certifying Authority) ufa każdej z chcących komunikować się stron z osobna i fakt ten można bezsprzecznie ustalić, to strony nie powinny mieć problemu z wzajemnym do siebie zaufaniem.

Dla przykładu, firma lokalizująca serwer SSL, np. w Singapurze, musi przedstawić CA następujące dokumenty: dowód prawa posługiwania się nazwą domenową serwera (np. bank.com) oraz dowód, że faktycznie jest tą firmą (wyciąg z rejestrów gospodarczych itd.). W ten sposób urząd certyfikacji uzyskuje pewność, że serwer bank.com należy do firmy Bank SA. Teraz trzeba o tym przekonać klienta, który znajduje się np. w Polsce.

Najlepiej byłoby, gdyby klient wprost do ręki otrzymał certyfikat potwierdzający tożsamość serwera bank.com i obsługującego go banku. Z oczywistych względów jest to jednak utrudnione. Na szczęście dla wszystkich zainteresowanych, dowód ten jest już w posiadaniu klienta. Wszystkie popularne przeglądarki WWW są wyposażone w kilkadziesiąt wbudowanych na stałe certyfikatów CA potwierdzających tożsamość wystawców certyfikatów najwyższego rzędu. Dzięki temu zamykają się wszystkie ogniwa potwierdzania tożsamości: tożsamość firmy jest potwierdzona przez lokalny urząd CA, który z kolei legitymuje się certyfikatem z podpisem elektronicznym urzędu wyższego rzędu.

Infrastruktura dla infrastruktury

Certyfikat X.509 to dokument elektroniczny potwierdzający tożsamość innego dokumentu, serwera, usługi sieciowej, firmy lub osoby. Oprócz parametrów, takich jak nazwa certyfikatu, data upływu ważności, certyfikat może też zawierać klucz publiczny podmiotu, którego dotyczy. W certyfikacie zwykle osadzona jest także ścieżka sieciowa do serwera, na którym jest przechowywany certyfikat urzędu nadrzędnego w stosunku do podmiotu oryginalnego.

Na świecie istnieje co najmniej kilkadziesiąt urzędów CA mających uprawnienia najwyższego poziomu - to ich certyfikaty są wbudowane w przeglądarki. CA najwyższego poziomu podpisują certyfikaty CA niższych poziomów (lokalnych CA). Lokalni CA podpisują finalne certyfikaty serwerów, osób, firm itd. Pozwala to np. uzyskać w razie potrzeby certyfikat lokalnego CA z Internetu, bez obawy o jego autentyczność (wbudowany certyfikat nadrzędny pozwoli ją zweryfikować).

Struktura hierarchiczna, w której kolejne poziomy uwierzytelniają się nawzajem, nazywa się drzewem certyfikacji (certification tree). Istotne jest także to, że certyfikat CA różni się od certyfikatu np. serwera obecnością specjalnych flag (basic constraints), określających dozwolone wykorzystanie certyfikatu - np. certyfikat CA nie może być wykorzystywany bezpośrednio na serwerze SSL, a certyfikat serwera - do podpisywania innych certyfikatów.

Weryfikacja certyfikatów odbywa się automatycznie w przeglądarce klienta. Jest ona odpowiedzialna za zweryfikowanie poprawności poszczególnych podpisów, zgodności nazwy serwera z nazwą obecną w certyfikacie itd. W razie jakichkolwiek niezgodności przeglądarka powinna ostrzec użytkownika i pozostawić mu podjęcie decyzji o kontynuacji połączenia. Jest to bardzo istotne, bo nakłada ogromną odpowiedzialność na przeglądarkę, która pełni rolę elementu spajającego wszystkie ogniwa zabezpieczeń zapewnianych przez SSL i PKI.