Wie funktioniert HTTPS?

HTTPS basiert auf Kryptografie mit öffentlichem / privatem Schlüssel . Dies bedeutet im Grunde, dass es ein Schlüsselpaar gibt: Der öffentliche Schlüssel wird zur Verschlüsselung verwendet und der geheime private Schlüssel wird zur Entschlüsselung benötigt.

Ein Zertifikat ist im Grunde ein öffentlicher Schlüssel mit einem Beschriftung zur Identifizierung des Eigentümers.

Wenn Ihr Browser eine Verbindung zu einem HTTPS-Server herstellt, antwortet der Server mit seinem Zertifikat. Der Browser prüft, ob das Zertifikat gültig ist. :

• Die Eigentümerinformationen müssen mit dem vom Benutzer angeforderten Servernamen übereinstimmen.
• das Zertifikat benötigt von einer vertrauenswürdigen Zertifizierungsstelle zu signieren.

Wenn eine dieser Bedingungen nicht erfüllt ist, wird der Benutzer über das Problem informiert.

Nach der Überprüfung wird die browser extrahiert den öffentlichen Schlüssel und verschlüsselt damit einige Informationen, bevor sie an den Server gesendet werden. Der Server kann es entschlüsseln, da der Server über den passenden privaten Schlüssel verfügt.

Wie verhindert HTTPS Angriffe durch Menschen in der Mitte?

In diesem Fall In diesem Fall kann G das Zertifikat erhalten, das A zuvor von W erhalten hat?

Ja, das Zertifikat ist der öffentliche Schlüssel mit der Bezeichnung. Der Webserver sendet es an jeden, der eine Verbindung dazu herstellt.

Wenn G das Zertifikat erhalten kann, bedeutet dies, dass G die Daten entschlüsseln kann?

Nein. Das Zertifikat enthält den öffentlichen Schlüssel des Webservers . Der böswillige Proxy ist nicht im Besitz des passenden privaten Schlüssels. Wenn der Proxy das echte Zertifikat an den Client weiterleitet, kann er keine Informationen entschlüsseln, die der Client an den Webserver sendet.

Der Proxyserver versucht möglicherweise, das Zertifikat zu fälschen und stattdessen seinen eigenen öffentlichen Schlüssel bereitzustellen. Dies wird jedoch die Unterschrift der Zertifizierungsstellen zerstören. Der Browser warnt vor dem ungültigen Zertifikat.

Gibt es eine Möglichkeit, wie ein Proxyserver HTTPS lesen kann?

Wenn der Administrator Ihres Computers zusammenarbeitet , kann ein Proxyserver https-Verbindungen abhören. Dies wird in einigen Unternehmen verwendet, um nach Viren zu suchen und Richtlinien für eine akzeptable Verwendung durchzusetzen.

Eine lokale Zertifizierungsstelle wird eingerichtet, und der Administrator teilt Ihrem Browser mit, dass dies CA ist vertrauenswürdig . Der Proxyserver verwendet diese Zertifizierungsstelle, um seine gefälschten Zertifikate zu signieren.

Oh, und natürlich neigen Benutzer dazu, auf Sicherheitswarnungen zu klicken.

Unter der Annahme, dass Benutzer nicht durch Zertifizierungswarnungen klicken (und davon ausgehen, dass Sie einen unveränderten Client ausführen), lautet die Antwort: Nein, der Proxy kann die Daten nicht entschlüsseln. .

Eine ausführliche Erklärung, wie HTTPS verhindert, dass ein Mann in der Mitte Ihren Datenverkehr entschlüsselt, finden Sie in einer Standardressource zu SSL / TLS, z. B.

• Wie Ist es möglich, dass Personen, die beobachten, dass eine HTTPS-Verbindung hergestellt wird, nicht wissen, wie sie entschlüsselt werden soll?

• Wikipedia-Seite auf TLS

PS Das Zertifikat besteht aus öffentlichen Daten. Es enthält den öffentlichen Schlüssel und den Domänennamen des Servers, von denen keiner geheim ist. Das Beobachten des Zertifikats hilft dem Angreifer nicht, die Daten zu entschlüsseln. (Ja, der Proxy kann das Zertifikat beobachten, dies ist jedoch harmlos.)

Aus Philipp C. Heckels Tech-Blog mit einigen geringfügigen Änderungen:

Während des Angriffs auf unverschlüsselten HTTP-Verkehr kann dies ohne X.509-Zertifikate und erfolgen Zertifizierungsstellen (CA), SSL-verschlüsselte HTTPS-Verbindungen verschlüsseln jede Anforderung und Antwort zwischen Client und Server durchgehend. Und da die übertragenen Daten mit einem gemeinsamen Geheimnis verschlüsselt sind, kann ein Middle Man (oder ein Proxy) die ausgetauschten Datenpakete nicht entschlüsseln. Wenn der Client eine SSL / TLS-Verbindung zum sicheren Webserver öffnet, überprüft er die Identität des Servers, indem er zwei Bedingungen überprüft: Erstens überprüft er, ob sein Zertifikat von einer dem Client bekannten Zertifizierungsstelle signiert wurde. Und zweitens wird sichergestellt, dass der allgemeine Name (CN, auch: Hostname) des Servers mit dem übereinstimmt, mit dem er eine Verbindung herstellt. Wenn beide Bedingungen erfüllt sind, geht der Client davon aus, dass die Verbindung sicher ist.

Um in die Verbindung hineinschnüffeln zu können, kann der Proxyserver als Zertifizierungsstelle fungieren, jedoch nicht als sehr vertrauenswürdig: Stattdessen Bei der Ausstellung von Zertifikaten an tatsächliche Personen oder Organisationen generiert der Proxy dynamisch Zertifikate für jeden Hostnamen, der für eine Verbindung benötigt wird. Wenn ein Client beispielsweise eine Verbindung zu https://www.facebook.com herstellen möchte, generiert der Proxy ein Zertifikat für „www.facebook.com“ und signiert es mit seiner eigenen Zertifizierungsstelle. Vorausgesetzt, der Client vertraut dieser Zertifizierungsstelle, sind beide oben genannten Bedingungen erfüllt (vertrauenswürdige Zertifizierungsstelle, dieselbe CN). Dies bedeutet, dass der Client der Ansicht ist, dass der Proxyserver tatsächlich "www.facebook.com" ist. Die folgende Abbildung zeigt den Anforderungs- / Antwortfluss für dieses Szenario. Dieser Mechanismus wird als transparentes HTTPS-Proxy bezeichnet.

Damit dieser Angriff funktioniert, müssen einige Bedingungen erfüllt sein:

• Proxyserver als Standard-Gateway (HTTP und HTTPS) : Für HTTP- und HTTPS-Proxy muss der Proxyserver natürlich in der Lage sein, die IP-Pakete abzufangen - das heißt, er muss sich irgendwo entlang des befinden Weg des Paketpfades. Der einfachste Weg, dies zu erreichen, besteht darin, das Standard-Gateway auf dem Clientgerät in die Proxyserveradresse zu ändern.
• Vertrauenswürdige Proxy-Zertifizierungsstelle (nur HTTPS) : Damit das HTTPS-Proxy funktioniert muss der Client die Proxy-Zertifizierungsstelle kennen (und ihr vertrauen!), dh die CA-Schlüsseldatei muss dem Vertrauensspeicher des Clients hinzugefügt werden.

Wenn Sie daran interessiert sind, einfache SSL-Sockets transparent zu beschnüffeln, sollten Sie SSLsplit ausprobieren, einen transparenten TLS / SSL-Man-in-the-Middle-Proxy. Es gibt viele Möglichkeiten, SSL anzugreifen, aber Sie benötigen keine gefälschten SSL-Zertifikate, keine betrügerische Zertifizierungsstelle (CA) oder Variationen der Man-in-the-Middle-SSL-Angriffe von Sicherheitsexperte Moxie Marlinspike. Warum sollten Sie sich all diese Mühe machen, wenn Sie nur einen SSL-Interception-Proxy wie ProxySG von Blue Coat Systems oder die kürzlich erworbene Netronome SSL-Appliance kaufen können, um die Aufgabe für Sie zu erledigen?

Von Steven J. Vaughan-Nichols auf ZDNet (Auszug):

Blue Coat, der größte Name im SSL-Abhörgeschäft, ist bei weitem nicht der einzige SSL-Interception anbieten und in eine Box einbrechen. Bis vor kurzem hat Microsoft Ihnen beispielsweise ein Programm, Forefront Threat Management Gateway 2010, verkauft, das diese Aufgabe auch für Sie übernehmen könnte. Mit einem vorhandenen SSL-Interception-Proxy-Programm oder -Gerät geschieht Folgendes:

Wenn Ihr Unternehmen den Proxy korrekt eingerichtet hat, wissen Sie nicht, dass etwas nicht funktioniert, da das interne SSL-Zertifikat des Proxys als gültiges Zertifikat auf Ihrem Computer registriert wurde. Wenn nicht, erhalten Sie eine Popup-Fehlermeldung, die, wenn Sie auf klicken, um fortzufahren, das "gefälschte" digitale Zertifikat akzeptiert. In beiden Fällen erhalten Sie eine sichere Verbindung zum Proxy, eine sichere Verbindung zur externen Site - und alles, was über den Proxy gesendet wird, kann im Klartext gelesen werden. Whoops.

Abhängig von der Konfiguration des Netzwerks, in dem Sie sich befinden, können Administratoren möglicherweise den Inhalt von HTTPS-Verbindungen (und möglicherweise VPNs) anzeigen.

Es ist offensichtlich möglich, Datenverkehr im Netzwerk abzufangen. Das übliche Problem besteht jedoch darin, dass nicht für alle von Ihnen besuchten Websites gültige Zertifikate ausgestellt werden können, sodass jedes Mal viele Zertifikatswarnungen angezeigt werden Sie greifen auf eine HTTPS-Site zu, wenn sie versuchen, den Datenverkehr zu entschlüsseln, um ihn anzuzeigen.

Wenn Sie jedoch einen von der Firma bereitgestellten Computer verwenden, können sie eine neue Zertifizierungsstelle installieren und diese dann verwenden Erstellen Sie SSL-Zertifikate für Websites, die Sie besuchen, damit dies nicht als Problem angezeigt wird.

Auf der VPN-Seite könnte es komplexer sein, wenn das VPN kein SSL verwendet, aber dieselbe Theorie gilt. Wenn Sie von einem Computer aus auf das Internet zugreifen, der einer anderen Person in einem von ihr kontrollierten Netzwerk gehört, kann diese wahrscheinlich auf alle von Ihnen eingegebenen Inhalte zugreifen.

Wenn Sie diese Art von Problem vermeiden möchten, würde ich verwenden Ein Gerät, das Sie besitzen / steuern, um auf das Internet zuzugreifen. Auf diese Weise sollten Sie gewarnt werden, wenn ein SSL-Abfangen auftritt.

Richtig, die Administratoren des Unternehmensnetzwerks implementieren einen Man-in-the-Middle-Angriff gegen den TLS-Client mit ihrer eigenen Zertifizierungsstelle, damit sie sehen können, was ihr Netzwerk verlässt. Sie werden wahrscheinlich über ein Gerät verfügen, das im laufenden Betrieb ein Zertifikat erstellt, das für gmail.com gültig ist, wenn Sie gmail.com besuchen. Der Grund, warum sie dies tun, ist nicht, Dr. Evil zu spielen, sondern um zu verhindern, dass Geschäftsgeheimnisse über ihre Internetverbindung aus ihrem Gebäude gebracht werden. Im Ernst, machen Sie Ihr Private Banking nicht auf einem Arbeitscomputer.

Wenn Sie ein Softwareprodukt verwenden, das den Systemzertifikatsspeicher nicht verwendet (z. B. eine OpenVPN-Instanz), können diese nicht abfangen und dekodieren Sie Ihren Datenverkehr, weil Sie ihrer Zertifizierungsstelle nicht vertrauen. Sie können das gleiche Ergebnis beispielsweise mit einer tragbaren Firefox-App erzielen. In den meisten Browsern können Sie die Details Ihrer sicheren Verbindung überprüfen und feststellen, wer die Zertifizierungsstelle ist, um sicherzugehen, wer zuhört oder nicht.

Der Proxy kann https blockieren und nur http vom Browser zulassen. Anschließend kann es eine eigene https-Verbindung initiieren, um die Anforderungen an den Server weiterzuleiten.

Die meisten Benutzer werden es nicht bemerken.

HSTS soll dies stoppen, ist aber nicht weit verbreitet.

SSL-Terminierungs- oder SSL-Proxy-Produkte wie Bluecoat müssen sich in Ihrem Netzwerk befinden und die Kosten, die Installationsverfahren und die normalen Sicherheitsrichtlinien berücksichtigen, die jedes Unternehmen haben würde, das diese Produkte installiert - die Bedrohungen eines böswilligen Angreifers, der ein kommerzielles SSL verwendet Terminierungsprodukt ist fast Null. OTOH - ein vertrauenswürdiger Insider mit Zugriff auf das NOC (Network Operations Center) könnte tatsächlich den SSL-terminierten Verkehr überwachen und vertrauliche Informationen offenlegen.

Dies ist ein häufiges Problem (gerechtfertigt oder nicht) für Unternehmen, die DLP-Systeme implementieren

JEDOCH HAT ALLES GESAGT - es gibt einen anderen Angriffsvektor, der im Homebanking-Bereich üblich ist und keinen Netzwerk-Proxy erfordert und im Browser Piggback- / Shim-Angriffe sind - da das DOM Zugriff hat Um den Textverkehr zu löschen, bevor er auf die SSL-Pipe trifft, ist dies ein praktischer Angriffsvektor, der häufig über eine Browsererweiterung installiert wird. Es gibt einen ausgezeichneten Stackexchange-Artikel zu Shims - Kann ein Shim (auch bekannt als Polyfill) ohne Benutzerwissen in IE, FF oder Chrome installiert werden und kann er vom Benutzer auf einer Anmeldeseite eingegebene Kennwörter lesen?