Forcer Chrome à ignorer une "clé publique éphémère Diffie-Hellman faible"

Avec la mise à jour de Chrome vers la v45, il bloque l'accès aux pages avec des clés publiques Diffher-Hellman éphermériques faibles. Je comprends que cela est dû à Logjam. Je comprends que le passage de https à http est une "solution" dans certains cas.

Cependant, je ne peux pas passer de https à http car je suis automatiquement redirigé vers https par le logiciel Web que nous utilisons sur notre intranet.

Évidemment, la solution serait de faire en sorte que la sécurité change les différents serveurs intranet pour être protégés contre les blocages, je comprends cela, mais ce n'est pas une option pour le moment, et je ne peux plus faire de travail jusqu'à ce qu'il soit corrigé. Parce que c'est un intranet et que la simple connexion nécessite que l'on soit physiquement ici, le risque est minuscule.

Existe-t-il un moyen de continuer à accéder aux pages via le protocole https, avec des clés publiques éphémères Diffie-Hellman faibles dans Chrome version 45?

Solution Hacky pour contourner ce problème (Mac OSX)

• Exécutez cela en ligne de commande pour contourner le problème lors du lancement de Chrome

Chrome:

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

Canari:

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

Pour Firefox

• Allez à propos de: config
• Rechercher security.ssl3.dhe_rsa_aes_128_shaetsecurity.ssl3.dhe_rsa_aes_256_sha
• Réglez-les tous les deux sur false.

REMARQUE: le correctif permanent serait de mettre à jour la clé DH avec une longueur> 1024

En effet, il semble que les navigateurs aient pris au sérieux le problème Diffie-Hellman avec des clés inférieures à 1024, ce qui est en partie une excellente nouvelle, mais d'un autre côté, il a suscité beaucoup d' utilisateurs Chrome en colère .

Le correctif de ce problème (et de nombreux autres liés à la sécurité) est la responsabilité des administrateurs système, donc si je comprends bien, la décision de bloquer tout site Web qui offre une clé Diffie-Hellman faible 512 bits ou inférieure est une mesure de la pression dirigée vers le ceux qui gèrent la sécurité sur des sites distants, avec "l'inconvénient" des utilisateurs qui en souffrent.

Il est actuellement possible de mettre sur liste noire certaines suites de chiffrement lors du lancement du navigateur Google Chrome en l'exécutant avec le --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013paramètre, qui semble désactiver celles liées à la vulnérabilité LogJam et permet aux utilisateurs de rejoindre les sites, mais j'insiste pour que ce soit la responsabilité des administrateurs système. pour résoudre le problème avec leurs clés Diffie-Hellmann.

Vous avez notamment demandé s'il y avait un inconvénient à utiliser les solutions de contournement répertoriées (ou à utiliser d'autres non répertoriées) dans une configuration intranet. La réponse courte est que tant que les serveurs impliqués utilisent des clés faibles, les serveurs impliqués seront sensibles à tout système utilisant une attaque logjam, et selon la nature du serveur, le serveur peut par la suite être un serveur compromis qui peut propager le problème à d'autres clients accédant au serveur.

Deux scénarios non improbables sont un ordinateur portable qui a été infecté hors de l'intranet accédant au serveur interne lorsqu'ils se reconnectent à l'intranet, ou un navigateur configuré pour ignorer le problème (comme suggéré ci-dessus et ailleurs) qui est actuellement utilisé pour accéder à Internet et qui arrive à se connecter à un serveur compromis étant un point de départ pour attaquer vos serveurs intranet.

Comme je ne connais pas personnellement tous les problèmes que présente la faille de blocage, je ne peux pas dire si l'une ou l'autre de ces deux situations est particulièrement probable. Ma propre expérience est que les administrateurs système avec des serveurs Internet ont tendance à devancer autant que possible ces problèmes. Cela dit, mon expérience est également que les administrateurs de serveur intranet ont tendance à faire des choses comme jolis sites avant de résoudre les problèmes de sécurité du serveur.

Face au même problème. Si vous êtes du côté serveur, ajoutez simplement les lignes suivantes dans le connecteur 443 dans server.xml tomcat

sslProtocols = "TLSv1, TLSv1.1, TLSv1.2" chiffrements = "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"

Cela vous aidera à résoudre ce problème de clé SSL.