SSL (ang. Secure Socket Layer) to protokół zaprojektowany w celu zapewnienia bezpiecznego przesyłania danych w Internecie. W przeciwieństwie do wielu stosowanych rozwiązań, zapewnia on poufność oraz integralność całej transmisji. Wbrew powszechnej opinii, głównym zadaniem protokołu SSL nie jest wyłącznie zapewnienia szyfrowanego połączenia, ale również uwierzytelnienie (zweryfikowanie tożsamości) komunikujących się stron. Dzięki temu, odwiedzając za pomocą bezpiecznego połączenia serwis Gmail lub też korzystając z internetowej bankowości, mamy pewność, że dany serwis należy do określonej organizacji. Czy aby na pewno?
Okazuje się, że w wyniku ataku ochrzczonego przez swych pomysłodawców mianem compelled certificate creation attack, władze są w stanie przechwycić dowolną komunikację zabezpieczoną za pomocą SSL. Co więcej, powstały już pierwsze komercyjne urządzenia zdolne do sprzętowego wsparcia tego typu działalności.
U podstaw bezpieczeństwa SSL leży specjalny system hierarchicznych certyfikatów. Kluczowe znaczenie mają tu urzędy certyfikacji (ang. certificate authority, CA), których zadaniem jest wydawanie certyfikatów poświadczających tożsamość poszczególnych instytucji. Poszczególne certyfikaty zostają podpisane należącym do CA certyfikatem głównym. Certyfikat zawiera więc zbiór danych jednoznacznie identyfikujących pewną jednostkę oraz jest potwierdzony przez jedną z grona zaufanych organizacji CA, co właśnie ma zapewniać bezpieczeństwo całego systemu.
Problem w tym, że każda z organizacji CA jest uznawana za równie zaufaną. Natomiast każda z wiodących przeglądarek internetowych (korzystając z własnego lub systemowego zbioru) rozpoznaje i w pełni akceptuje setki certyfikatów głównych i w konsekwencji powszechnie akceptowane są również wszystkie certyfikaty podpisane przez poszczególne urzędy CA.
Co najgorsze, z technicznego punktu widzenia, w pełni możliwe jest wystawienie certyfikatu poświadczającego tożsamość dowolnej organizacji przez dowolną organizację CA. Możliwe jest więc, by np. rosyjski urząd certyfikacji wystawił fałszywy certyfikat dla tożsamości mail.google.com! Z technicznego punktu widzenia taki zabieg jest banalny, wystarczy bowiem tylko w całym procesie przyznawania certyfikatu pominąć etap weryfikacji tożsamości ubiegającego się o jego wystawienie. Taki certyfikat, jeśli tylko certyfikat główny rosyjskiego CA będzie znany przeglądarce użytkownika, pozwala natomiast bez większego problemu na wykonanie ataku typu Man-in-the-Middle, czyli pośredniczenie w komunikacji użytkownika z usługą Gmail w celu przechwycenia całej komunikacji! Użytkownik nie zauważy niczego podejrzanego, ponieważ transmisja będzie zabezpieczona za pomocą certyfikatu wystawionego dla mail.google.com oraz potwierdzonego znanym certyfikatem głównym…
Compelled certificate creation attack polega więc na zmuszeniu przez władze lub służby specjalne (np. za pomocą nakazu sądowego, wywierania presji, gróźb itd.) lokalnego urzędu CA do wystawienia fałszywego certyfikatu poświadczającego tożsamość określonej organizacji, w celu przechwycenia komunikacji SSL prowadzonej przez lokalnych użytkowników z tą właśnie organizacją za pomocą ataku typu Man-in-the-Middle. Oczywiście crackerzy, a nawet duże organizacje przestępcze, prawdopodobnie nie są w stanie wykonać tego typu ataku, ponieważ nie znajdą sposobu na zmuszenie urzędu CA do wydania fałszywego certyfikatu.
Czy tego typu ataki są już obecnie stosowane? Okazuje się, że istnieją przesłanki mogące o tym świadczyć. Packet Forensics, amerykańska firma z Arizony, produkuje bowiem urządzenia niemal stworzone z myślą o przeprowadzaniu ataku typu compelled certificate creation attack.
Urządzenia te pozwalają na zautomatyzowane przechwytywanie szyfrowanych transmisji z wykorzystaniem kopii właściwego certyfikatu lub też fałszywego certyfikatu poświadczającego tożsamość określonej organizacji…
Skuteczna obrona przed tego typu atakami jest trudna, a w pewnych przypadkach może być praktycznie niemożliwa. W miarę skuteczną strategią obronną wydaje się być polityka kontrolowania certyfikatów typu Trust-On-First-Use (TOFU). Oznacza to przyjęcie założenia, że podczas pierwszego korzystania z określonej usługi jej certyfikat był prawidłowy. Monitorując więc za każdym razem jakiekolwiek zmiany certyfikatu tej organizacji, będziemy w stanie wykryć, że zmienił się przykładowo urząd CA poświadczający prawdziwość certyfikatu. Takie wykrycie będzie prawdopodobnie oznaczać zaistnienie ataku (pomimo, że oba urzędy CA w świetle zasad rządzących komunikacją SSL są zaufane). Co jednak w momencie, gdy władze określonego kraju wymuszą na dostawcy usługi udostępnienie w celach śledczych kopii głównego certyfikatu usługi? W takim przypadku internauci nie będą w stanie zauważyć jakiejkolwiek ingerencji w bezpieczne połączenie SSL…
Dobrze wiedzieć że są takie przypadki przymuszanie urzędów certyfikacyjnych przez rządy lub służby specjalne do „poświadczenia nieprawdy”. Okazuje się, że SSL, DNSSEC, itd. są warte maksymalnie jednego funta kłaków jeśli atak nazywa się „government in the middle”…
O przypadkach przymuszania CA nic nie pisałem, bo chyba nie ma na chwilę obecną żadnych dowodów. Skoro jednak firma Packet Forensics wyraźnie nastawia się na dostarczanie swych urządzeń służbom:
to chyba jednak mają jakichś klientów?
Z sprzedawania frytek pewnie nie da sie wyzyc na poziomie.
@abcman: Podstawowym celem istnienia zabezpieczen jest ochrona przed "zlymi ludzmi", nie przed odpowiednio usankcjonowanymi dzialaniami instytucji panstwowych.
Podstawowym celem istnienia CBA jest odpowiednio usankcjonowane działanie, a nie zabawa w "złych ludzi".
A skąd pewność, że te działania są "usankcjonowane"? A nawet jeśli to skąd pewność, że na podstawie prawdziwych dowodów? Pewnie słyszałeś (słyszałaś?) o "usankcjonowanych" podsłuchach wydawanych na podstawie 100 stronicowych akt, których nikt (sędzia) w godzinę nie przeczyta a w których tak na prawdę nic nie ma.
No to słitaśnie. Potem się powie tłuszczy (przepraszam, wyborcom:), że należy walczyć z pedofilią/terroryzmem w internecie i cały proces się dopiero rozbuja.
Nie wydaje mi się, by czyniąc proces przyznawania certyfikatów bardziej scentralizowanym udałoby się uniknąć takich praktyk. W każdym razie, to auto się pomylił. Władza nie może podsłuchać każdej komunikacji. Zawsze mogę sobie samemu wystawić certyfikat dla serwera(usługi), z którego tylko ja będę chcieć korzystać.
Nie zawsze jest tak, że musisz chcieć z czegoś skorzystać. Istnieje wiele ataków (np. DNS poisoning) pozwalających na "zachęcenie" użytkownika do odwiedzenia określonego (np. fałszywego) serwera.
Przecież rozpoznam fałszywy serwer po własnym certyfikacie 😉 .
Fałszywy serwer może mieć certyfikat identyczny z tym prawdziwym, było o tym we wpisie. Wystarczy tylko, że władze otrzymają od dostawcy usługi kopię oryginalnego certyfikatu dla celów "śledczych"…
Hmmm… ale przecież zdobycie "kopii" certyfikatu serwera nie stanowi wielkiego problemu…
Hcsl.pl, skup sie na chwile, on mowi o wlasnym serwerze z wlasnorecznie
wygenerowanym certyfikatem, bez udzialu "osob trzecich".
A chyba wiem o jakim ataku mowa, przychodza smutni panowie z nakazem
do dostawcy hostingu i "otwieraj pan serwerownie, bedziem certyfikaty
z serwerow zczesywac".
hcsl, ależ bredzisz nieznośnie… Po co władze mają od kogoś otrzymywać kopię certyfikatu od jakiegoś niejasnego dostawcy usług do jakichś niezrozumiałych celów śledczych, skoro certyfikat udostępniany jest przez serwer przy każdym połączeniu?
Odróżniasz w ogóle certyfikat od klucza prywatnego?!?
Czemu tylko SSL?
To nie jest atak na protokół – taki atak można przeprowadzić na dowolną technologię bezpieczeństwa opartą na tym że czemuś ufamy – w tym momencie certyfikatowi głównemu.
Tak samo jest w przypadku web of trust i wzajemnemu podpisywaniu kluczy – im większa sieć zaufania tym większa szansa że dostanie się do niej ktoś z niecnymi zamiarami.
Akurat im większa sieć zaufania tym *mniejsza* szansa, że ktoś z niecnymi zamiarami cokolwiek zdziała. Na tym polega sens tworzenia dużej sieci zaufania (np. w infrastrukturze GnuPG).
Ale bzdura, przecież określone służby mogą iść do dostawcy (o ile jest w kraju) i zażądać dostępu bezpośrednio do serwera. Nie trzeba żonglować certyfikatami, routingiem, kupować drogiego sprzętu, czy robić DNS poisoning. Najprostsza i najtańsza metoda.
Oczywiście jak serwer jest za granicą, oryginalne CA jest jeszcze gdzie indziej, to trzeba iść do lokalnego trusted root CA i "poprosić" o swój certyfikat.
@s: I tak sie robi. Tyle, ze serwer czesto/zwykle jest w innym kraju.
Luz ludzie. Jest dodatek do FF3, "Certificate Patrol", który daje sobie radę z tym problemem. Jeśli ktoś wymieni ważny certyfikat na inny ważny certyfikat, pokaże się okno z informacją że certyfikat danej strony uległ zmianie. Polecam.
Kolejny powód, aby nie używać pieprzonej Opery.
A jak to się ma do prawa bankowego?
Wcale się nie ma!
Po prostu zabezpieczenie SSL opiera się na _zaufaniu_, że kawałek kodu potwierdza czyjąś tożsamość, bo _jakaś_ _organizacja_ to _zweryfikowała_. Nie ma absolutnie _żadnej_ możliwości, żeby to potwierdzić samodzielnie, zwłaszcza podczas podłączania się do jakiejkolwiek usługi zabezpieczonej przez SSL.
Podsumowując: kolejny raz okazuje się, że cały system jest tylko tak bezpieczny, jak jego najsłabsze ogniwo – w tym wypadku, tradycyjnie, jest nim człowiek…
@Tomasz Woźniak: Coraz wiecej bankow wymienia metody autoryzacji transakcji opierajace sie na zaufaniu SSL-owi (i w zwiazku z tym wrazliwe na man-in-the-browser czy man-in-the-middle metoda opisana powyzej) na jakies lepsze.
Jakie daj nazwy do wygooglania.
@jarek: Jesli nie potrafisz wyguglac bez nazwy, to nazwa niespecjalnie pomoglaby ci w zrozumieniu tematu.
Jest dodatek do Firefox'a o nazwie "Certificate Patrol", ułatwia on TOFU.
Zagrożenie jest szczególnie widoczne na rządowych stronach które posługują się własnymi certyfikatami.
Firefox od razu wyświetla komunikat.
Przykład strony:
https://nsp2011.spis.gov.pl/form/