wake-up-neo.net

Forzar a Chrome a ignorar una "clave pública débil efímera Diffie-Hellman"

Con la actualización de Chrome a v45, está bloqueando el acceso a las páginas con claves públicas débiles efímeras Diffie-Hellman. Entiendo que esto se debe a Logjam. Entiendo que cambiar de https a http es una "solución" en algunos casos.

Sin embargo, no puedo cambiar de https a http porque el software basado en web que utilizamos en nuestra intranet me redirige automáticamente a https.

Obviamente, la solución sería cambiar la seguridad de los distintos servidores de intranet para que estén a salvo de logjam, entiendo eso, pero esa no es una opción en este momento, y no puedo hacer más trabajo hasta que se solucione. Debido a que es una intranet y la simple conexión requiere que uno esté físicamente aquí, el riesgo es minúsculo.

¿Hay alguna manera de que pueda continuar accediendo a las páginas a través del protocolo https, con las débiles claves públicas efímeras Diffie-Hellman en Chrome versión 45?

17
Raine Dragon

Corrección de Hacky para solucionar este problema (Mac OSX)

  • Ejecute esto en la línea de comandos para solucionar el problema al iniciar Chrome

Chrome:

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

Canario:

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

Para Firefox

  • Ir a about: config
  • Buscar security.ssl3.dhe_rsa_aes_128_sha y security.ssl3.dhe_rsa_aes_256_sha
  • Póngalos a false.

NOTA: la solución permanente sería actualizar la clave DH con una longitud> 1024

8
user38814

De hecho, parece que los navegadores han tomado en serio el problema Diffie-Hellman con claves inferiores a 1024, lo que en una parte es una gran noticia , pero por otro lado, ha generado muchos usuarios de Chrome enojados .

La solución para este problema (y muchos otros relacionados con la seguridad) es responsabilidad de los administradores de sistemas, por lo que, según tengo entendido, la decisión de bloquear cualquier sitio web que ofrezca una clave Diffie-Hellman débil de 512 bits o inferior es una medida de presión dirigida a los que administran la seguridad en sitios remotos, con el "inconveniente" de los usuarios que sufren los efectos.

Actualmente es posible incluir en la lista negra algunos Cipher Suites al iniciar el navegador Google Chrome ejecutándolo con el parámetro --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013, que parece deshabilitar los relacionados con la vulnerabilidad de LogJam y permite que los usuarios se unan a los sitios, pero insisto en que deben ser administradores de sistemas. Responsabilidad de solucionar el problema con sus llaves de Diffie-Hellmann.

5
nKn

Una de las cosas que preguntó fue si existía alguna desventaja en el uso de las soluciones en la lista (o en el uso de otras que no están en la lista) en una configuración de intranet. La respuesta corta es que mientras los servidores involucrados usen claves débiles, los servidores involucrados serán susceptibles a cualquier sistema que use un ataque de logjam, y dependiendo de la naturaleza del servidor, el servidor puede ser posteriormente un servidor comprometido que puede propagar el servidor. Problema a otros clientes que acceden al servidor.

Dos escenarios no improbables son una computadora portátil que ha sido infectada desde la intranet que accede al servidor interno cuando se conectan de nuevo a la intranet, o un navegador configurado para ignorar el problema (como se sugirió anteriormente y en otros lugares) que se usa actualmente para acceder a Internet y que sucede que conectarse a un servidor comprometido es un punto de partida para atacar sus servidores de intranet.

Como no estoy familiarizado personalmente con todos los problemas que presenta la falla del bloqueo de sistema, no puedo decir si alguna de estas dos situaciones es particularmente probable. Mi propia experiencia es que los administradores de sistemas con servidores orientados a Internet tienden a adelantarse lo más posible a estos problemas. Dicho esto, mi experiencia también es que los administradores de servidores de intranet tienden a hacer cosas como hacer que los sitios sean bastante antes de abordar los problemas de seguridad del servidor.

Ante el mismo problema. Si usted es un tipo del lado del servidor, simplemente agregue las siguientes líneas en el conector 443 en server.xml Tomcat

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

Esto te ayudará a resolver este problema de la clave SSL.

0
Kiran