SSL und Man-in-the-Middle-Missverständnisse

90

Ich habe unzählige Dokumentationen zu diesem Problem gelesen, kann aber immer noch nicht alle Teile zusammenfügen, daher möchte ich ein paar Fragen stellen.

  1. Zunächst beschreibe ich kurz das Authentifizierungsverfahren, wie ich es verstehe, da ich mich in dieser Hinsicht möglicherweise irre: Ein Client stellt eine Verbindung her, auf die ein Server mit einer Kombination aus öffentlichem Schlüssel, einigen Metadaten und digitaler Signatur von a antwortet vertrauenswürdige Autorität. Dann trifft der Client die Entscheidung, ob er dem Server vertraut, verschlüsselt einen zufälligen Sitzungsschlüssel mit dem öffentlichen Schlüssel und sendet ihn zurück. Dieser Sitzungsschlüssel kann nur mit einem auf dem Server gespeicherten privaten Schlüssel entschlüsselt werden. Der Server führt dies aus und dann beginnt die HTTPS-Sitzung.

  2. Wenn ich oben richtig bin, ist die Frage, wie der Man-in-the-Middle-Angriff in einem solchen Szenario stattfinden kann. Ich meine, selbst wenn jemand die Antwort des Servers (z. B. www.server.com) mit einem öffentlichen Schlüssel abfängt und einige Mittel hat, um mich glauben zu lassen, dass er www.server.com ist, kann er meinen Sitzungsschlüssel immer noch nicht entschlüsseln ohne den privaten Schlüssel.

  3. Geht es bei der gegenseitigen Authentifizierung nur um das Vertrauen des Servers in die Clientidentität? Ich meine, der Client kann bereits sicher sein, dass er mit dem richtigen Server kommuniziert, aber jetzt möchte der Server herausfinden, wer der Client ist, oder?

  4. Und die letzte Frage betrifft die Alternative zur gegenseitigen Authentifizierung. Wenn ich in der beschriebenen Situation als Client fungiere, was ist, wenn ich nach dem Einrichten der SSL-Sitzung ein Login / Passwort im HTTP-Header sende? Aus meiner Sicht können diese Informationen nicht abgefangen werden, da die Verbindung bereits gesichert ist und der Server sich bei meiner Identifizierung darauf verlassen kann. Liege ich falsch? Was sind die Nachteile eines solchen Ansatzes im Vergleich zur gegenseitigen Authentifizierung (nur Sicherheitsprobleme sind wichtig, nicht die Komplexität der Implementierung)?

Vadim Chekry
quelle

Antworten:

103

Man-in-the-Middle-Angriffe auf SSL sind wirklich nur möglich, wenn eine der Voraussetzungen von SSL nicht erfüllt ist. Hier einige Beispiele.

  • Der Server - Schlüssel gestohlen wurde - Mittel der Angreifer erscheinen kann der Server sein, und es gibt keine Möglichkeit für den Kunden zu kennen.

  • Der Client vertraut einer nicht vertrauenswürdigen Zertifizierungsstelle (oder einer, deren Stammschlüssel gestohlen wurde). Wer einen vertrauenswürdigen Zertifizierungsstellenschlüssel besitzt, kann ein Zertifikat generieren, das vorgibt, der Server zu sein, und der Client wird ihm vertrauen. Angesichts der Anzahl der in Browsern bereits vorhandenen Zertifizierungsstellen kann dies ein echtes Problem sein. Dies bedeutet, dass sich das Serverzertifikat anscheinend in ein anderes gültiges Zertifikat ändert, was die meisten Clients vor Ihnen verbergen werden.

  • Der Client macht sich nicht die Mühe, das Zertifikat anhand seiner Liste vertrauenswürdiger Zertifizierungsstellen korrekt zu validieren. Jeder kann eine Zertifizierungsstelle erstellen. Ohne Validierung scheinen "Bens Autos und Zertifikate" genauso gültig zu sein wie Verisign.

  • Der Client wurde angegriffen und eine gefälschte Zertifizierungsstelle wurde in seine vertrauenswürdigen Stammberechtigungen eingefügt. Dadurch kann der Angreifer jedes gewünschte Zertifikat generieren, und der Client wird ihm vertrauen. Malware tendiert dazu, dies zu tun, um Sie beispielsweise zu gefälschten Bankenseiten weiterzuleiten.

Insbesondere # 2 ist ziemlich unangenehm, selbst wenn Sie für ein hoch vertrauenswürdiges Zertifikat bezahlen, ist Ihre Site in keiner Weise an dieses Zertifikat gebunden. Sie müssen allen Zertifizierungsstellen im Browser des Clients vertrauen, da jede von ihnen ein gefälschtes Zertifikat für generieren kann Ihre Website, die genauso gültig ist. Es ist auch kein Zugriff auf den Server oder den Client erforderlich.

Joachim Isaksson
quelle
4
Es gibt auch Tools wie sslstrip , die versuchen, https-Links transparent in http-Links umzuschreiben.
mpontillo
3
Ein weiterer Punkt bei der Zertifikatsüberprüfung ist, dass der Client den Hostnamen überprüfen muss. Es ist nicht gut genug, um zu überprüfen, ob das Zertifikat echt ist. Es muss ein Problem für die Entität sein, mit der Sie sprechen möchten (siehe hier und hier ). Bei sslstrip muss der Benutzer letztendlich überprüfen, ob er SSL / TLS verwenden möchte (obwohl HSTS helfen kann).
Bruno
Könnte ich ein Chrome-Plugin (oder einen anderen Browser) schreiben, das die Daten abfängt, bevor der Browser sie verschlüsselt?
Rosdi Kasim
Ein weiterer Grund ist "Vertrauensmissbrauch", wie in der TürkTrust-Ausgabe.
Zeremonie
1
@ Remover Nicht wirklich ... # 1 ist der private Schlüssel auf dem Server, gepaart mit dem echten öffentlichen Schlüssel. In diesem Szenario würden Sie mit dem realen Server sprechen, aber jemand anderes könnte den Datenverkehr entschlüsseln, indem er sich in der Mitte befindet. Sie können das Zertifikat nicht ändern. # 2 beinhaltet das Senden eines völlig anderen Zertifikats, das von einer "vertrauenswürdigen" Zertifizierungsstelle ausgestellt wurde und für den Client als legitim erscheint. Der Angreifer kann dann in Ihrem Namen Proxy-Anfragen stellen und Nachrichten auf diese Weise anzeigen. Beides führt zu einem Kompromiss, aber # 1 liegt unter Ihrer Kontrolle. # 2 ist leider nicht.
Basic
17

Zunächst beschreibe ich kurz das Authentifizierungsverfahren, so wie ich es verstehe. Vielleicht irre ich mich bei diesem Schritt. Ein Client stellt also eine Verbindung her und ein Server antwortet darauf mit einer Kombination aus öffentlichem Schlüssel, einigen Metadaten und digitaler Signatur einer vertrauenswürdigen Behörde.

Der Server antwortet mit einer X.509-Zertifikatkette und einer digitalen Signatur, die mit einem eigenen privaten Schlüssel signiert ist.

Dann trifft der Client die Entscheidung, ob er dem Server vertraut

Richtig.

verschlüsselt einen zufälligen Sitzungsschlüssel mit dem öffentlichen Schlüssel und sendet ihn zurück.

Nein. Der Client und der Server führen einen gemeinsamen Prozess zur Generierung von Sitzungsschlüsseln durch, bei dem der Sitzungsschlüssel selbst niemals übertragen wird.

Dieser Sitzungsschlüssel kann nur mit einem auf dem Server gespeicherten privaten Schlüssel entschlüsselt werden.

Nein.

Der Server macht das

Nein.

und dann beginnt die HTTPS-Sitzung.

Die TLS / SSL- Sitzung beginnt, es sind jedoch zunächst weitere Schritte erforderlich.

Wenn ich oben richtig bin, ist die Frage, wie der Man-in-the-Middle-Angriff in einem solchen Szenario stattfinden kann.

Indem Sie sich als Server tarnen und als SSL-Endpunkt fungieren. Der Client müsste jeden Autorisierungsschritt weglassen. Leider ist der einzige Autorisierungsschritt in den meisten HTTPS-Sitzungen die Überprüfung des Hostnamens.

Ich meine, selbst wenn jemand die Antwort des Servers (z. B. www.server.com) mit einem öffentlichen Schlüssel abfängt und mich dann mit einigen Mitteln glauben lässt, dass er www.server.com ist, kann er meinen Sitzungsschlüssel immer noch nicht entschlüsseln ohne den privaten Schlüssel.

Siehe oben. Es gibt keinen Sitzungsschlüssel zum Entschlüsseln. Die SSL-Verbindung selbst ist sicher. Es ist möglicherweise nicht sicher, mit wem Sie sprechen .

Geht es bei der gegenseitigen Authentifizierung nur um das Vertrauen des Servers in die Clientidentität? Ich meine, der Client kann bereits sicher sein, dass er mit dem richtigen Server kommuniziert, aber jetzt möchte der Server herausfinden, wer der Client ist, oder?

Richtig.

Und die letzte Frage betrifft die Alternative zur gegenseitigen Authentifizierung. Wenn ich in der beschriebenen Situation als Client fungiere, was ist, wenn ich nach dem Einrichten der SSL-Sitzung ein Login / Passwort im HTTP-Header sende? Wie ich sehe, können diese Informationen nicht abgefangen werden, da die Verbindung bereits gesichert ist und der Server sich bei meiner Identifizierung darauf verlassen kann. Liege ich falsch?

Nein.

Was sind die Nachteile eines solchen Ansatzes im Vergleich zur gegenseitigen Authentifizierung (nur Sicherheitsprobleme sind wichtig, nicht die Komplexität der Implementierung)?

Es ist nur so sicher wie der Benutzername / das Passwort, die viel einfacher zu verlieren sind als ein privater Schlüssel.

Marquis von Lorne
quelle
Ich danke Ihnen für Ihre Erklärung. Das einzige, was ich nicht verstanden habe, ist, warum Sie sagten, ein Client sende keinen Sitzungsschlüssel an einen Server? Nun, vielleicht habe ich eine falsche Terminologie verwendet. Hier wird dieses Datenelement als "Pre-Master-Geheimnis" bezeichnet. Wird es nicht vom Client gesendet und mit dem privaten Serverschlüssel entschlüsselt?
Vadim Chekry
1
@VadimChekry Das Pre-Master-Geheimnis ist nicht der Sitzungsschlüssel. Es ist eines von mehreren Daten, die zum Generieren des Sitzungsschlüssels unabhängig an beiden Enden verwendet werden. Der Prozess ist in RFC 2246 beschrieben.
Marquis of Lorne
1
@Chris Sie sind viel weniger anfällig, jedoch ist das Spoofing von IP-Adressen möglich. Es gibt keinen Ersatz dafür, die Peer-Identität im Zertifikat selbst zu überprüfen.
Marquis von Lorne
1
+1 Dies ist größtenteils eine recht gute Antwort. Einige Punkte sind jedoch mit Ein-Wort-Antworten nicht erklärbar. Sie könnten es zu einer endgültigen Antwort machen, wenn Sie diese Punkte im Hauptteil erweitern und / oder näher erläutern würden (dh anstelle von "Nein" könnten Sie kurz erwähnen, was tatsächlich passiert.). Das würde wirklich ein paar Dinge klarstellen. Vielen Dank.
Stimmen
1
@ tjt263 Das erste Nein erklärt, was wirklich passiert. Die nächsten beiden Nein beziehen sich auf dasselbe Missverständnis, das das erste Nein hervorgebracht hat, und haben dieselbe Erklärung. Das nächste und letzte "Nein" bezieht sich auf "Bin ich falsch" und bezieht sich auf die Informationen, die gerade aus dem OP zitiert wurden. Es ist daher schwierig zu verstehen, was Ihrer Meinung nach hier tatsächlich fehlt.
Marquis von Lorne
17

Jeder, der sich zwischen Client und Server befindet, kann einen Mann im mittleren Angriff auf https inszenieren. Wenn Sie der Meinung sind, dass dies unwahrscheinlich oder selten ist, sollten Sie bedenken, dass es kommerzielle Produkte gibt , die den gesamten SSL-Verkehr über ein Internet-Gateway systematisch entschlüsseln, scannen und neu verschlüsseln. Sie senden dem Client ein SSL-Zertifikat, das im laufenden Betrieb erstellt wurde und dessen Details aus dem "echten" SSL-Zertifikat kopiert, aber mit einer anderen Zertifikatkette signiert wurden. Wenn diese Kette mit einer der vertrauenswürdigen Zertifizierungsstellen des Browsers endet, ist dieses MITM für den Benutzer unsichtbar. Diese Produkte werden hauptsächlich an Unternehmen verkauft, um (polizeiliche) Unternehmensnetzwerke zu "sichern", und sollten mit dem Wissen und der Zustimmung der Benutzer verwendet werden. Technisch gesehen steht der Nutzung durch ISPs oder andere Netzbetreiber nichts mehr im Wege. (Es ist sicher anzunehmen, dass der NSA mindestens einen vertrauenswürdigen Signaturschlüssel für die Stammzertifizierungsstelle hat .)

Wenn Sie eine Seite bereitstellen, können Sie einen HTTP-Header einfügen, der angibt, mit welchem ​​öffentlichen Schlüssel die Seite signiert werden soll. Dies kann dazu beitragen, Benutzer auf das MITM über ihre "sichere" Verbindung aufmerksam zu machen, es handelt sich jedoch um eine Trust-on-First-Use-Technik. Wenn Bob noch keinen Datensatz mit dem "echten" öffentlichen Schlüssel hat, schreibt Mallory einfach den pkp-Header im Dokument neu. Die Liste der Websites, die diese Technologie (HPKP) verwenden, ist bedrückend kurz. Es enthält Google und Dropbox, um ihre Gutschrift. Normalerweise blättert ein https-Intercepting-Gateway durch Seiten der wenigen großen vertrauenswürdigen Sites, die HPKP verwenden. Wenn Sie einen HPKP-Fehler sehen, wenn Sie ihn nicht erwarten, seien Sie vorsichtig.

In Bezug auf Kennwörter wird alles in einer https-Verbindung durch https gesichert, mit Ausnahme des Domainnamens, der gelöscht werden muss, damit die Anforderung weitergeleitet werden kann. Im Allgemeinen wird empfohlen, keine Kennwörter in die Abfragezeichenfolge einzufügen, wo sie in Protokollen, Lesezeichen usw. herumhängen können. Die Abfragezeichenfolge ist jedoch nur sichtbar, wenn https gefährdet ist.

bbsimonbb
quelle
Dies bedeutet jedoch, dass dieses MITM-Gerät (das den Datenverkehr entschlüsselt / scannt und neu verschlüsselt) Zugriff auf eine der vertrauenswürdigen Zertifizierungsstellen haben muss, oder? (um das Serverzertifikat zu "fälschen"). Nehmen wir an, das passiert. Dann macht jemand das kaputt, die Informationen werden öffentlich und es wird einen Skandal im Pres geben und das CA-Zertifikat wird von allen Browsern entfernt, oder? Ich meine, im Idealfall ...
Jazzcat
2
Nein, nein. Für die "SSL-Überprüfung" auf dem Gateway müssen Zertifikate im laufenden Betrieb erstellt und signiert werden. Dazu ist jedoch kein Stammzertifikat erforderlich. Es hat ein Zwischenzertifikat, das eine Kette hat. Ob Ihr Browser dem Stamm der Kette vertraut oder nicht, bestimmt, ob ein Zertifikatfehler angezeigt wird. Bei der Arbeit wurden wir gebeten, das Fortinet-Stammzertifikat zu installieren, damit unsere Browser keine Zertifikatfehler melden. Wenn die Kette jedoch mit einem bereits vertrauenswürdigen Zertifikat beendet wurde, ist sie transparent.
Bbsimonbb
Ein Arbeitskollege nutzte ein begrenztes Verständnis dafür, warum diese MITM-Techniken des Unternehmensnetzwerks für Google eine schlechte Idee sind, um SSL zu erzwingen. Könnte er tatsächlich ein bisschen Korrektheit haben?
EmSixTeen
1
Entschuldigung, ich verstehe die Frage nicht!
Bbsimonbb
2
  1. Richtig
  2. Nicht so richtig. Bei dieser Art von Angriff erhält der Zwischenserver Ihre Anfrage und sendet diese für Sie an das Ziel. und antworten Sie dann mit dem Ergebnis. Tatsächlich ist es der Man-in-the-Middle-Server, der eine sichere Verbindung mit Ihnen herstellt, nicht der tatsächliche Server, den Sie kommunizieren möchten. Aus diesem Grund MÜSSEN Sie immer überprüfen, ob das Zertifikat gültig und vertrauenswürdig ist.
  3. könnte richtig sein
  4. Wenn Sie sicher sind, dass die gesicherte Verbindung vertrauenswürdig ist, können Sie sicher Benutzername / Passwort senden.
Boynux
quelle
Ungefähr 2 - Ich gehe davon aus, dass der Client die vom Server während des Verbindungsaufbaus gesendeten Metadaten gründlich überprüft und dass der Client nicht ALLEN Zertifikaten vertraut. Wäre ein solches Szenario also nicht möglich, wenn - a) ein Client nicht das tut, was ich oben gesagt habe, oder b) ein Mann in der Mitte irgendwo ein von einer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat hat?
Vadim Chekry
1
Es kommt sehr selten vor, dass der Zwischenserver ein gültiges Zertifikat sendet. Letztes Jahr ist es mit Comodo CA passiert, wenn ich mich gut erinnere. Wenn es sich jedoch um eine vertrauenswürdige Verbindung handelt, ist sie normalerweise vollständig sicher.
Boynux
1

Alles, was Sie gesagt haben, ist korrekt, mit Ausnahme des Teils über den Sitzungsschlüssel. Der Zweck von CAs besteht darin, einen Man-in-the-Middle-Angriff zu besiegen - alles andere wird von SSL selbst erledigt. Die Clientauthentifizierung ist eine Alternative zu einem Benutzernamen- und Kennwortschema.

David Schwartz
quelle