Gibt es eine Möglichkeit, SSL-bezogene Warnungen auf Betriebssystemebene unter Windows oder auf Browserebene für alle gängigen Browser vollständig zu unterdrücken?

Gibt es eine Möglichkeit, SSL-bezogene Warnungen auf Betriebssystemebene unter Windows oder auf Browserebene für alle gängigen Browser vollständig zu unterdrücken?

Ich verstehe, warum SSL-Warnungen erforderlich sind und warum Benutzer, selbst erfahrene, daran gehindert werden sollten, diese einfach zu ignorieren. Ich verstehe auch, dass der Ansatz „Whitelist“ oder vertrauenswürdige, nicht vertrauenswürdige Stammzertifizierungsstellen im Allgemeinen der beste Ansatz ist, wenn Sie an Ihrem alltäglichen Arbeitsplatz arbeiten, an dem Sie auch Bankgeschäfte erledigen, Handel treiben oder E-Mails versenden.

Wenn ich jedoch eine frisch eingerichtete Testbox verwende Internet Explorer 8, die keinen Internetzugang hat, hat es keinen Sinn, ständig ein oder zwei Schaltflächen anklicken zu müssen, um einen Server https://my-vm-213.goofy.localoder was auch immer zu verwalten. Und wenn wir es mit Hosts zu tun haben, die in großer Zahl auf und ab gehen und seitwärts laufen, macht es für mich keinen Sinn, einen Moment damit zu verbringen, Stammzertifizierungsstellen hinzuzufügen, die dumm hinzuzufügen sind und innerhalb weniger Stunden keinen Grund mehr haben, zu existieren.

Meine Frage ist folgende: Gibt es eine Möglichkeit, SSL-Prüfungen „immer zu bestehen“:

  1. Auf der Ebene des Windows-Betriebssystems? (dasselbe Subsystem, das von der Certificates mmcGUI certutilusw. verwaltet wird)
  2. Auf Browserebene? - für alle gängigen Browser, insbesondereInternet Explorer
  3. Auf der niedrigstmöglichen Ebene auf Unix-ähnlichen Systemen? (Ich nehme an, dass dies der Fall ist, OpenSSLaber ich weiß es nicht genau)

Für mich wäre das so etwas wie:

( X ) Always validate SSL certificates (DANGEROUS!)

Weitere Rationalisierung unten

Wenn Sie wissen, dass Sie in einer Laborumgebung oder einer neu eingerichteten Umgebung oder einer Umgebung für kleine Unternehmen arbeiten und sich ausschließlich mit systembezogenen Angelegenheiten befassen, gibt es keinen Vorteil in Bezug auf Vertraulichkeit oder Integrität (oder das Bewusstsein des Mangels daran), wenn SiestetsSSL-Warnungen unterdrücken, weil Sie bereits wissen, dass sie erscheinen werden. Ich nehme an, Sie könnten argumentieren: „Was ist, wenn jemand weiß, dass Sie in dieser Hinsicht so nachlässig sind und dies ausnutzt, indem er gezielt die Arten von Hosts angreift, die Sie unterdrücken möchten?“, aber dieses Argument gilt nur, wenn a) es offensichtliche Möglichkeiten gibt, Ihre Tests der IE8-Browserkompatibilität für eine Intranet-Anwendung auszunutzen, b) Sie Ihr virtuelles Maschinennetzwerk falsch konfiguriert und es tatsächlich zugelassen haben, Pakete über sein Gateway zu senden oder zu empfangen, und aus anderen Gründen, aber vor allemc) Sie haben jemals etwas getanandersals Ergebnis dieser Warnung während der Arbeit an einem Host, von dem Sie wissen, dass er diese Warnung erzeugt.

Antwort1

Wenn Sie Sicherheit benötigen, verwenden Sie SSL, und zwar richtig. Wenn Sie keine Sicherheit benötigen, verwenden Sie kein SSL.

Der unsachgemäße Einsatz von SSL schadet der Sicherheit, Benutzerfreundlichkeit und Verfügbarkeit stärker als der völlige Verzicht darauf.

Die aktuellen Browser haben endlich die Sicherheit verbessert und das ist eine normale Entwicklung.

Antwort2

Einen zentralen Ort gibt es nicht.

Beim Internet Explorer können Sie möglicherweise einige DLLs hacken und vorhandene Funktionen ersetzen. Und Sie müssen dies möglicherweise für jede von Ihnen verwendete Windows-Version tun und sie nach Betriebssystemaktualisierungen auf dem neuesten Stand halten. Chrome und Firefox haben ihre eigenen SSL-Stacks (NSS), die Sie ändern müssten. Die Situation ist bei Mac OS X ähnlich, wo Safari einen TLS-Stack verwendet und Chrome und Firefox ihre eigenen TLS-Stacks (auch hier NSS) verwenden. Und auf UNIX-Systemen müssen Sie sich hauptsächlich mit Firefox und Chrome auseinandersetzen, die derzeit ebenfalls den NSS-Stack verwenden.

Der Aufwand, all diese Stellen zu hacken, ist wahrscheinlich größer als der Aufwand, der zum Hinzufügen der benutzerdefinierten CA erforderlich ist, die Sie für Ihre Testsites verwenden.

Antwort3

Möglicherweise ist es besser, einen transparenten Proxy hinzuzufügen, der SSL entfernt oder passende Zertifikate im Handumdrehen als MITM-Angriff erstellt. Auf diese Weise wird nur eine private Zertifizierungsstelle benötigt. Dies sollte bei Verwendung eines beliebigen Bereitstellungssystems problemlos möglich sein.

verwandte Informationen