Frage:
Kann eine HTTPS-Verbindung aufgrund eines nicht autorisierten DNS-Servers gefährdet werden?
LanceBaynes
2011-05-16 13:33:51 UTC
view on stackexchange narkive permalink

Wenn ich eine Site besuche (nur einen Desktop-PC, clientseitig), die über ein gültiges HTTPS-Zertifikat / eine gültige HTTPS-Verbindung verfügt, kann dies gefährdet sein, wenn ich einen nicht autorisierten DNS-Server verwende (nicht absichtlich, ich bin besorgt) über einen Angriff auf den DNS-Dienst)?

Ich denke beispielsweise an: Die Site der Zertifizierungsstelle (um die HTTPS-Verbindung zu überprüfen) wird von meinem Nameserver (dem gefährdeten) aufgelöst?

Verwandte [Der Versuch, die SSL-Verbindung zu überprüfen, erfolgt von einem vertrauenswürdigen Host] (http://security.stackexchange.com/questions/1034/can-javascript-flash-verify-the-ssl-connection-to-prevent-session-cookie- und-basi)
Verwandte [Bedeutet eine hergestellte SSL-Verbindung, dass eine Leitung wirklich sicher ist] (http://security.stackexchange.com/questions/5/)
Neun antworten:
#1
+37
john
2011-05-16 14:32:24 UTC
view on stackexchange narkive permalink

Um eine Verbindung zu einer Website über https herzustellen oder nicht, benötigen Sie die IP-Adresse der Website und fragen Ihren DNS-Server anhand des Domainnamens Ihrer Website danach. Wenn Ihr DNS-Server die Antwort nicht zwischengespeichert hat, versucht er, Ihre Anfrage zu lösen, indem er eine ganze Reihe von DNS-Servern fragt (den DNS-Stammserver, den Domänenhandler der obersten Ebene ... bis zu dem für die Domäne autorisierenden DNS-Server).

Ein Angreifer, der einen dieser Server kontrolliert, kann Ihnen mit einer gefälschten IP-Adresse für diese Website antworten. Dies wird Ihr Browser versuchen, zu besuchen. Diese IP-Adresse enthält im Allgemeinen eine Replik der gehosteten Website, damit sie mit der ursprünglichen identisch aussieht, oder fungiert nur als stiller Weiterleiter Ihrer Verbindung zur richtigen Site, nachdem Sie die erforderlichen Informationen erfasst haben. P. >

Nun zu weiteren Details: Wenn die Website HTTPS-geschützt ist, gibt es viele Fallstricke. Auf der normalen Website wird ein Zertifikat ausgestellt, das Details des Domainnamens an die Website bindet. Dies erfolgt jedoch mithilfe einer asymmetrischen Verschlüsselung.

Dies bedeutet, dass die Website durch den Prozess des SSL-Handshakes dazu verpflichtet ist beweisen, dass es Kenntnisse über den privaten Schlüssel hat, der dem öffentlichen Schlüssel im Zertifikat zugeordnet ist. Jetzt kann der böswillige Teilnehmer Ihnen das Originalzertifikat der Website sehr gut zur Verfügung stellen, wenn Sie versuchen, unter dem richtigen Hostnamen auf die falsche IP-Adresse zuzugreifen. Er hat jedoch keine Kenntnis vom privaten Schlüssel, sodass der SSL-Handshake niemals abgeschlossen wird. P. >

Aber es gibt Möglichkeiten für den Abfangjäger, das Ganze zum Laufen zu bringen. Ich kann mir vier vorstellen:

1) Die einfachste Lösung besteht darin, Ihnen ein selbstsigniertes Zertifikat anstelle eines normalen Zertifikats zuzustellen . Dies wird vom Angreifer selbst ausgegeben. Normalerweise warnt Sie Ihr Browser davor, und wenn Sie eine aktuelle Browserversion ausführen, werden die Warnungen überall angezeigt, aber Benutzer neigen dazu, sich durch solche Dinge zu klicken.

2) Ein anderer Ansatz, der bei Stuxnet-Angriffen verwendet wird, besteht darin, die privaten Schlüssel, die für ein gültiges Zertifikat verwendet werden, von der Organisation zu stehlen, deren Identität Sie annehmen möchten.

3) Eine andere Lösung, die in aufgetreten ist In einigen Fällen (wir sprechen hier nicht über den durchschnittlichen Angreifer) nutzt er einen Fehler im Registrierungsverfahren aus, das von Zertifizierungsstellen (oder Registrierungsbehörden) verwendet wird, und schafft es, ein Zertifikat für eine Website auszustellen, die ihm nicht gehört . Es gab Fälle, in denen RAs einfach nicht genügend Überprüfungen durchgeführt und Zertifikate für google.com ausgestellt haben.

4) Ähnlich wie oben: Ein kompetenter Angreifer "hackt" ein Zertifikat oder eine Registrierungsstelle und schafft es, diese auszustellen einige Zertifikate unter welchem ​​Namen auch immer er will. Es geschah im Mai 2011 (der berühmte Comodo-Hack) und im Juli 2011 (der DigiNotar-Hack). Weitere Informationen finden Sie unter Wie machbar ist es, dass eine Zertifizierungsstelle gehackt wird? Welche standardmäßigen vertrauenswürdigen Stammzertifikate sollte ich entfernen? - IT-Sicherheit.

5) Schließlich ist die beängstigendste Technik die, die drei Briefagenturen und ähnliche Parteien anwenden können: Wenn eine Regierung eine Zertifizierungsstelle kontrolliert, kann sie dies theoretisch erzwingen Stellen Sie nach Belieben Zertifikate für jeden Standort aus. Denken Sie jetzt, dass die Zertifizierungsstellen auf der ganzen Welt verteilt sind, einige davon in Ländern, in denen dies sehr gut möglich erscheint. Ein Beispiel dafür ist die CA, die von der Emirates Telecommunications Corporation (Etisalat) betrieben wird und zu 60% im Besitz der Regierung der Vereinigten Arabischen Emirate (VAE) ist. Etisalat hat einmal einen harmlos aussehenden BlackBerry-Patch eingeführt, mit dem Spyware in RIM-Geräte eingefügt wurde, um die Überwachung von E-Mails zu ermöglichen.

Wenn der Client das alte SSL 2.0-Protokoll weiterhin unterstützt, kann ein MITM das SSL herunterstufen Verbindung und verwenden Sie entweder einen schwächeren symmetrischen Verschlüsselungsalgorithmus oder einen schwächeren Schlüsselaustausch.

Zusammenfassend lässt sich sagen, dass der Angreifer, wenn er den DNS-Server kontrolliert, sehr böswillige Aktionen ausführen kann. Zum Abfangen von SSL-verschlüsseltem Datenverkehr benötigt er jedoch mehr als das.

Und um Ihre letzte Frage zu beantworten: Die Die Website der Zertifizierungsstelle muss nicht bei jedem Besuch einer Website aufgelöst werden: Die Website stellt Ihnen normalerweise das öffentliche Zertifikat zur Verfügung, das sie selbst verwendet. Möglicherweise erhalten Sie es jedoch stattdessen von der Zertifizierungsstelle. Dies ändert jedoch nichts an den oben genannten Dingen.

Gute Zusammenfassung. Ein weiteres Szenario besteht darin, dass der Angreifer den tatsächlich verwendeten privaten Schlüssel auf der Site stiehlt, auf der er sich ausgeben möchte.
+1, sehr gute Antwort. Ein weiteres Szenario ist die Bereitstellung der gefälschten HTTPS-Site über eine herabgestufte SSL-Verbindung. Z.B. Beantwortung der Client-Anfrage nur mit SSL v.2 - Wenn der Client dies unterstützt, gibt es zahlreiche zusätzliche Fallstricke.
[Verwandte Frage zur Sicherheit und zum Vertrauen von CA-Roots] (http://security.stackexchange.com/questions/2268/how-feasible-is-it-for-a-ca-to-grant-exceptions-to-the -Überprüfungsprozess-whi)
Hat stuxnet keine Codesignaturzertifikate verwendet, die von den Organisationen selbst gestohlen wurden, und keinen Hack auf die CA oder RA? Tolle Antwort, abgesehen von diesem kleinen Punkt.
Ja, sie wurden nicht gehackt, wer weiß, wie sie sie bekommen haben.
@john, Warte, ** was ist mit TLS **?Wenn der ISP alle Ihre IP-Pakete überwachen und ändern könnte, würde das nicht bedeuten, dass der ISP TLS hacken kann?
#2
+6
binfalse
2011-05-16 14:28:29 UTC
view on stackexchange narkive permalink

Es sollte nicht möglich sein. Wenn der Angreifer in der Lage ist, Ihr DNS zu steuern, leitet er Sie möglicherweise zu einem gefährdeten Server weiter. Ihr Browser warnt Sie jedoch (wenn er richtig konfiguriert ist) vor einem fehlerhaften Zertifikat.

Aber tatsächlich ist es möglich ! Falls der Server kein gültiges Zertifikat hat, warnt Ihr Browser, wenn Sie eine Verbindung zum realen Server herstellen und , wenn Sie eine Verbindung zum Computer des Angreifers herstellen. Sie können nicht entscheiden, ob diese Warnung kritisch ist.
In einem anderen Szenario konnte der Angreifer das gültige Zertifikat des Servers abrufen (siehe zum Beispiel hier). So kann er Sie auf einen kompromittierten Server umleiten und Ihr Browser sagt nichts.

Bei dem Comodo-Angriff, auf den Sie verweisen, hat der Angreifer nicht "das gültige Zertifikat des Servers abgerufen" - das sind öffentliche Informationen. Sie haben auch nicht den privaten Schlüssel des gültigen Zertifikats abgerufen. Sie haben stattdessen ein zweites gültiges Zertifikat erstellt, indem sie ihren eigenen privaten Schlüssel und die Zertifizierungsstelle ihrer Wahl verwendet haben.
#3
+6
AviD
2011-05-17 00:25:23 UTC
view on stackexchange narkive permalink

Zusätzlich zu der hervorragenden Antwort von @ John kann ein nicht autorisierter DNS-Server neben der Beeinträchtigung der aktuellen HTTPS-Verbindung auch andere Schäden verursachen (obwohl dies streng außerhalb des Rahmens Ihrer Frage liegt, halte ich es für immer noch relevant). Es gibt verschiedene Arten von Schaden, die es anrichten kann, außer zu versuchen, Ihre aktuelle Verbindung zu belauschen.

Wenn Sie einen böswilligen DNS-Server auffordern, Adressen für Sie aufzulösen, können Sie Antworten erhalten, nach denen Sie nicht gefragt haben. Dies wirkt sich auch auf andere Verbindungen aus, die Sie erstellen - , selbst wenn Sie den Rogue nicht mehr verwenden DNS .
ZB unter Verwendung von DNS-Vergiftungstechniken. (Siehe auch meine Antwort auf diese Frage.)

Außerdem kann das böswillige DNS Sie absichtlich auf einen anderen Server umleiten, z. Ein Opferserver, der jetzt von gefälschten Anfragen überflutet wird.

Wer garantiert Ihnen außerdem, dass Sie tatsächlich die SSL-Verbindung herstellen? Die meisten Benutzer geben nicht "aich tee tee pee ESS (!) Doppelpunkt whack whack ..." ein. Sie geben nur den Domainnamen (z. B. "mybank") und ein Drücken Sie Strg + Eingabetaste oder lassen Sie die Suchmaschine es öffnen oder ... und in all diesen Fällen ist es wahrscheinlich, dass die erste Anfrage des Benutzers überhaupt nicht HTTPS ist. (Wenn Sie es speziell eingeben, ist das natürlich anders, also YMMV in diesem Punkt).

Ich schlage außerdem vor, einige der Antworten unter "Was ist mit der Übernahme des Domainnamens eines anderen verbunden?"

Das automatische Ausfüllen führt zu noch schlimmeren Gewohnheiten. Ich habe in Firefox eine merkwürdige Eigenart festgestellt, dass unterschiedliche Passwörter für die Versionen "http: //" und "https: //" derselben Site gespeichert werden (wahrscheinlich unterschiedliche IPs). Mit Amazon können Sie beispielsweise im Nicht-HTTPS-Modus surfen. Wenn Sie jedoch etwas kaufen, müssen Sie sich über HTTPS erneut authentifizieren. Ich hatte irgendwann ein völlig anderes Amazon-Konto eingerichtet, das ich zum Surfen verwendete, da deren Benutzernamen nicht eindeutig sein müssen. Ich fand dies eines Tages durch einen Unfall, als ich meine zweite Wunschliste (und meinen Browserverlauf) entdeckte.
Erwähnenswert sind auch die Angriffe von [EvilGrade] (http://www.elithecomputerguy.com/2013/03/11/exploiting-automatic-updates-with-evilgrade/)
Benutzer, die ihre Abfrage an Suchmaschinen eingeben, sind wahrscheinlich ein bisschen sicherer, da Suchmaschinen dazu neigen, Sie direkt mit der https-Site zu verknüpfen, anstatt die anfängliche http-> https-Umleitung zu durchlaufen, wenn Sie den Domainnamen direkt ohne eingegeben haben Angabe des Protokolls.
#4
+3
goodguys_activate
2011-05-17 23:02:08 UTC
view on stackexchange narkive permalink

Einige Unternehmens-Proxys (die über eine DNS-Umleitung oder eine Vielzahl anderer Mittel arbeiten) überprüfen möglicherweise den Inhalt einer SSL-Verbindung. Darüber hinaus erhalten die Benutzer eines verwalteten Desktops keine Browserwarnung, wenn das MITM-Zertifikat im lokalen Speicher installiert wurde.

Dies hängt davon ab, wer den Proxy verwaltet und wie seine Protokolle verwendet werden aus Ihrer Sicht akzeptabel oder eine schlechte Sache sein.

Weitere Informationen zum Abfangen von SSL finden Sie unter diesem Link:

Wenn die Der SSL-Proxy fängt eine SSL-Verbindung ab und präsentiert dem Client-Browser ein emuliertes Serverzertifikat. Der Client-Browser gibt ein Sicherheits-Popup an den Endbenutzer aus, da der Browser dem vom ProxySG verwendeten Aussteller nicht vertraut. Dieses Popup wird nicht angezeigt, wenn das vom SSL-Proxy verwendete Ausstellerzertifikat als vertrauenswürdiges Stammverzeichnis in den Zertifikatspeicher des Clientbrowsers importiert wird.

Der ProxySG stellt alle konfigurierten Zertifikate über seine Verwaltungskonsole zum Download zur Verfügung. Sie können Endbenutzer bitten, das Ausstellerzertifikat über Internet Explorer oder Firefox herunterzuladen und als vertrauenswürdige Zertifizierungsstelle in einem Browser ihrer Wahl zu installieren. Dadurch wird das Zertifikat-Popup für emulierte Zertifikate entfernt ...

Weitere Informationen ...

#5
+2
Steve Dispensa
2011-09-04 23:08:56 UTC
view on stackexchange narkive permalink

Ein weiterer Punkt: Ein Angreifer, dem Ihr DNS-Resolver gehört, kann OCSP- oder CRL-Anforderungen an ein Schwarzes Loch fehlleiten, und praktisch alle Browser behandeln dies als Beweis dafür, dass das Zertifikat nicht widerrufen wurde. Wenn also ein Bösewicht zufällig ein gültiges Zertifikat stiehlt, der Gute es jedoch widerruft, kann der Bösewicht verhindern, dass Clients diesen Widerruf sehen, indem er die OCSP / CRL-Anforderung schwarz durchlöchert.

#6
+2
munchkin
2014-12-26 07:07:28 UTC
view on stackexchange narkive permalink

Weil es schwierig ist, Phishing-Sites zu unterscheiden. Hier ist das SSL-Observatorium der EFF.

https://www.eff.org/observatory

Die allgemeine Idee ist solide, Identitätswechsel sind auf unsachgemäße Ausgabe zurückzuführen von Zertifikaten. Wenn Sie sicher sein könnten, dass alle anderen da draußen, wenn sie mit einem Zertifikat konfrontiert werden, genau dasselbe Zertifikat haben, dann wäre die Wahrscheinlichkeit, dass es sich um eine Phishing-Site handelt, nahe Null. Der erstaunliche Teil der Forschung ist die Anzahl der Blattknoten und Zertifizierungsstellen, denen der Browser vertraut.

#7
+1
zedman9991
2011-05-16 18:10:46 UTC
view on stackexchange narkive permalink

Es gibt einen gemischten Angriff, der die meisten Leute täuschen würde http://www.h-online.com/security/news/item/Black-Hat-new-ways-to-attack-SSL-740173. html

Der Angreifer fungiert als Mann in der Mitte und richtet einen unverschlüsselten Link zum Opfer ein, der http: // ... im Browser anzeigt, aber das Vorhängeschloss ist gesetzt und grün Leute vermissen den Mangel an https: // ...

Das Vorhängeschlosssymbol wird bei diesem Angriff nicht gesetzt. Für die Seite, die wie ein Vorhängeschloss aussieht, wird ein neues Favicon bereitgestellt, damit Benutzer es verwechseln können. Eine andere Möglichkeit besteht darin, eine homomorphe URL zu verwenden, die sowohl https als auch ein echtes Zertifikat enthält - jedoch nicht die echte URL.
#8
  0
Nam Nguyen
2011-05-16 15:35:46 UTC
view on stackexchange narkive permalink

In Ihrem Fall lautet die Frage NEIN. Die HTTPS-Verbindung kann NICHT beeinträchtigt werden.

Lassen Sie uns nun herausfinden, warum.

  1. Ihr Browser ist öffentlich Schlüssel der CA. Vertrauenswürdige öffentliche Schlüssel.

  2. Angenommen, der Angreifer kann nicht nur das DNS steuern, sondern auch die Server selbst, in diesem Fall sowohl die Zertifizierungsstelle als auch die Ziel-HTTP-Server.

  3. Der Angreifer kann die Zertifizierungsstelle NICHT fälschen, da er keine passenden privaten Schlüssel als Browser hat.

  4. Der Angreifer kann die nicht fälschen HTTP-Server auch, da sein Zertifikat nicht mit einem Stempel einer vertrauenswürdigen Zertifizierungsstelle versehen ist.

  5. ol>

    Im Extremfall kann der Angreifer ein Zertifikat für die Domäne erhalten, die er nicht hat. ' t control / own, dann ist der vorherige Punkt ungültig. Und der Angreifer kann alles tun, was seine Fantasie heraufbeschwören kann. Die Sache ist, dies verstößt gegen unsere Annahme, dass die CA vertrauenswürdig ist! Es ist die Schuld der Zertifizierungsstelle, die dem Angreifer ein solches Zertifikat erteilt. Und wenn CA nicht mehr vertrauenswürdig ist, ist SSL nur noch ein Papiertiger.

Leider haben Kompromisse verschiedener Zertifizierungsstellen im Laufe der Zeit gezeigt, dass Ihr Endpunkt (SSL ist nur ein Papiertiger) manchmal wahr ist, was Ihren Anfangspunkt ungültig macht.
"Vertrauenswürdige öffentliche Schlüssel" - Gehen Sie in die CA-Liste Ihres Browsers und sehen Sie, wie viele CAs vorhanden sind. Vertrauen Sie all diesen Zertifizierungsstellen? Nun ja, aber Sie sind sich dessen wahrscheinlich nicht bewusst. (Beachten Sie, dass einige der CA-Unternehmen auch ISP-Dienste ausführen. Daher wäre es theoretisch einfach, den gesamten HTTPS-Verkehr mit eigenen (gefälschten) Zertifikaten für ihre Kunden zu entschlüsseln und neu zu signieren, da einige ISPs bereits ähnliche Aktionen mit DNS NX und durchgeführt haben einfaches HTTP, dies ist technisch machbar); Ganz zu schweigen von verschiedenen Banken, die HTTPS mit "Installieren Sie einfach das FooBar Bank CA-Zertifikat in Ihrem Browser" implementieren (yuck).
Wir sprechen hier über das Arbeitsprinzip. Du musst jemandem vertrauen, damit die Sicherheit funktioniert, oder? In PKI ist das die Zertifizierungsstelle. Mit dieser Annahme muss man leben. Deshalb bricht alles zusammen, wenn diese Annahme fehlschlägt.
#9
  0
Tyler
2019-02-06 00:51:11 UTC
view on stackexchange narkive permalink

Es ist höchst unwahrscheinlich, es sei denn, Sie klicken, um ein verdächtiges Zertifikat zuzulassen. Abgesehen davon, dass ein schlecht konfigurierter oder alter Browser mit schwacher SSL gehackt wird, ist dies eine ziemlich große Aufgabe. Sie könnten über eine umfangreiche Datenbank mit IP-Adressen für gemischte Inhalte verfügen, die auf gängigen Hauptwebsites verwendet werden und sich in unsichere Adressen auflösen, die Java, Schriftarten oder andere potenziell gefährliche Dateien verwenden, und alles dort mit schädlichen Inhalten versehen. Daher ist das Deaktivieren gemischter Inhalte heutzutage eine großartige Idee.



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