Frage:
Verhindert https Angriffe von Proxyservern in der Mitte?
jojo
2011-10-15 05:23:38 UTC
view on stackexchange narkive permalink

Es gibt einen Desktop-Client A, der in einer https-Verbindung eine Verbindung zur Website W herstellt.

  A --> W  

Irgendwie zwischen A und W, dort ist ein Proxy G.

  A --> G --> W  
  • In diesem Fall kann G das Zertifikat erhalten Was hat W offensichtlich von W bekommen?
  • Wenn G das Zertifikat erhalten kann, bedeutet das, dass G die Daten entschlüsseln kann?
Sieben antworten:
#1
+213
Hendrik Brummermann
2011-10-22 01:19:03 UTC
view on stackexchange narkive permalink

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.

Wenn der Administrator und der Computer zusammenarbeiten, werden keine Zertifikatwarnungen angezeigt. Wie kann der Benutzer wissen, ob der Proxy die Konversation abhört? Afaik mein Unternehmen scannt https, aber ich sehe das selbstsignierte Zertifikat nicht in der Kettenvertrauensstellung, wenn ich die Zertifikate von https-Sites überprüfe.
Sie können es erkennen. 1. Ihr Unternehmenszertifikat ist kein selbstsigniertes. Es handelt sich um ein ordnungsgemäß von einer Behörde unterzeichnetes Zertifikat, das automatisch in den gesamten Internet Explorer der Welt eingebettet ist. Um alle Berechtigungen für ** magische ** Zertifikate ohne Ihre Ankündigung zu erkennen, gibt es einen eindeutigen, aber harten Pfad. Entfernen Sie alle magisch autorisierten Stammzertifikate in Ihrem Internet Explorer. Ab diesem Ausgangspunkt müssen Sie alle Serverzertifikate explizit akzeptieren. Sie müssen sie lesen, verstehen und diejenigen akzeptieren, denen Sie vertrauen.
Eine Frage ist: Ich kann nicht sehen, was das Netzwerk verlässt, aber was ist mit der Antwort, die der Server an den Browser zurückgesendet hat? Jetzt habe ich einen öffentlichen Schlüssel. Bedeutet das, dass ich alle Antworten dekodieren kann und alles gesehen habe, was der Browser ist sehen?
Mit dem öffentlichen Schlüssel können Sie nur Daten verschlüsseln und werden nur für die Aushandlung des Sitzungsschlüssels verwendet. (@Hendrik Sie können möglicherweise den Teil über die Verwendung des öffentlichen Schlüssels durch den Browser verbessern.)
Jeder, der in der Lage ist, ein Zertifikat für den Proxy zu generieren, der mit einem Signaturzertifikat eines von Ihrem Computer vertrauenswürdigen Ca signiert ist, kann Ihre Verbindung abfangen. Gibt es RFCs / Tech-Outs, die dies verhindern können? Mir sind einige Plugins bekannt, die eine Cert-Fingerabdruck-Datenbank bereitstellen und Sie warnen, wenn der Cert-Fingerabdruck, den Sie erhalten, nicht mit dem Plugin-Server übereinstimmt, diese aber möglicherweise auch abgefangen werden. Obwohl https-Proxys heutzutage nur in Unternehmen verwendet werden, wie Sie beschrieben haben, eröffnen sich Angreifern mit ausreichendem Einfluss Möglichkeiten für Mitm-Angriffe, um vertrauenswürdige Zertifizierungsstellen in die Hände zu bekommen.
@masi Es gibt ein Projekt namens [Certificate Patrol] (http://patrol.psyced.org/), das zuvor gesehene Zertifikate verfolgt und Sie benachrichtigen kann, wenn sich ein Zertifikat unerwartet ändert. Dies ist im oben beschriebenen Unternehmenskontext nicht hilfreich, kann jedoch auf einem mobilen Gerät hilfreich sein, um Sie zu benachrichtigen, wenn Ihr lokales Netzwerk feindlich eingestellt ist.
Und was ist mit der Antwort, die das W an A zurücksendet? Wird G es lesen können?
@se7entyse7en-Nr.Genau wie W einen privaten Schlüssel hat, richtet A einen solchen Schlüssel zu Beginn der Kommunikation ein.G hat keinen dieser Schlüssel.
@zinking Nein, Sie können nicht, der öffentliche / private Schlüssel wird nur zum Erstellen eines Sitzungsschlüssels verwendet, und dieser Sitzungsschlüssel wird zum Ver- / Entschlüsseln des gesamten Datenverkehrs zwischen https-Client / Server verwendet, da die symmetrische Verschlüsselung schneller sein muss.
Guter Artikel.Vielen Dank.Ich habe eine Frage: Kann "G" vor der Verhandlung des Sitzungsschlüssels den öffentlichen Schlüssel vom Webserver erfassen und eine Verhandlung des Sitzungsschlüssels früher als "A" fortsetzen, damit er als "A" fungieren kann?
@Jeon, Der öffentliche Schlüssel (und die Zertifikatinformationen) sind öffentlich, sodass jeder darauf zugreifen kann.Während des TLS-Handshakes muss der Server jedoch nachweisen, dass er den zugehörigen privaten Schlüssel kennt.Irgendwann verschlüsselt der Client eine nicht erratene Information mit dem öffentlichen Schlüssel, und der Server muss sie mit seinem privaten Schlüssel entschlüsseln, um den Handshake fortzusetzen.Weitere Informationen finden Sie im [Wikipedia-Artikel zum TLS] (https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake).
Können Sie hier weitere Informationen hinzufügen: "Vernichten Sie die Unterschrift der Zertifizierungsstellen".Warum kann "G" seinen öffentlichen Schlüssel nicht für "A" bereitstellen und das Zertifikat so fälschen, dass es korrekt mit seinem eigenen privaten Schlüssel signiert ist?Ist es also doppelt signiert, einmal von "W" und einmal von "Truzsted Certificate Provider" und "A" kennt auch diesen öffentlichen Schlüssel.
Wie stellt dies ein Sicherheitsrisiko für Webanwendungen dar?
Ein weiterer Fall, der das Konzept untergräbt, können Formen vorinstallierter Bloatware sein.Der bekannteste Fall, an den ich mich erinnern kann, war die Installation von "SuperFish" durch Lenovo.Obwohl dies letztendlich nur das Äquivalent von "der Administrator kooperiert" ist, wenn auch in diesem Fall unwissentlich.
Beachten Sie, dass in neueren Versionen von Firefox "Verbindung von einem von Mozilla nicht erkannten Zertifikataussteller überprüft" für nicht von NSS genehmigte Zertifikate angezeigt wird, sodass (im Gegensatz zu Chrome und IE) aktuelle COTS TLS-Proxys von einem Firefox-Benutzer mit erkannt werden könnenNur 1 Klick forensische Untersuchung.
#2
+21
D.W.
2011-10-15 07:38:17 UTC
view on stackexchange narkive permalink

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.

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

Angenommen, keine Stammzertifizierungsstelle wird geöffnet und verliert die Kontrolle über ihren privaten Schlüssel.
Es ist eine faire Annahme, dass (Stamm- und delegierte) Zertifizierungsstellen ihren nationalen Geheimdiensten gefälschte Zertifikate liefern. Anscheinend gab es vermutlich versehentlich eine öffentliche Vermarktung von Proxy-Geräten, die diese Art von Zertifikaten verwenden.
Tatsächlich führt [Blue Coat ProxySG] (https://www.bluecoat.com/products/proxysg) seit langer Zeit MiTM auf HTTPS durch, indem es von benutzerdefinierten vertrauenswürdigen Zertifikaten abhängig ist, die auf Clients installiert werden, die über sie zugreifen, und im Grunde so tun, als ob dies der Fall wäre CA zusätzlich zu einem Caching-Proxy. Ähnlich verhält es sich mit Nokia, Opera Mobile, Amazon Kindle usw., indem vertrauenswürdige Stammzertifikate auf ihren Clients installiert und dann alle Anforderungen über ihre gefälschten CA-Server weitergeleitet werden. Kurz gesagt, jeder, der behauptet oder zu sein scheint, HTTPS-Inhalte "dazwischen" zwischenzuspeichern, erneut zu komprimieren oder auf andere Weise zu optimieren, tut dies.
Natürlich kann ein Proxy Daten entschlüsseln - Sie stellen eine SSL-Verbindung zum Proxy her, der Proxy entschlüsselt alles und stellt dann eine SSL-Verbindung zum tatsächlichen Ziel her und umgekehrt zu der Antwort: http://www.zdnet.com/article/how-the- nsa-und-dein-Chef-kann-abfangen-und-brechen-ssl /
@markmnl Dies erfordert, dass Clients so eingerichtet sind, dass sie den Zertifikaten des Proxys vertrauen, oder dass Benutzer die resultierenden Fehlermeldungen blind ablehnen (eine gute Wette, um ehrlich zu sein). Aus dem Artikel, den Sie verlinkt haben: "Wenn Ihr Unternehmen den Proxy korrekt eingerichtet hat, wissen Sie nicht, dass etwas nicht stimmt, 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. "
#3
+19
manav m-n
2014-09-17 12:33:31 UTC
view on stackexchange narkive permalink

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.

enter image description here

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.

enter image description here

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:

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

Ist es möglich, das Original-Facebook-Zertifikat von Man-in-the-Middle zu unterscheiden?
@manav sind Sie sicher, indem Sie facebbok.com mitteilen und zeigen, wo das Zertifikat funktioniert?
@SudhanshuGaur glauben Sie wirklich, dass die oben genannten Informationen ausreichen, um facebbok.com zu hacken !!Die bereitgestellten Informationen sind sehr einfach und alte und heutige organisatorische Sicherheitssysteme sind sowohl bei der HW- als auch bei der SW-Entschlüsselung meilenweit voraus
#4
+8
Rory McCune
2014-03-26 13:52:25 UTC
view on stackexchange narkive permalink

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.

#5
+8
Bill McGonigle
2014-03-30 08:43:06 UTC
view on stackexchange narkive permalink

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.

#6
+4
Erik van Velzen
2017-03-10 05:16:09 UTC
view on stackexchange narkive permalink

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.

#7
+2
Danny Lieberman
2015-09-01 14:46:51 UTC
view on stackexchange narkive permalink

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?



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...