Jak działa SSL?
Gdzie certyfikat jest zainstalowany na kliencie (lub przeglądarce?) I serwerze (lub serwerze internetowym?)?
Jak rozpoczyna się proces zaufania / szyfrowania / uwierzytelniania po wprowadzeniu adresu URL do przeglądarki i pobraniu strony z serwera?
W jaki sposób protokół HTTPS rozpoznaje certyfikat? Dlaczego protokół HTTP nie może współpracować z certyfikatami, skoro to certyfikaty obsługują całe zaufanie / szyfrowanie / uwierzytelnianie?
ssl
ssl-certificate
Vicky
źródło
źródło
Odpowiedzi:
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:
# 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:
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 .
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 .
źródło
HTTPS to połączenie HTTP i SSL (Secure Socket Layer) w celu zapewnienia szyfrowanej komunikacji między klientem (przeglądarką) a serwerem internetowym (aplikacja jest hostowana tutaj).
Dlaczego jest to potrzebne?
HTTPS szyfruje dane przesyłane z przeglądarki do serwera przez sieć. Tak więc nikt nie może wąchać danych podczas transmisji.
Jak nawiązywane jest połączenie HTTPS między przeglądarką a serwerem WWW?
Ten przepływ można przedstawić na poniższym diagramie:
źródło
Napisałem mały wpis na blogu, który pokrótce omawia ten proces. Zapraszam do obejrzenia.
SSL Handshake
Mały fragment z tego samego jest następujący:
„Klient wysyła żądanie do serwera przez HTTPS. Serwer wysyła kopię swojego certyfikatu SSL + klucz publiczny. Po zweryfikowaniu tożsamości serwera za pomocą lokalnego zaufanego magazynu CA, klient generuje tajny klucz sesji, szyfruje go przy użyciu publicznego klucz i wysyła go. Serwer odszyfrowuje tajny klucz sesji przy użyciu swojego klucza prywatnego i wysyła potwierdzenie do klienta. Ustanowiono bezpieczny kanał. "
źródło
Mehaase już to szczegółowo wyjaśnił. Dodam moje 2 centy do tej serii. Mam wiele postów na blogu dotyczących uzgadniania SSL i certyfikatów. Chociaż większość z nich dotyczy serwera internetowego IIS, post nadal dotyczy ogólnie uzgadniania SSL / TLS. Oto kilka w celach informacyjnych:
Ustanawianie zaufania między komunikującymi się stronami za pośrednictwem magazynu certyfikatów
Komunikacja SSL / TLS działa wyłącznie na zasadzie zaufania. Każdy komputer (klient / serwer) w Internecie ma listę głównych i pośrednich urzędów certyfikacji, które utrzymuje. Są one okresowo aktualizowane. Podczas uzgadniania SSL jest używany jako odniesienie do ustanowienia zaufania. Na przykład podczas uzgadniania SSL, gdy klient dostarcza certyfikat do serwera. Serwer spróbuje sprawdzić, czy urząd certyfikacji, który wydał certyfikat, znajduje się na jego liście urzędów certyfikacji. Gdy nie może tego zrobić, deklaruje, że nie może przeprowadzić weryfikacji łańcucha certyfikatów. (To jest część odpowiedzi. Dotyczy również AIAw tym celu). Klient przeprowadza również podobną weryfikację certyfikatu serwera, który otrzymuje w funkcji Server Hello. W systemie Windows za pomocą programu PowerShell można wyświetlić magazyny certyfikatów dla klienta i serwera. Wykonaj poniższe czynności z konsoli programu PowerShell.
Przeglądarki takie jak Firefox i Opera nie polegają na podstawowym systemie operacyjnym do zarządzania certyfikatami. Utrzymują własne, oddzielne magazyny certyfikatów.
Uzgadnianie SSL wykorzystuje zarówno szyfrowanie symetryczne, jak i kryptografię klucza publicznego. Uwierzytelnianie serwera odbywa się domyślnie. Uwierzytelnianie klienta jest opcjonalne i zależy od tego, czy punkt końcowy serwera jest skonfigurowany do uwierzytelniania klienta, czy nie. Zapoznaj się z moim wpisem na blogu, ponieważ szczegółowo to wyjaśniłem.
Wreszcie na to pytanie
Certyfikaty to po prostu plik, którego format jest zdefiniowany przez standard X.509 . Jest to dokument elektroniczny, który potwierdza tożsamość strony komunikującej się. HTTPS = HTTP + SSL to protokół, który definiuje wytyczne dotyczące sposobu komunikacji między 2 stronami.
WIĘCEJ INFORMACJI
Jeśli powyższa czynność zostanie wykonana, będziesz mieć rzetelne zrozumienie certyfikatów i SSL.
źródło