it-swarm-eu.dev

Verhindert https Angriffe von Proxyservern in der Mitte?

Es gibt einen Desktop-Client A, der über eine https-Verbindung eine Verbindung zur Website W herstellt

A --> W

Irgendwie gibt es zwischen A und W einen Proxy G.

A --> G --> W
  • Kann G in diesem Fall das Zertifikat erhalten, das A zuvor von W erhalten hat?
  • Wenn G das Zertifikat erhalten kann, bedeutet dies, dass G die Daten entschlüsseln kann?
183
jojo

Wie funktioniert HTTPS?

HTTPS basiert auf Kryptographie 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 einer Bezeichnung, die den Eigentümer identifiziert.

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 muss von einer vertrauenswürdigen Zertifizierungsstelle signiert werden.

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

Nach der Überprüfung extrahiert der Browser extrahiert den öffentlichen Schlüssel und verwendet ihn, um einige Informationen zu verschlüsseln, bevor sie an den Server gesendet werden. Der Server kann es entschlüsseln, weil der Server hat den passenden privaten Schlüssel.

Wie verhindert HTTPS Angriffe von Menschen in der Mitte?

Kann G in diesem Fall das Zertifikat erhalten, das A zuvor von W erhalten hat?

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

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

Nein. Das Zertifikat enthält das öffentlicher Schlüssel des Webservers. Der böswillige Proxy befindet sich 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 kooperiert, 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.

Ein lokale Zertifizierungsstelle ist 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, Sicherheitswarnungen wegzuklicken.

209

Unter der Annahme, dass Benutzer nicht durch Zertifizierungswarnungen klicken (und davon ausgehen, dass Sie einen nicht geä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.

P.S. 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.)

20
D.W.

Aus Philipp C. Heckels Tech-Blog mit einigen leichten Änderungen:

Während der Angriff auf unverschlüsselten HTTP-Verkehr ohne X.509-Zertifikate und Zertifizierungsstellen erfolgen kann, verschlüsseln SSL-verschlüsselte HTTPS-Verbindungen 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 verbunden ist. 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: Anstatt Zertifikate an tatsächliche Personen oder Organisationen auszustellen, 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.

enter image description here

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

  • Proxyserver als Standardgateway (HTTP und HTTPS) : Sowohl für HTTP- als auch für HTTPS-Proxy muss der Proxyserver natürlich in der Lage sein, die IP-Pakete abzufangen - Dies bedeutet, dass es sich irgendwo auf dem Weg des Paketpfads befinden muss. Der einfachste Weg, dies zu erreichen, besteht darin, das Standard-Gateway im Client-Gerät in die Proxy-Server-Adresse zu ändern.
  • Vertrauenswürdige Proxy-Zertifizierungsstelle (nur HTTPS) : Damit die HTTPS-Proxy-Funktion funktioniert, muss der Client die Proxy-Zertifizierungsstelle (dh den CA-Schlüssel) kennen (und dieser vertrauen!) Die Datei muss dem Trust Store des Clients hinzugefügt werden.

enter image description here

Wenn Sie an einfachen SSL-Sockets transparent schnüffeln möchten, 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?


Aus Steven J. Vaughan-Nichols im ZDNet (Auszug):

Blue Coat, der größte Name im SSL-Interception-Geschäft, ist bei weitem nicht der einzige, der SSL-Interception anbietet und in einer Box einbricht. 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. Wenn ein SSL-Interception-Proxy-Programm oder -Gerät installiert ist, geschieht Folgendes wirklich:

enter image description here

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. Hoppla.

19
manav m-n

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 natürlich möglich, Datenverkehr im Netzwerk abzufangen. Das übliche Problem besteht jedoch darin, dass nicht für alle von Ihnen besuchten Sites gültige Zertifikate ausgestellt werden können. Daher werden bei jedem Zugriff auf eine HTTPS-Site zahlreiche Zertifikatswarnungen angezeigt Sie versuchen, den Verkehr zu entschlüsseln, um ihn anzusehen.

Wenn Sie jedoch einen von der Firma bereitgestellten Computer verwenden, kann dieser eine neue Zertifizierungsstelle installieren und diese dann zum Erstellen von SSL-Zertifikaten für von Ihnen besuchte Sites verwenden, sodass dies nicht als Problem angezeigt wird.

Auf der VPN-Seite könnte es komplexer sein, wenn das VPN kein SSL verwendet, aber die gleiche 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 ein Gerät verwenden, das Sie besitzen/steuern, um auf das Internet zuzugreifen. Auf diese Weise sollten Sie gewarnt werden, wenn ein SSL-Abfangen auftritt.

8
Rory McCune

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 Ihren Datenverkehr nicht abfangen und dekodieren, da 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.

7
Bill McGonigle

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.

4
Erik van Velzen

SSL-Terminierungs- oder SSL-Proxy-Produkte wie Bluecoat müssen sich in Ihrem Netzwerk befinden und unter Berücksichtigung der Kosten, der Installationsverfahren und der normalen Sicherheitsrichtlinien, die jedes Unternehmen haben würde, das diese Produkte installiert - die Bedrohung durch einen böswilligen Angreifer, der ein kommerzielles SSL-Terminierungsprodukt verwendet 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 Anliegen (gerechtfertigt oder nicht) für Unternehmen, die DLP-Systeme implementieren.

JEDOCH HAT ALLES GESAGT - es gibt einen anderen Angriffsvektor, der im Home-Banking-Bereich üblich ist, für den kein Netzwerk-Proxy erforderlich ist und bei dem es sich um Piggback-/Shim-Angriffe im Browser handelt - da das DOM Zugriff auf Klartextverkehr hat, bevor es auf den trifft SSL-Pipe - Dies ist ein praktischer Angriffsvektor und wird häufig über eine Browser-Erweiterung installiert. Es gibt einen ausgezeichneten Stackexchange-Artikel über Shims - Kann ein Shim (auch bekannt als Polyfill) in IE, FF oder Chrome ohne Benutzerwissen installiert werden und kann vom Benutzer eingegebene Passwörter lesen)? auf einer Anmeldeseite?

2
Danny Lieberman