Forçar o Chrome a ignorar uma "chave pública Diffie-Hellman efêmera fraca"

Com a atualização do Chrome para a versão 45, ele está bloqueando o acesso a páginas com chaves públicas Diffie-Hellman ephermeral fracas. Eu entendo que isso é devido ao Logjam. Eu entendo que a mudança de https para http é uma "solução" em alguns casos.

No entanto, não consigo alternar de https para http porque sou redirecionado automaticamente para https pelo software baseado na Web que usamos em nossa intranet.

Obviamente, a solução seria ter segurança alterar os vários servidores da intranet para ser seguro de logjam, eu entendo que, mas isso não é uma opção neste exato minuto, e eu não posso fazer mais nenhum trabalho até que seja corrigido. Porque é uma intranet e simplesmente conectando em tudo exige que um esteja fisicamente aqui, o risco é minúsculo.

Existe alguma maneira de continuar acessando páginas via protocolo https, com chaves públicas efêmeras Diffie-Hellman na versão 45 do Chrome?

Correção Hacky para contornar este problema (Mac OSX)

• Execute isso na linha de comando para solucionar o problema durante o lançamento do Chrome

Cromada:

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

Canário:

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

Para o Firefox

• Ir para about: config
• Procurar por security.ssl3.dhe_rsa_aes_128_sha e security.ssl3.dhe_rsa_aes_256_sha
• Defina ambos para false.

NOTA: Consertar permanentemente seria atualizar a chave DH com um comprimento & gt; 1024

De fato, parece que os navegadores levaram a sério o problema Diffie-Hellman com chaves menores do que 1024 de comprimento, que em uma parte é ótimo notícias, mas por outro lado, gerou muita usuários zangados do Google Chrome .

A correção para este problema (e muitos outros relacionados à segurança) é responsabilidade dos administradores, então, pelo que entendi, a decisão de bloquear qualquer site que ofereça uma chave Diffie-Hellman fraca de 512 bits ou inferior é uma medida de pressão direcionada ao usuário. aqueles que gerenciam a segurança em sites remotos, com o "desvantagem" de usuários que sofrem os efeitos.

No momento, é possível colocar blacklists em algumas Cipher Suites ao iniciar o navegador Google Chrome, executando-o com o --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013 Parâmetro, que parece desabilitar os relacionados à vulnerabilidade do LogJam e permite que os usuários participem dos sites, mas eu insisto que deve ser responsabilidade do administrador do sistema corrigir o problema com as chaves do Diffie-Hellmann.

Uma das perguntas que você fez foi se havia alguma desvantagem em usar as soluções alternativas listadas (ou usar outras que não estavam listadas) em uma configuração de intranet. A resposta curta é que, contanto que os servidores envolvidos usem chaves fracas, os servidores envolvidos serão suscetíveis a qualquer sistema que use um ataque logjam e, dependendo da natureza do servidor, o servidor pode subsequentemente ser um servidor comprometido que pode propagar o servidor. problema para outros clientes acessando o servidor.

Dois cenários não improváveis ​​são um laptop que foi infectado pela intranet acessando o servidor interno quando eles se conectam à intranet novamente ou um navegador configurado para ignorar o problema (como sugerido acima e em outro lugar) usado atualmente para acessar a Internet e que acontece de se conectar a um servidor comprometido sendo um ponto de partida para atacar seus servidores de intranet.

Como não estou pessoalmente familiarizado com todas as questões que a falha do logjam apresenta, não posso dizer se alguma dessas duas situações é particularmente provável. Minha própria experiência é que os administradores de sistemas com servidores voltados para a Internet tendem a chegar o mais longe possível de tais problemas. Dito isso, minha experiência também é que os administradores de servidores de intranet tendem a fazer coisas como criar sites antes de resolver os problemas de segurança do servidor.

Enfrentou o mesmo problema. Se você é do lado do servidor basta adicionar as seguintes linhas no conector 443 no server.xml tomcat

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

Isso ajudará você a resolver esse problema de chave SSL.