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

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

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.

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.

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.

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.

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.