it-swarm.com.de

Chrome zwingen, einen "schwachen, kurzlebigen öffentlichen Diffie-Hellman-Schlüssel" zu ignorieren

Mit dem Update von Chrome auf v45 wird der Zugriff auf Seiten mit schwachen ephermeralen öffentlichen Diffie-Hellman-Schlüsseln blockiert. Ich verstehe, dass das an Logjam liegt. Ich verstehe, dass der Wechsel von https zu http in einigen Fällen eine "Lösung" ist.

Ich kann jedoch nicht von https zu http wechseln, da ich von der webbasierten Software, die wir in unserem Intranet verwenden, automatisch zu https umgeleitet werde.

Die Lösung wäre natürlich, dass die Sicherheit die verschiedenen Intranetserver so ändert, dass sie vor Logjam geschützt sind. Ich verstehe das, aber das ist momentan keine Option, und ich kann erst dann mehr arbeiten, wenn es behoben ist. Da es sich um ein Intranet handelt und für die einfache Verbindung überhaupt eine physische Verbindung erforderlich ist, ist das Risiko gering.

Kann ich mit schwachen, kurzlebigen öffentlichen Diffie-Hellman-Schlüsseln in Chrome Version 45 weiterhin über das https-Protokoll auf Seiten zugreifen?

17
Raine Dragon

Hacky Fix, um dieses Problem zu umgehen (Mac OSX)

  • Führen Sie dies in der Befehlszeile aus, um das Problem beim Starten von Chrome zu umgehen

Chrome:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Kanarienvogel:

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Für Firefox

  • Gehe zu about: config
  • Suche nach security.ssl3.dhe_rsa_aes_128_sha und security.ssl3.dhe_rsa_aes_256_sha
  • Setzen Sie beide auf false.

HINWEIS: Eine dauerhafte Korrektur besteht darin, den DH-Schlüssel mit einer Länge> 1024 zu aktualisieren

8
user38814

Offensichtlich haben Browser das Diffie-Hellman-Problem mit niedrigeren Schlüsseln als 1024 ernst genommen. Dies sind zum Teil großartige Nachrichten, zum anderen hat es jedoch auch Auswirkungen Viele verärgerte Chrome-Nutzer .

Die Behebung dieses Problems (und vieler anderer Probleme im Zusammenhang mit der Sicherheit) liegt in der Verantwortung von Sysadmins. Nach meinem Verständnis ist die Entscheidung, Websites mit einem schwachen Diffie-Hellman-Schlüssel mit 512 Bit oder niedriger zu sperren, ein Maß für den Druck, der auf das System ausgeübt wird diejenigen, die die Sicherheit an entfernten Standorten verwalten, wobei die "Kehrseite" der Benutzer unter den Auswirkungen leidet.

Es ist derzeit möglich, einige Cipher Suites beim Starten des Google Chrome-Browsers auf eine schwarze Liste zu setzen, indem Sie ihn mit dem Parameter --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013 ausführen. Dieser Parameter scheint die mit der Sicherheitsanfälligkeit in LogJam in Zusammenhang stehenden zu deaktivieren und Benutzern den Beitritt zu den Websites zu ermöglichen. Verantwortung, das Problem mit den Diffie-Hellmann-Schlüsseln zu beheben.

5
nKn

Sie haben unter anderem gefragt, ob die Verwendung der aufgeführten Problemumgehungen (oder der Verwendung anderer, die nicht aufgeführt sind) in einem Intranet-Setup nachteilig ist. Die kurze Antwort lautet: Solange die beteiligten Server schwache Schlüssel verwenden, sind die beteiligten Server für alle Systeme anfällig, die einen Log-Jam-Angriff ausführen. Abhängig von der Art des Servers kann es sich bei dem Server anschließend um einen kompromittierten Server handeln, der den möglicherweise weitergibt Problem für andere Clients, die auf den Server zugreifen.

Zwei nicht unwahrscheinliche Szenarien sind ein Laptop, der über das Intranet infiziert wurde und auf den internen Server zugreift, wenn er erneut eine Verbindung zum Intranet herstellt, oder ein Browser, der so konfiguriert ist, dass er das Problem (wie oben und anderswo vorgeschlagen) ignoriert, das derzeit für den Internetzugang verwendet wird zufällig eine Verbindung zu einem kompromittierten Server herstellen, der ein Ausgangspunkt für Angriffe auf Ihre Intranetserver ist.

Da ich nicht persönlich mit allen Problemen vertraut bin, die der Logjam-Fehler mit sich bringt, kann ich nicht sagen, ob eine dieser beiden Situationen besonders wahrscheinlich ist. Nach meiner eigenen Erfahrung sind Sysadmins mit Servern mit Internet-Zugang solchen Problemen in der Regel so weit wie möglich voraus. Meiner Erfahrung nach neigen Administratoren von Intranetservern jedoch dazu, Websites hübsch zu machen, bevor sie sich mit Fragen der Serversicherheit befassen.

Konfrontiert das gleiche Problem. Wenn Sie ein Server-Typ sind, fügen Sie einfach die folgenden Zeilen in den 443-Connector in server.xml Tomcat ein

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" Chiffren = "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA"

Auf diese Weise können Sie das Problem mit dem SSL-Schlüssel beheben.

0
Kiran