Uwaga: swoją pierwotną odpowiedź napisałem bardzo szybko, ale od tego czasu stało się to dość popularne pytanie / odpowiedź, więc nieco ją rozszerzyłem i uściśliłem.
Możliwości TLS
„SSL” to nazwa, która jest najczęściej używana w odniesieniu do tego protokołu, ale SSL szczególnie odnosi się do zastrzeżonego protokołu opracowanego przez firmę Netscape w połowie lat 90-tych. „TLS” to standard IETF oparty na SSL, więc w mojej odpowiedzi użyję TLS. Obecnie istnieje prawdopodobieństwo, że prawie wszystkie Twoje bezpieczne połączenia w sieci używają protokołu TLS, a nie SSL.
TLS ma kilka możliwości:
- Szyfruj dane warstwy aplikacji. (W twoim przypadku protokołem warstwy aplikacji jest HTTP).
- Uwierzytelnij serwer przed klientem.
- Uwierzytelnij klienta na serwerze.
# 1 i # 2 są bardzo powszechne. # 3 jest mniej powszechny. Wydaje się, że koncentrujesz się na drugim, więc wyjaśnię tę część.
Poświadczenie
Serwer uwierzytelnia się wobec klienta przy użyciu certyfikatu. Certyfikat to zbiór danych [1] zawierający informacje o witrynie internetowej:
- Nazwa domeny
- Klucz publiczny
- Firma, która jest jej właścicielem
- Kiedy został wydany
- Kiedy wygasa
- Kto to wydał
- Itp.
Możesz osiągnąć poufność (punkt 1 powyżej), używając klucza publicznego zawartego w certyfikacie do szyfrowania wiadomości, które można odszyfrować tylko za pomocą odpowiedniego klucza prywatnego, który powinien być bezpiecznie przechowywany na tym serwerze. [2] Nazwijmy tę parę kluczy KP1, abyśmy nie byli później zdezorientowani. Możesz również sprawdzić, czy nazwa domeny na certyfikacie jest zgodna z odwiedzaną witryną (punkt 2 powyżej).
Ale co by było, gdyby przeciwnik mógł modyfikować pakiety wysyłane do iz serwera, a co by się stało, gdyby ten przeciwnik zmodyfikował przedstawiony ci certyfikat i wstawił swój własny klucz publiczny lub zmienił inne ważne szczegóły? Gdyby tak się stało, przeciwnik mógłby przechwycić i zmodyfikować wszelkie wiadomości, które Twoim zdaniem zostały bezpiecznie zaszyfrowane.
Aby zapobiec takiemu atakowi, certyfikat jest kryptograficznie podpisywany przez klucz prywatny innej osoby w taki sposób, że podpis może zostać zweryfikowany przez każdego, kto ma odpowiedni klucz publiczny. Nazwijmy tę parę kluczy KP2, aby było jasne, że nie są to te same klucze, których używa serwer.
Urzędy certyfikacji
Więc kto stworzył KP2? Kto podpisał certyfikat?
Upraszczając trochę, urząd certyfikacji tworzy KP2 i sprzedaje usługę używania klucza prywatnego do podpisywania certyfikatów dla innych organizacji. Na przykład tworzę certyfikat i płacę firmie takiej jak Verisign za podpisanie go ich kluczem prywatnym. [3] Ponieważ nikt oprócz Verisign nie ma dostępu do tego klucza prywatnego, nikt z nas nie może sfałszować tego podpisu.
A jak osobiście zdobyłbym klucz publiczny w KP2, aby zweryfikować ten podpis?
Cóż, widzieliśmy już, że certyfikat może przechowywać klucz publiczny - a informatycy uwielbiają rekursję - dlaczego więc nie umieścić klucza publicznego KP2 w certyfikacie i nie rozpowszechniać go w ten sposób? Na początku brzmi to trochę szalenie, ale w rzeczywistości dokładnie tak to działa. Kontynuując przykład firmy Verisign, firma Verisign tworzy certyfikat, który zawiera informacje o tym, kim jest, jakie typy rzeczy mogą podpisywać (inne certyfikaty) oraz o kluczu publicznym.
Teraz, jeśli mam kopię tego certyfikatu Verisign, mogę jej użyć do zweryfikowania podpisu na certyfikacie serwera dla witryny, którą chcę odwiedzić. Spokojnie, prawda ?!
Cóż, nie tak szybko. Musiałem skądś zdobyć certyfikat Verisign . A jeśli ktoś sfałszuje certyfikat Verisign i umieści tam swój własny klucz publiczny? Następnie mogą sfałszować podpis na certyfikacie serwera i wracamy do punktu wyjścia: ataku typu man-in-the-middle.
Łańcuchy certyfikatów
Kontynuując myślenie rekurencyjne, moglibyśmy oczywiście wprowadzić trzeci certyfikat i trzecią parę kluczy (KP3) i użyć ich do podpisania certyfikatu Verisign. Nazywamy to łańcuchem certyfikatów: każdy certyfikat w łańcuchu służy do weryfikacji następnego certyfikatu. Miejmy nadzieję, że już widać, że to rekurencyjne podejście to tylko żółwie / certyfikaty. Gdzie to się kończy?
Ponieważ nie możemy utworzyć nieskończonej liczby certyfikatów, łańcuch certyfikatów musi oczywiście gdzieś się zatrzymać , a to jest zrobione poprzez włączenie certyfikatu do łańcucha, który jest samopodpisany .
Zatrzymam się na chwilę, podczas gdy ty będziesz zbierać eksplodujące fragmenty materii mózgowej. Z podpisem własnym ?!
Tak, na końcu łańcucha certyfikatów (zwanego też „głównym”) będzie certyfikat, który używa własnej pary kluczy do podpisywania się. Eliminuje to problem nieskończonej rekurencji, ale nie rozwiązuje problemu z uwierzytelnianiem. Każdy może stworzyć samopodpisany certyfikat, na którym jest napisane cokolwiek, tak jak ja mogę stworzyć fałszywy dyplom z Princeton, który mówi, że mam trzykrotne specjalizacje z polityki, fizyki teoretycznej i kopanie tyłków, a następnie podpisuję się na dole.
[Nieco nieciekawym] rozwiązaniem tego problemu jest po prostu wybranie zestawu certyfikatów z podpisem własnym, którym jawnie ufasz. Na przykład mogę powiedzieć: „ Ufam temu samopodpisanemu certyfikatowi firmy Verisign”.
Mając to jawne zaufanie, mogę teraz zweryfikować cały łańcuch certyfikatów. Bez względu na to, ile certyfikatów jest w łańcuchu, mogę zweryfikować każdy podpis aż do katalogu głównego. Kiedy dotrę do katalogu głównego, mogę sprawdzić, czy ten certyfikat główny jest certyfikatem, któremu jawnie ufam. Jeśli tak, to mogę zaufać całej sieci.
Zaufanie
Uwierzytelnianie w TLS wykorzystuje system nadanego zaufania . Jeśli chcę zatrudnić mechanika samochodowego, nie mogę ufać żadnemu przypadkowemu mechanikowi, którego znajdę. Ale może mój przyjaciel ręczy za konkretnego mechanika. Ponieważ ufam mojemu przyjacielowi, mogę zaufać temu mechanikowi.
Kupując komputer lub pobierając przeglądarkę, otrzymujesz kilkaset certyfikatów głównych, którym wyraźnie ufa. [4] Firmy, które posiadają i obsługują te certyfikaty, mogą powierzyć to zaufanie innym organizacjom, podpisując swoje certyfikaty.
To daleki od doskonałego systemu. Czasami urząd certyfikacji może błędnie wystawić certyfikat. W takich przypadkach może być konieczne unieważnienie certyfikatu. Odwołanie jest trudne, ponieważ wydany certyfikat zawsze będzie poprawny kryptograficznie; protokół pozapasmowy jest niezbędny, aby dowiedzieć się, które wcześniej ważne certyfikaty zostały unieważnione. W praktyce niektóre z tych protokołów nie są zbyt bezpieczne, a wiele przeglądarek i tak ich nie sprawdza.
Czasami atakowany jest cały urząd certyfikacji. Na przykład, gdybyś włamał się do Verisign i ukradł ich główny klucz podpisujący, mógłbyś sfałszować dowolny certyfikat na świecie. Zwróć uwagę, że dotyczy to nie tylko klientów Verisign: nawet jeśli mój certyfikat jest podpisany przez Thawte (konkurent Verisign), to nie ma znaczenia. Mój certyfikat nadal może zostać sfałszowany przy użyciu złamanego klucza podpisywania firmy Verisign.
To nie jest tylko teoria. To wydarzyło się na wolności. DigiNotar został zhakowany, a następnie zbankrutował. Comodo również zostało zhakowane , ale w niewytłumaczalny sposób działają one do dziś.
Nawet jeśli urzędy certyfikacji nie są bezpośrednio zagrożone, w tym systemie istnieją inne zagrożenia. Na przykład rząd używa przymusu prawnego, aby zmusić CA do podpisania sfałszowanego certyfikatu. Twój pracodawca może zainstalować własny certyfikat CA na komputerze pracownika. W tych różnych przypadkach ruch, który według Ciebie będzie „bezpieczny”, jest w rzeczywistości całkowicie widoczny / modyfikowalny dla organizacji kontrolującej ten certyfikat.
Zaproponowano kilka zamienników, w tym Convergence , TACK i DANE .
Uwagi końcowe
[1] Dane certyfikatu TLS są sformatowane zgodnie ze standardem X.509 . X.509 jest oparty na ASN.1 („Abstract Syntax Notation # 1”), co oznacza, że nie jest binarnym formatem danych. Dlatego X.509 musi być zakodowany w formacie binarnym. DER i PEM to dwa najpopularniejsze kodowania, o których wiem.
[2] W praktyce protokół faktycznie przełącza się na szyfr symetryczny, ale jest to szczegół, który nie dotyczy twojego pytania.
[3] Można przypuszczać, że urząd certyfikacji faktycznie sprawdza, kim jesteś przed podpisaniem certyfikatu. Gdyby tego nie zrobili, mógłbym po prostu utworzyć certyfikat dla google.com i poprosić urząd certyfikacji o jego podpisanie. Mając ten certyfikat, mogłem pośredniczyć w każdym „bezpiecznym” połączeniu z google.com. Dlatego etap walidacji jest bardzo ważnym czynnikiem w funkcjonowaniu urzędu certyfikacji. Niestety, nie jest jasne, jak rygorystyczny jest ten proces walidacji w setkach urzędów certyfikacji na całym świecie.
[4] Zobacz listę zaufanych urzędów certyfikacji Mozilli .
