Drei der derzeit eingereichten Antworten erfordern eine Verringerung der Sicherheitsstufe Ihres Browsers , sodass Sie möglicherweise verschiedenen Angriffen ausgesetzt sind, wenn Sie dies in Ihrem primären Browser tun, und anschließend verwenden diesen Browser für andere Websites oder vergessen Sie einfach, diese Änderung (oder mehrere Änderungen) rückgängig zu machen.
Legacy- und unsichere SSL / TLS-Funktionen (SSLv2- und SSLv3, SHA1RSA-Signaturen, RC4 und 3DES-Chiffren, MD5 MAC, Export-Chiffren, Nicht-PFS-Chiffren, <1024 DH-Parameter) werden progressiv standardmäßig deaktiviert und / oder aus entfernt Browser, und das aus gutem Grund.
Ein separates Problem, das @AndreKR hilfreich kennzeichnet, ist die Browserkompatibilität . In diesem Fall ist ein älterer Browser in einer dedizierten VM wahrscheinlich das robusteste Lösung.
Wenn Sie das Gerät nicht ersetzen können, verwenden Sie eine dedizierte VM oder einen dedizierten Browser. Die nächstbeste Option ist ein TLS-Proxy, um die Verwendung eines modernen sicheren Browsers zu ermöglichen. Das Aktivieren von einer (oder zwei oder drei ...) unsicheren Funktionen in einem Browser ist keine sichere und nachhaltige Lösung. Wenn das Unvermeidliche eintritt und eine erforderliche Funktion vollständig entfernt wird? (SSLv3-Unterstützung für Chrome, Opera, Firefox).
Eine sichere Alternative besteht darin, die Verbindungen über etwas zu übertragen, das unterstützt sowohl alte / ältere als auch neue Protokolle &-Chiffren, es gibt viele Optionen (einschließlich der ziemlich schwergewichtigen Lösung eines Apache-Reverse-Proxys).
Die folgende leichtere Lösung sollte sowohl auf * nix- als auch auf Windows-Systemen funktionieren. Dies erfordert, dass Sie einen Schlüssel / ein Zertifikat generieren - nicht unbedingt ein Problem, da das nächste, was passieren wird, ist, dass moderne Browser SHA1-signierte Zertifikate ablehnen. Auf diese Weise können Sie ein SHA-2-signiertes RSA-2048-Zertifikat und zeitgemäßes TLS für den Zugriff auf das Gerät verwenden.
Für dieses Beispiel:
- Gerät befindet sich auf 192.168.1.123 mit HTTPS am Standardport
- funktioniert wie unter * nix gezeigt, beide Optionen werden unter Windows unterstützt und sollten nur minimale Änderungen erfordern.
- Sie haben einen Schlüssel / ein Zertifikat zur Verwendung generiert und verwenden bei Bedarf einen der folgenden:
socat proxy
Verwenden von socat :
CERT = "cert = mydevice.crt, key = mydevice.key "SSLSRV =" cipher = AES256-SHA, method = TLS1.2, verify = 0 "SSLCLI =" cipher = AES128-SHA, method = SSL3, verify = 0 "socat \ OPENSSL- HÖREN: 11443, bind = 127.0.0.1, reuseaddr, fork, $ CERT, $ SSLSRV \ OPENSSL: 192.168.1.123: 443, $ SSLCLI
und stellen Sie eine Verbindung zu https: / her /127.0.0.1:11443/
Hinweise
Ändern Sie Ihre lokale Hosts -Datei, um bei Bedarf Warnungen vor nicht übereinstimmenden Zertifikatsnamen in Ihrem Browser zu vermeiden. Da Sie dafür ohnehin ein internes Zertifikat benötigen, können Sie ein Zertifikat mit dem erwarteten internen Namen erstellen (im Gegensatz zu vielen Geräten, auf die ich gestoßen bin
Für die TLSv1.2-Unterstützung benötigen Sie OpenSSL-1.0.1 oder höher und socat-1.7.3.0 oder höher, um ungerade oder unfreundliche Namen für Zertifikate zu verwenden. Die Optionen cipher und method können je nach Anforderung angepasst werden, ebenso wie die Überprüfung des Server- oder Clientzertifikats.
Diese Lösung erstreckt sich auch auf ähnliche Probleme. B. nur SSLv2-Geräte oder mit 512-Bit-Zertifikaten oder einem humpelnden Satz von Chiffresuiten. Sie müssen jedoch sicherstellen, dass OpenSSL nicht mit no-ssl2 oder no-ssl3 und hat die entsprechende Chiffrensuite aktiviert.
Wenn ich ein Auditor wäre, würde ich lieber eine dokumentierte Zugriffsmethode (zusammen mit einem Upgrade-Plan!) als eine Ad-hoc-Lösung sehen, bei der es sich um einen Unfall handelt, der darauf wartet, passiert zu werden .