Desde que atualizei o Firefox para a versão 38, encontro um problema ao enviar um determinado formulário no site https://usercenter.checkpoint.com/ A maioria do site funciona normalmente, mas envia um formulário durante a abertura de um tíquete de suporte (URL no log abaixo ) faz com que o Firefox falhe na negociação do TLS. A página de erro do Firefox não explica quase nada:
Falha na Conexão Segura
A conexão com o servidor foi redefinida enquanto a página estava carregando.
- A página que você está tentando visualizar não pode ser mostrada porque a autenticidade dos dados recebidos não pôde ser verificada.
- Entre em contato com os proprietários do site para informá-los sobre esse problema.
Denunciar este erro
Relatar as informações de endereço e certificado em usercenter.checkpoint.com nos ajudará a identificar e bloquear sites maliciosos. Obrigado por ajudar a criar uma web mais segura!
Relatar automaticamente erros no futuro Saiba mais…
No console do desenvolvedor da web, vejo apenas isso:
19:58:44.470 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 AjaxCall
19:58:44.589 POST https://usercenter.checkpoint.com/usercenter/portal/js_pane/supportId,CreateServiceRequestId [178ms]
A primeira linha é apenas um aviso de que no futuro o SHA-1 não será suportado. Preciso ativar algo para ver a causa da falha do TLS? As informações sobre TLS e certificado do console estão abaixo:
Não vejo nada de errado lá. Por desespero, tentei brincar com os parâmetros TLS about:configsem sucesso:
security.tls.insecure_fallback_hosts
security.tls.unrestricted_rc4_fallback
security.tls.version.fallback-limit
security.tls.version.max
security.tls.version.min
O teste Qualy SSL não mostra nada completamente errado: https://www.ssllabs.com/ssltest/analyze.html?d=usercenter.checkpoint.com
Há um artigo promissor na base de conhecimento da Red Hat: servidores Firefox 38 e SSL / TLS que são intolerantes à versão TLS, mas a solução está disponível apenas para clientes pagantes.
Também verifiquei a compatibilidade do site para o Firefox 38 .
Questões
- Como posso solucionar o problema da falha do TLS?
- No Firefox, existem outras listas brancas configuráveis pelo usuário em que posso tentar adicionar o endereço do site com falha?
- Quais poderiam ser as razões para a falha aparecer somente após o envio de um determinado formulário enquanto o console mostra que a solicitação POST vai para o mesmo host
usercenter.checkpoint.comda comunicação bem-sucedida anterior?
{Distinguished Name, Serial Number}torna o certificado exclusivo, para que ele possa ser selecionado sem ambiguidade; veja RFC 4158 . Mas veja as advertências abaixo ao selecioná-lo, porque não é uma coisa fácil de fazer. Além disso, o Checkpoint não deve enviar o certificado G5 antigo como parte da cadeia.Respostas:
Use
openssl s_client. É um canivete suíço para coisas assim. E useopenssl x509para despejar certificados.Você geralmente está interessado nos
{Issuer, Subject}pares na cadeia assim:Observe como o emissor no servidor se torna o assunto para o próximo certificado superior. Gutmann fornece o seguinte diagrama para descrevê-lo em seu livro Engineering Security :
No topo, a raiz da CA é autoassinada e o problema e o assunto são os mesmos. Se houvesse um nível 3, seria:
Mas você geralmente não vê isso em cadeia, porque deve confiar nisto. E parte dos requisitos para a âncora de confiança é que você já a possui para garantir que não seja adulterada.
O uso dos nomes Assunto e Emissor está utilizando o que se chama Nomes Distintos . A outra maneira de formar uma corrente é com
KEYIDs. Às vezes, você o vê através do SKI ( Subject Key Identifier ) e do AKI ( Authority Key Identifier ). Os identificadores de chave são apenas impressões digitais de uma chave pública digerida.Você pode encontrar a leitura de Nomes Distintos em padrões como RFC 4514 ; e usando KEYIDs em padrões como o RFC 4518 , que se preocupa com a construção de caminhos.
Parece que o problema está no navegador (mas veja abaixo). Parece que está faltando a
Class 3 Public Primary Certification Authorityimpressão digitala1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b.Quando visito o Symantec Root Certifcates e baixa a Autoridade de Certificação Primária Pública da Classe 3 , posso criar um caminho para a validação (observe o
Verify return code: 0 (ok)abaixo).Você deve baixar e instalar
Class 3 Public Primary Certification Authorityna loja raiz confiável do seu navegador. Ou determine por que não está sendo usado pelo navegador para criar o caminho (veja a seguir).Mozilla e Firefox falam sobre
Class 3 Public Primary Certification Authorityem uma postagem no blog: Eliminando gradualmente os certificados com as chaves RSA de 1024 bits . De acordo com a publicação, eles preteriram esse certificado da CA desde o Firefox 32. Eu realmente não os culpo, pois essas chaves são usadas a longo prazo para operações de assinatura da CA e precisam de parâmetros "mais fortes" porque precisam viver de 10 a 30 anos (literalmente).O Checkpoint precisa obter um novo certificado de servidor emitido sob um certificado (cadeia) com parâmetros contemporâneos, como uma CA com um módulo RSA de 4096 bits e SHA-256. Ou uma CA subordinada com um módulo RSA de 2048 bits e SHA-256 ...
(Veja também o que não funcionou para mim abaixo).
Aqui está um exemplo de validação do certificado do servidor com a Autoridade de Certificação Primária Pública da Classe 3 usando o OpenSSL
s_client:Anteriormente, eu disse: "No topo, a raiz da CA é autoassinada e o problema e o assunto são os mesmos" . Aqui está um despejo dessa raiz de CA autoassinada, onde o Assunto e o Emissor são os mesmos. Ele também mostra os módulos de 1024 bits e sha1WithRSAEncryption.
Anteriormente, eu disse: "O Checkpoint precisa obter um novo certificado de servidor emitido sob um certificado (cadeia) com parâmetros contemporâneos, como uma CA com um módulo RSA de 4096 bits e SHA-256. Ou uma CA subordinada com um módulo RSA de 2048 bits e SHA-256 ... " .
Aqui está o que não funcionou para mim: enraizar ou ancorar a confiança na CA subordinada mais forte
VeriSign Class 3 Public Primary Certification Authority - G5e não na CA raiz de 1024 bits mais fraca.EDIT : isso ocorre devido a um erro no OpenSSL 1.0.2a e abaixo. Foi corrigido no OpenSSL 1.0.2b. Consulte Comportamento esperado para verificação quando um subordinado em uma cadeia é promovido a uma raiz autoassinada?
O problema prático é a Symantec reemitir um certificado com o mesmo nome e a mesma chave pública; portanto, o Nome distinto , o Identificador da chave do sujeito e o Identificador da chave da autoridade não foram alterados; mas apenas alterando o número de série .
Consegui identificá-lo abaixo devido aos diferentes números de série entre o certificado enviado na cadeia e o baixado do site da Symantec. Em seguida, ficou claro que o certificado reemitido foi alterado de uma autoridade de certificação subordinada para uma autoridade de certificação raiz.
Você pode usar
-showcertscom o OpenSSLs_clientpara ver os certificados na cadeia:O que normalmente faço a seguir é copiar um certificado codificado PEM na cadeia para uma área de transferência e, em seguida, usá-lo
pbpastepara colar em um terminal e canalizá-lo para o OpenSSLx509. Por exemplo, aqui estão os níveis 2VeriSign Class 3 Public Primary Certification Authority - G5enviados como parte da cadeia:fonte
Para corrigir isso, digite about: config na barra de endereços e selecione "Terei cuidado, prometo!" botão. Nesse ponto, clique duas vezes na opção security.tls.insecure_fallback_hosts e adicione o endereço que você está tentando acessar.
Eu tive que remover o "https: \" (colocar as duas barras invertidas, o superusuário removeu o segundo) do meu endereço para que ele funcionasse, mas seus resultados podem variar, então tente os dois.
Isso é exato a partir do Firefox versão 43.0.1.
fonte
security.tls.insecure_fallback_hostsnão era o caso. Mais tarde, em um comentário, um escreveu que o problema estava no lado do servidor. O servidor estava fechando as conexões.Se você consultar a Autoridade de Certificação Primária Pública da Classe 3 da VeriSign - G5 fornecida na cadeia
openssl s_client ... -showcertse a Autoridade de Certificação Primária Pública da Classe 3 da VeriSign - G5 disponibilizada para download, você verá que são certificados diferentes. Portanto, a Verisign reemitiu um certificado com o mesmo nome distinto e chave pública do assunto .A versão em cadeia da Autoridade de Certificação Primária Pública VeriSign Classe 3 - G5 tem o seguinte número de série e não é autoassinada (observe que o Assunto e o Emissor são diferentes):
A versão baixada dos Certificados Raiz da Symantec da Autoridade de Certificação Primária Pública VeriSign Classe 3 - G5 tem o seguinte número de série e é autoassinada (observe que o Assunto e o Emissor são os mesmos):
Há realmente apenas uma correção aqui.
O ponto de verificação deve parar de enviar a versão antiga subordinada da Autoridade de Certificação Primária Pública Classe 3 da VeriSign - G5 na cadeia.
Isso ocorre porque, na prática, esses caminhos de verificação e seleção de certificados ficarão confusos porque o certificado G5 antigo e o novo certificado G5 são muito semelhantes. Eles são muito semelhantes porque usam o mesmo Nome Distinto e o mesmo Identificador de Chave de Assunto / Identificador de Chave de Autoridade .
Em teoria, você pode extrair o certificado G5 antigo da cadeia enviada pelo servidor e colocá-lo no Mozilla Trust Store. Mas eu suspeito fortemente que isso irá confundir os agentes do usuário que tentam criar um caminho, porque a única coisa que mudou foi o número de série.
Para entender a confusão, consulte o RFC 4158 e como selecionar um certificado. Uma maneira é a
{Distinguished Name, Serial Number}tupla. Mas um certificado sendo verificado não inclui o número de série do emissor. Ele inclui apenas o Nome Distinto e o Identificador da Chave de Autoridade .A Seção 3.5.12, Identificadores de chave correspondente (KIDs), especifica:
Mas não é necessário e está ausente do warez fornecido pela Symantec. Para vê-lo em primeira mão, despeje o intermediário de Nível 1 enviado na cadeia. É chamado VeriSign Classe 3 Secure Server CA - G3 . Observe que ele possui um identificador de chave de autoridade , mas nenhum número de série :
fonte