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

Con la actualización de Chrome a v45, está bloqueando el acceso a páginas con claves públicas efímeras débiles de 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 hacer que la seguridad cambie los distintos servidores de la intranet para estar seguros de logjam, lo entiendo, 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 claves públicas efímeras efímeras de Diffie-Hellman en Chrome versión 45?

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

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

Cromo:

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 acerca de: config
• Buscar security.ssl3.dhe_rsa_aes_128_shaysecurity.ssl3.dhe_rsa_aes_256_sha
• Ajústalos a ambos false.

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

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

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 aquellos que administran la seguridad en sitios remotos, con la "desventaja" de los usuarios que sufren los efectos.

Actualmente es posible poner en la lista negra algunos Cipher Suites al iniciar el navegador Google Chrome ejecutándolo con el --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013parámetro, que parece deshabilitar los relacionados con la vulnerabilidad LogJam y permite a los usuarios unirse a los sitios, pero insisto en que debería ser responsabilidad de los administradores de sistemas. para solucionar el problema con las llaves de su Diffie-Hellmann.

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

Dos escenarios no improbables son una computadora portátil que ha sido infectada fuera de la intranet accediendo al servidor interno cuando se conectan nuevamente 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 se conecta a un servidor comprometido y es un punto de partida para atacar sus servidores de intranet.

Como no estoy familiarizado personalmente con todos los problemas que presenta la falla logjam, no puedo decir si alguna de esas 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 del servidor de intranet tienden a hacer cosas como hacer sitios bonitos antes de abordar los problemas de seguridad del servidor.

Enfrenté el mismo problema. Si usted es 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 lo ayudará a resolver este problema de clave SSL.