Deaktivieren von HSTS für verwaltete Browser

Welche Optionen habe ich, um HSTS sowohl für neue Websites als auch für im Browser eingebrannte Websites zu deaktivieren?

Die Verwendung der HTTPS-Inspektion ändert von Natur aus den Fingerabdruck einer Site, indem sie als Mann in der Mitte fungiert. Der Besuch einer zuvor besuchten Site ohne HTTPS-Inspektion oder einer der vorinstallierten Sites führt zu einer unzugänglichen Site. Welche Optionen - falls vorhanden - habe ich außer der Deaktivierung der Inspektion?

Hier ist ein Beispiel für Google Mail in Chrome mit HTTPS-Überprüfung:

Main Einzelheiten

Hintergrund

Ich richte eine neue Firewall ein und versuche, meine HTTPS-Inspektionsregeln zu bereinigen. Ich möchte wirklich vermeiden, Websites zur Liste hinzuzufügen, die möglicherweise vom Benutzer bereitgestellte Inhalte enthalten, z. B. mail.google.com / gmail.com.

Seit ich das letzte Mal HSTS / HTTP Strict Transport Security gemacht habe, ist es viel häufiger geworden.

Hinweis - Ich habe versucht, dieses Generikum beizubehalten, da dies ein Problem für viele verschiedene Setups sein kann. Ich hoffe auf eine betriebssystem- / browserübergreifende Methode, die auf jedes Firewall-Produkt anwendbar ist, aber ein bisschen viel verlangt. Ein Fokus auf (IE, Chrome, Firefox) unter Windows (7+) wäre ein guter Anfang. Methoden, die sich auf Gruppenrichtlinien konzentrieren, wären ebenfalls sehr nützlich.

security firewall deep-packet-inspection

— Tim Brigham
quelle

Es fällt mir wirklich schwer, das zu verstehen. Soll das eigentlich ein Problem lösen? Wenn ja, was?

— Michael Hampton

@ MichaelHampton fair genug. Ich denke, ich habe es ein bisschen zu allgemein gemacht. Ich muss Websites verfügbar machen, ohne die HTTPS-Überprüfung zu deaktivieren.

— Tim Brigham

@ MichaelHampton, Zum Testen von SSL-Sachen im Grunde. security.stackexchange.com/q/102279/2379 . Oder um einem Proxy die Aufzeichnung zu ermöglichen (z. B. JMeter). Es spielt keine Rolle, ob die Einstellung wahnsinnig dunkel ist (so dass der durchschnittliche Benutzer niemals blind durchklicken kann), aber es muss einen Weg geben, dies zu tun.

— Pacerier

Sie bringen hier ein paar verschiedene Dinge zusammen, und ich vermute, dass dies Sie zu falschen Schlussfolgerungen führt.

Bei HSTS ("HTTP Strict Transport Security") geht es (nur!) Darum, dass HTTPS für Verbindungen zu bestimmten Standorten verwendet wird. Es wird nichts darüber erzwungen, welche Schlüssel, Zertifikate usw. zur Authentifizierung der Verbindung verwendet werden.
Das Anheften von öffentlichen Schlüsseln gibt an, dass, wenn eine HTTPS-Verbindung zu einem bestimmten Namen hergestellt wird, die Zertifikatkette eine einer bestimmten Whitelist öffentlicher Schlüssel enthalten muss, andernfalls wird die Verbindung als ungültig betrachtet.

Da die HTTPS-Prüfung (leider) weit verbreitet ist, besteht die allgemeine Praxis unter Browsern darin, dass Zertifikatketten, die mit einem lokal installierten Stammzertifizierungsstellenzertifikat enden, von der Überprüfung des Fixierens öffentlicher Schlüssel ausgenommen sind. Ich habe eine Aussage von Adam Langley von Chrome zum Verhalten von Chrome gefunden (Abschnitt "Was ist mit MITM-Proxys, Fiddler usw.?"), Aber meine Erfahrung ist für andere Browser ähnlich.

Ich bin ziemlich sicher, dass das in Ihrem Screenshot angegebene Problem nicht darin besteht, dass der Browser an einer Stecknadel hängen bleibt, sondern dass das Zertifikat überhaupt nicht als Verkettung mit einem vertrauenswürdigen CA-Zertifikat erkannt wird. Dies löst einen HSTS-Fehler aus, da "Verwenden von HTTPS" korrekter als "Verwenden von ordnungsgemäß gesichertem HTTPS einschließlich sicherer Chiffren und eines vertrauenswürdigen Zertifikats zur Authentifizierung" angegeben wird. Ich würde empfehlen, noch einmal zu überprüfen, ob das Stammzertifizierungsstellenzertifikat des MitM-Proxys korrekt installiert ist und von den verwendeten Browsern als gültig erkannt wird.

— womble
quelle