Google banuje chiński rządowy urząd certyfikacji z powodu utraty zaufania

dodał 2 kwietnia 2015 o 13:05 w kategorii Krypto  z tagami:
Google banuje chiński rządowy urząd certyfikacji z powodu utraty zaufania

Certyfikat chińskiego rządowego urzędu certyfikacji wkrótce zostanie zablokowany w Google Chrome. To bardzo radykalne, rzadko spotykane posunięcie jest wynikiem podejrzanego incydentu sprzed kilku tygodni, w który zamieszany był ten urząd.

Bezpieczeństwo szyfrowanego ruchu wymienianego z serwerami WWW w dużej mierze polega na systemie publicznego zaufania do urzędów certyfikacji. Google własnie poinformowało, że jednemu z większych urzędów nie będzie ufać. Jak do tego doszło?

Egipski podsłuch

Afera rozpoczęła się 20 marca, gdy Google wykryło nieautoryzowany certyfikat wystawiony dla swoich domen gdzieś w Egipcie. Ktoś z adresu IP 197.44.153.50 próbował otworzyć witryny Google oraz Twittera w Google Chrome. Przeglądarka ta ma zapisane na stałe podpisy cyfrowe certyfikatów SSL, które powinna otrzymać od Google i Twittera, jednak tego dnia otrzymała nieautoryzowane certyfikaty – choć podpisane zaufanym kluczem innego wystawcy.

Google Chrome nie pierwszy raz pomógł wykryć praktykę wystawiania fałszywych certyfikatów – poniżej znajdziecie listę wcześniejszych incydentów. Scenariusz, który doprowadził do tych wydarzeń jak i ich skutki są warte opisania.

Fałszywe certyfikaty wykryte przez Google były wystawione przez podrzędne centrum certyfikacji należące do egipskiej firmy MCS (MidEast Communication Systems), która jest integratorem systemów informatycznych. Certyfikat MCS był z kolei powiązany z chińskim rządowym centrum certyfikacji CNNIC – jedyną organizacją w Chinach zarządzającą domeną .CN, certyfikatami SSL oraz całym chińskim internetem. Google powiadomiło CNNIC i zablokowało certyfikat MCS w Chromie (podobnie postąpiła Mozilla, działanie zapowiedział też Microsoft). Wytłumaczenie incydentu jest dość ciekawe.

Jak tanio i prosto zostać CA

Otrzymanie możliwości wystawiania certyfikatów SSL dla dowolnej domeny – i to certyfikatów, którym zaufają automatycznie najpopularniejsze przeglądarki – to bardzo kosztowny i skomplikowany proces. Trzeba zbudować całą infrastrukturę logiczną i fizyczną, która zapewni odpowiedni poziom ochrony klucza prywatnego, łącznie z odpowiednio chronionymi pomieszczeniami, gdzie odbywać się będzie ceremonia podpisywania klucza. Zamiast zatem zostać urzędem certyfikacji, prościej jest otrzymać certyfikat podrzędnego urzędu certyfikacji.

Większość urzędów certyfikacji stawia potencjalnym odbiorcom klucza urzędu pośredniego spore wymagania: dedykowane urządzenie zapewniające bezpieczeństwo klucza, klatka Faraday’a, najlepiej uzbrojony strażnik pod drzwiami lub, alternatywnie, klucz pozostający w posiadaniu urzędu certyfikacji i używany zdalnie przez urząd pośredni. Większość, ale nie wszyscy. Kiedy zatem firma MCS postanowiła zostać wystawcą certyfikatów SSL, skorzystała z tego, że CNNIC nie miał oficjalnej procedury wydawania certyfikatów urzędów pośrednich.

My tylko pożyczymy

Według zapewnień MCS, klucz umożliwiający wystawianie certyfikatów dla dowolnej domeny został wypożyczony na 2 tygodnie na podstawie osobnej umowy. MCS klucz chciało tymczasowo przechować w najbezpieczniejszym urządzeniu, jakie znalazło w swojej infrastrukturze – firewallu firmy Palo Alto, zgodnym ze standardem FIPS. W czwartek 19 marca klucz wylądował w serwerze CA w urządzeniu i w piątek miał zostać przeniesiony do dedykowanej infrastruktury. Jak to jednak zwykle w projektach bywa, nastąpiły opóźnienia i piątkowy transfer nie miał miejsca. Klucz został w firewallu na weekend.

Fragment architektury MCS

Fragment architektury MCS

Według oficjalnego raportu MCS (część 1 i 2) firewall nie tylko był podłączony zarówno do sieci wewnętrznej jak i zewnętrznej, ale także miał domyślnie włączoną funkcję podsłuchu (MiTM) połączeń SSL. Kiedy zatem jeden z pracowników firmy odpalił przeglądarkę Chrome by wejść na kilka stron, firewall radośnie wykorzystał świeżo otrzymany certyfikat i odszyfrował ruch użytkownika podkładając mu fałszywy, wygenerowany w locie certyfikat witryny docelowej. Chrome natychmiast to wykrył i zaraportował do centrali – a ciąg dalszy już znacie.

Radykalne posunięcie Google

Choć Google potwierdziło, że obserwowany incydent odpowiada opisowi dostarczonemu przez sprawców,  to po dłuższym namyśle postanowiło zareagować w bardzo stanowczy sposób. Zapowiedziało, że przy najbliższej aktualizacji Chrome zablokuje certyfikat CNNIC (a raczej wyłączy jego atrybut zaufania), co spowoduje, że wszystkie witryny internetowe, korzystające z certyfikatów wystawionych przez CNNIC lub któregokolwiek z jego klientów, będą informować o problemach z certyfikatem. Blokada nie nastąpiła natychmiast, by dać chwilę właścicielom witryn na zapobieżenie skutkom tego ruchu. Nie wiemy jeszcze, ile stron posługuje się certyfikatem zależnym od CNNIC, ale Chrome ma ponad 50% rynku w Chinach, zatem konsekwencje mogą być poważne.

Blokada certyfikatu nie jest bezterminowa – Google poinformowało, ze CNNIC może zgłosić chęć ponownego uznania certyfikatu za zaufany, musi tylko wcześniej wdrożyć standard Certificate Transparency, opracowany przez Google i mający na celu zapewnienie lepszej kontroli nad procesem wydawania certyfikatów. CNNIC nie jest zbyt zadowolone z przebiegu wydarzeń, jednak trudno wskazać innego winnego zaistniałej sytuacji. Brawo dla Google za odważną decyzję – ekosystem certyfikatów jest zbyt wrażliwy, by pozwalać na takie zaniedbania. osobną sprawą jest także historia opowiedziana przez MCS – Egipt w końcu znajduje się na liście krajów, które lubią podsłuchiwać swoich obywateli.

Najważniejsze wcześniejsze incydenty: