Jak weryfikowane są certyfikaty ssl?

Jaka jest seria kroków potrzebnych do bezpiecznej weryfikacji certyfikatu ssl? Moje (bardzo ograniczone) zrozumienie polega na tym, że gdy odwiedzasz witrynę https, serwer wysyła certyfikat do klienta (przeglądarki), a przeglądarka pobiera informacje o wystawcy certyfikatu z tego certyfikatu, a następnie używa ich do kontaktu z wystawcą i w jakiś sposób porównuje certyfikaty pod względem ważności.

    Jak to się dokładnie robi?
  • co z procesem czyni go odpornym na man-in-the-middle ataki?
  • co uniemożliwia jakiejś przypadkowej osobie skonfigurowanie własnej usługi weryfikacji do wykorzystania w atakach typu man-in-the-middle, więc wszystko "wygląda" bezpiecznie?
Author: matt b, 2008-10-09

5 answers

Oto bardzo uproszczone wyjaśnienie:

  1. Twoja przeglądarka pobiera certyfikat serwera WWW, który zawiera klucz publiczny serwera www. Ten certyfikat jest podpisany kluczem prywatnym zaufanego urzędu certyfikacji.

  2. Twoja przeglądarka internetowa jest instalowana z kluczami publicznymi wszystkich głównych organów certyfikujących. Używa tego klucza publicznego do sprawdzenia, czy certyfikat serwera sieci web został rzeczywiście podpisany przez zaufany certyfikat autorytet.

  3. Certyfikat zawiera nazwę domeny i / lub adres ip serwera www. Przeglądarka internetowa potwierdza w urzędzie certyfikacji, że adres wymieniony w certyfikacie jest adresem, z którym ma otwarte połączenie.

  4. Twoja przeglądarka internetowa generuje współdzielony klucz symetryczny, który będzie używany do szyfrowania ruchu HTTP na tym połączeniu; jest to o wiele bardziej efektywne niż korzystanie z szyfrowania klucza publicznego/prywatnego dla wszystkiego. Twoja przeglądarka szyfruje klucz symetryczny z kluczem publicznym serwera sieci Web, a następnie odsyła go z powrotem, zapewniając, że tylko serwer sieci web może go odszyfrować, ponieważ tylko serwer sieci Web ma swój klucz prywatny.

Zauważ, że urząd certyfikacji (CA) jest niezbędny do zapobiegania atakom typu man-in-the-middle. Jednak nawet niepodpisany certyfikat uniemożliwi pasywne podsłuchiwanie twojego zaszyfrowanego ruchu, ponieważ nie ma możliwości uzyskania dostępu do współdzielonego klucza symetrycznego.

 226
Author: Eli Courtwright,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-11-30 20:25:39

Warto zauważyć, że oprócz zakupu certyfikatu (jak wspomniano powyżej), możesz również utworzyć swój własny za darmo; jest to określane jako "certyfikat z własnym podpisem". Różnica między certyfikatem podpisanym samodzielnie a zakupionym jest prosta: zakupiony certyfikat został podpisany przez urząd certyfikacji, o którym twoja przeglądarka już wie. Innymi słowy, przeglądarka może łatwo zweryfikować autentyczność zakupionego certyfikatu.

Niestety to ma doprowadziło to do błędnego przekonania, że certyfikaty podpisane samodzielnie są z natury mniej bezpieczne niż te sprzedawane przez komercyjne urzędy certyfikacji, takie jak GoDaddy i Verisign, i że musisz żyć z ostrzeżeniami/wyjątkami przeglądarki, jeśli ich używasz; jest to nieprawidłowe .

Jeśli bezpiecznie rozpowszechnisz certyfikat z podpisem własnym (lub certyfikat CA, jak sugerował bobince) i zainstalujesz go w przeglądarkach, które będą korzystać z twojej witryny, jest on tak samo bezpieczny jak zakupiony i nie jest podatny na ataki man-in-the-middle i fałszerstwo cert. Oczywiście oznacza to, że jest to możliwe tylko wtedy, gdy tylko kilka osób potrzebuje bezpiecznego dostępu do twojej witryny (np.).

W celu zwiększenia świadomości i zachęcenia innych małych blogerów, takich jak ja, do ochrony siebie, napisałem samouczek na poziomie podstawowym, który wyjaśnia bardziej szczegółowo pojęcia stojące za certyfikatami i jak bezpiecznie tworzyć i używać certyfikatów podpisanych samodzielnie (wraz z sample kodu i screeny). Oto link na wypadek, gdyby był pomocny dla kogokolwiek w przyszłości: http://www.clintharris.net/2009/self-signed-certificates/.

 43
Author: Clint Harris,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-05 02:16:53

You said that

Przeglądarka pobiera informacje o wystawcy certyfikatu z tego certyfikat, a następnie używa go do kontaktu z wystawcą i jakoś porównuje certyfikaty pod względem ważności.

Klient nie musi sprawdzać u Emitenta, ponieważ dwie rzeczy:

  1. wszystkie przeglądarki mają wstępnie zainstalowaną listę wszystkich głównych kluczy publicznych CAs
  2. certyfikat jest podpisany, a sam podpis jest wystarczającym dowodem na to, że certyfikat jest ważny ponieważ klient może samodzielnie i bez kontaktu z serwerem wystawcy upewnić się, że certyfikat jest autentyczny. Na tym polega piękno szyfrowania asymetrycznego.

Zauważ, że 2. nie da się zrobić bez 1.

To jest lepiej wyjaśnione w tym Duży diagram zrobiłem jakiś czas temu

(przejdź do "co to jest podpis ?"na dole)

blob

 14
Author: ychaouche,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-02 09:48:20

Klient ma wstępnie ustawiony magazyn kluczy publicznych urzędów certyfikatów SSL. Aby serwer mógł być zaufany, musi istnieć łańcuch zaufania od certyfikatu dla serwera przez władze pośredniczące do jednego z tak zwanych certyfikatów "root".

Możesz sprawdzić i / lub zmienić listę zaufanych organów. Często robisz to, aby dodać certyfikat dla lokalnego organu, któremu ufasz - jak firma, dla której pracujesz, Szkoła, do której uczęszczasz lub co nie.

Wstępnie ustawiona lista może się różnić w zależności od klienta, którego używasz. Najwięksi dostawcy certyfikatów SSL zapewniają, że ich certyfikaty główne są we wszystkich głównych przeglądarkach ($$$).

Ataki typu "Małpa w środku" są "niemożliwe", chyba że atakujący ma klucz prywatny zaufanego certyfikatu głównego. Ponieważ odpowiednie certyfikaty są szeroko stosowane, narażenie takiego klucza prywatnego miałoby poważne konsekwencje dla ogólnego bezpieczeństwa handlu elektronicznego. Z tego powodu, te klucze prywatne są bardzo, bardzo pilnie strzeżone.

 6
Author: nsayer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-09 17:39:36

Jeśli jesteś bardziej technicznie myślący, ta strona jest prawdopodobnie tym, czego chcesz: http://www.zytrax.com/tech/survival/ssl.html

Uwaga: królicza Nora idzie głęboko :).

 6
Author: Mike Frysinger,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-22 19:27:16