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

Question

Com a atualização do Chrome para a versão 45, ele está bloqueando o acesso a páginas com chaves públicas Dherie-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 para alterar os vários servidores da intranet para estarem protegidos contra o logjam, eu entendo isso, mas isso não é uma opção neste exato minuto, e eu não posso fazer mais nenhum trabalho até que seja corrigido. Por ser uma intranet e simplesmente conectar-se a todos exige que 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 no Chrome versão 45?

    

Answer 1

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

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

Chrome:

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
• Pesquise 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 tamanho > 1024

    

Answer 2

De fato, parece que os navegadores levaram a sério o problema Diffie-Hellman com chaves menores que 1024 de tamanho, o que em uma parte é uma notícia excelente , mas por outro lado, gerou muito de usuários zangados do Chrome .

A correção para esse problema (e muitos outros relacionados à segurança) é responsabilidade do administrador, 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 direcionado para aqueles que gerenciam segurança em sites remotos, com o "downside" de usuários sofrendo os efeitos.

Atualmente, é possível incluir alguns conjuntos de codificação na lista negra ao iniciar o navegador Google Chrome, executando-o com o parâmetro --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013 , que parece desabilitar os relacionados à vulnerabilidade LogJam e permite que os usuários participem dos sites, mas insisto Deveria ser responsabilidade dos administradores corrigir o problema com as chaves de Diffie-Hellmann.

    

Answer 3

Uma das perguntas que você fez foi se havia alguma desvantagem em usar as soluções alternativas listadas (ou usar outras que não estão listadas) em uma configuração de intranet. A resposta curta é que, enquanto os servidores envolvidos estiverem usando chaves fracas, os servidores envolvidos estarã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 o 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.

    

Answer 4

Enfrentou o mesmo problema. Se você é do lado do servidor, apenas adicione 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.