Pod kluczem

Prawda ta dotyczy zresztą nie tylko wielkiego biznesu. Za każdym razem, kiedy chcemy uruchomić w Sieci serwis operujący na relatywnie ważnych danych (a ważne mogą być przecież najróżniejsze informacje – chociażby personalia członków klubu miłośników Ferrari czy uczestników małej aukcji znaczków pocztowych), trzeba zadbać o bezpieczeństwo transakcji. W praktyce oznacza to, że poufne dane (np. numer karty kredytowej, dane adresowe klienta), które muszą być przesłane za pomocą Internetu, nie mogą dostać się w niepowołane ręce.

Z pomocą w tym zadaniu przychodzi powszechnie stosowany, bezpieczny protokół HTTPS (ang. HTTP over SSL). Obsługuje go każdy szanujący się serwer WWW. Potrzebny jest jeszcze jeden, bardzo istotny element, a mianowicie certyfikat dla serwera WWW. Brak cyfrowego identyfikatora może okazać się najsłabszym punktem zabezpieczonego systemu i zniweczyć cały trud włożony w przygotowanie serwisu.

Na co komu certyfikat?

Tuż po instalacji serwera obsługującego bezpieczne połączenia za pomocą protokołu HTTPS trudno jest nie zadać sobie takiego pytania. W większości przypadków serwery są rozprowadzane z przykładowymi certyfikatami i być może dlatego rzadko zdajemy sobie sprawę z ich obecności, nie wspominając już o poprawności cyfrowego klucza. Po wprowadzeniu do przeglądarki adresu typu https://www.firma.com.pl/ użytkownik potwierdza zwykle mechanicznie przyciskiem OK całą serię okien dialogowych, które zgłaszają nieprawidłowości w certyfikatach serwera. Tak czy inaczej na ekranie pojawi się przecież oczekiwana strona, a przeglądarka – zgodnie ze stanem faktycznym – zasygnalizuje szyfrowane połączenie. Skoro działa, to lepiej nic nie poprawiać, bo przecież można coś popsuć, a całość miała być gotowa na zeszły piątek. Mniej więcej w taki sposób także serwery WWW potwierdzają znane porzekadło, zgodnie z którym tymczasowe rozwiązania egzystują znacznie dłużej, niż nam się wydaje w momencie ich tworzenia.

Problem z taką doraźną sytuacją polega przede wszystkim na tym, że technologia HTTPS jest łatwo dostępna. Pozwala to łatwo zaszkodzić serwerowi WWW, którego administrator nie przywiązuje zbyt wielkiej wagi do certyfikatów? Okazuje się, że wystarczy skopiować cały serwis (lub przynajmniej jego część) i, posługując się odpowiednimi technikami, nieco “ogłupić” wybrany serwer DNS (tak, aby odsyłał on przeglądarki użytkowników, chcących się połączyć z danym serwerem, pod fałszywy adres). Teraz trzeba tylko poczekać na ofiarę, która po raz kolejny zignoruje ostrzeżenia, tym razem w pełni zasadne. Cała “akcja” może trwać bardzo krótko i – z punktu widzenia klienta – wyglądać na “chwilową awarię” serwisu. Kiedy już poufne dane trafią w ręce osoby, która ich mieć nie powinna, to zdarzyć się może dużo nieprzyjemnych rzeczy. Zapewniam, że w dzisiejszej Sieci jest sporo osób dysponujących zarówno stosowną wiedzą, jak i środkami do realizacji opisanego scenariusza.

Jak więc widać, szyfrowane połączenia uniemożliwiają (czy też raczej znacznie utrudniają) przechwycenie i modyfikację danych, ale na tym kończą się korzyści wynikające z kodowania informacji. Jeżeli chcemy się upewnić, że przesyłamy dane do właściwego serwera, musimy skorzystać z certyfikatów. Pozwolą one na upewnienie się, że transmisja odbywa się pomiędzy właściwymi komputerami. Jeśli o naszym serwisie myślimy poważnie, to warto zadbać o certyfikat z prawdziwego zdarzenia.

Więcej:bezcatnews