web-dev-qa-db-fra.com

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

Avec la mise à jour de Chrome vers v45, il bloque l’accès aux pages contenant des clés publiques multimères Diffie-Hellman faibles. Je comprends que cela est dû à Logjam. Je comprends que passer 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 utilisé sur notre intranet.

Évidemment, la solution consisterait à faire en sorte que la sécurité modifie les différents serveurs intranet afin de les protéger de tout blocage, ce que je comprends, mais ce n’est pas une option à la minute actuelle, et je ne peux plus travailler tant que ce n’est pas résolu. Parce que c'est un intranet et que la simple connexion nécessite la présence physique, le risque est minuscule.

Puis-je continuer à accéder aux pages via le protocole https, avec des clés publiques éphémères Diffie-Hellman faibles dans la version 45 de Chrome?

google-chromesecurityhttps
17
Raine Dragon

Hacky corrige ce problème (Mac OSX)

  • Exécuter ceci en ligne de commande pour résoudre 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

Canary: 

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
  • Recherchez security.ssl3.dhe_rsa_aes_128_sha et security.ssl3.dhe_rsa_aes_256_sha
  • Définissez les deux sur false.

REMARQUE: Une solution permanente consisterait à mettre à jour la clé DH avec une longueur> 1024.

8
user38814

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 dans une partie est une grande nouvelle, mais en revanche, il a généré beaucoup d'utilisateurs en colère de Chrome .

La solution à ce problème (ainsi qu’à de nombreux autres problèmes liés à la sécurité) incombe à l’administrateur système. Par conséquent, si je comprends bien, la décision de bloquer tout site Web offrant une clé Diffie-Hellman de 512 bits ou moins est une mesure de pression dirigée vers le ceux qui gèrent la sécurité sur des sites distants, avec le "inconvénient" (=) des utilisateurs .

Il est actuellement possible de répertorier certaines suites de chiffrement lors du lancement du navigateur Google Chrome en l’exécutant avec le paramètre --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013, 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 le cas de sysadmins. la responsabilité de résoudre le problème avec leurs clés Diffie-Hellmann.

5
nKn

Vous avez notamment demandé s'il était désavantageux d'utiliser les solutions de contournement répertoriées (ou d'utiliser d'autres solutions 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 sont susceptibles de subir l’attaque par obstruction d’un système. En fonction de la nature du serveur, le serveur peut par la suite être un serveur compromis susceptible de propager le problème aux autres clients accédant au serveur.

Deux scénarios non improbables sont un ordinateur portable 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) actuellement utilisé pour accéder à Internet et arrive à se connecter à un serveur compromis constituant un tremplin pour attaquer vos serveurs intranet.

Étant donné que je ne connais pas personnellement tous les problèmes soulevés par la faille liée à l’embouteillage, je ne saurais dire si l’une ou l’autre de ces situations est particulièrement probable. D'après mon expérience personnelle, les administrateurs système dotés de serveurs Internet ont tendance à avoir une longueur d'avance sur ces problèmes. Cela dit, j’ai également appris que les administrateurs de serveurs intranet ont tendance à créer des sites plus jolis avant de s’attaquer aux problèmes de sécurité des serveurs.

0
Rusty YouDon'tNeedHisLastName

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

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

0
Kiran