No passado, os certificados expiravam frequentemente porque tinham de ser renovados manualmente. As pessoas simplesmente se esqueceram de fazer isso. Com o advento do Let's Encrypt e do procedimento de atualização automática, parece que o problema deve ser resolvido. Mas recente História do Firefox mostra que, de facto, ainda é relevante. Infelizmente, os certificados continuam a expirar.

Caso você tenha perdido a história, à meia-noite do dia 4 de maio de 2019, quase todas as extensões do Firefox pararam de funcionar repentinamente.

No final das contas, a falha massiva ocorreu devido ao fato de a Mozilla o certificado expirou, que foi usado para assinar extensões. Portanto, foram marcados como “inválidos” e não foram verificados (detalhes técnicos). Nos fóruns, como solução alternativa, foi recomendado desabilitar a verificação de assinatura de extensão em about: config ou alterando o relógio do sistema.

A Mozilla lançou rapidamente o patch do Firefox 66.0.4, que resolve o problema de certificado inválido e todas as extensões voltam ao normal. Os desenvolvedores recomendam instalá-lo e não use não há soluções alternativas para ignorar a verificação de assinatura porque elas podem entrar em conflito com o patch.

No entanto, esta história mostra mais uma vez que a expiração do certificado continua a ser uma questão premente hoje.

A este respeito, é interessante observar de uma forma bastante original como os desenvolvedores do protocolo lidaram com esta tarefa. DNSCrypt. A sua solução pode ser dividida em duas partes. Em primeiro lugar, estes são certificados de curto prazo. Em segundo lugar, alertar os usuários sobre o vencimento dos de longo prazo.

DNSCrypt

DNSCrypt é um protocolo de criptografia de tráfego DNS. Ele protege as comunicações DNS contra interceptações e MiTM e também permite contornar o bloqueio no nível da consulta DNS.

O protocolo envolve o tráfego DNS entre cliente e servidor em uma construção criptográfica, operando sobre os protocolos de transporte UDP e TCP. Para usá-lo, tanto o cliente quanto o resolvedor DNS devem oferecer suporte ao DNSCrypt. Por exemplo, desde março de 2016, está habilitado em seus servidores DNS e no navegador Yandex. Vários outros provedores também anunciaram suporte, incluindo Google e Cloudflare. Infelizmente, não existem muitos deles (152 servidores DNS públicos estão listados no site oficial). Mas o programa proxy dnscrypt pode ser instalado manualmente em clientes Linux, Windows e MacOS. Há também implementações de servidor.

Como funciona o DNSCrypt? Resumindo, o cliente pega a chave pública do provedor selecionado e a utiliza para verificar seus certificados. As chaves públicas de curto prazo da sessão e o identificador do conjunto de cifras já estão lá. Os clientes são incentivados a gerar uma nova chave para cada solicitação e os servidores são incentivados a alterar as chaves a cada 24 horas. Na troca de chaves, é utilizado o algoritmo X25519, para assinatura - EdDSA, para criptografia de bloco - XSalsa20-Poly1305 ou XChaCha20-Poly1305.

Um dos desenvolvedores do protocolo, Frank Denis escreveessa substituição automática a cada 24 horas resolveu o problema dos certificados expirados. Em princípio, o cliente de referência dnscrypt-proxy aceita certificados com qualquer período de validade, mas emite um aviso "O período da chave dnscrypt-proxy para este servidor é muito longo" se for válido por mais de 24 horas. Ao mesmo tempo, foi lançada uma imagem Docker, na qual foi implementada uma rápida mudança de chaves (e certificados).

Primeiro, é extremamente útil para a segurança: se o servidor estiver comprometido ou a chave vazar, o tráfego de ontem não poderá ser descriptografado. A chave já mudou. Isto provavelmente representará um problema para a implementação da Lei Yarovaya, que obriga os provedores a armazenar todo o tráfego, incluindo o tráfego criptografado. A implicação é que ele pode ser descriptografado posteriormente, se necessário, solicitando a chave ao site. Mas, neste caso, o site simplesmente não pode fornecê-lo, pois utiliza chaves de curto prazo, excluindo as antigas.

Mas o mais importante, escreve Denis, é que as chaves de curto prazo forçam os servidores a configurar a automação desde o primeiro dia. Se o servidor se conectar à rede e os scripts de alteração de chave não estiverem configurados ou não funcionarem, isso será detectado imediatamente.

Quando a automação altera as chaves a cada poucos anos, não se pode confiar nela e as pessoas podem esquecer a expiração do certificado. Se você alterar as chaves diariamente, isso será detectado instantaneamente.

Ao mesmo tempo, se a automação estiver configurada normalmente, não importa a frequência com que as chaves são trocadas: todos os anos, trimestralmente ou três vezes ao dia. Se tudo funcionar por mais de 24 horas, funcionará para sempre, escreve Frank Denis. Segundo ele, a recomendação de rotação diária de chaves na segunda versão do protocolo, aliada a uma imagem Docker pronta que o implementa, reduziu efetivamente o número de servidores com certificados expirados, ao mesmo tempo que melhorou a segurança.

No entanto, alguns fornecedores ainda decidiram, por algumas razões técnicas, definir o período de validade do certificado para mais de 24 horas. Este problema foi amplamente resolvido com algumas linhas de código no dnscrypt-proxy: os usuários recebem um aviso informativo 30 dias antes do certificado expirar, outra mensagem com um nível de severidade mais alto 7 dias antes da expiração e uma mensagem crítica se o certificado tiver algum resíduo restante. validade.menos de 24 horas. Isto se aplica apenas a certificados que inicialmente possuem um longo período de validade.

Essas mensagens oferecem aos usuários a oportunidade de notificar os operadores DNS sobre a expiração iminente do certificado antes que seja tarde demais.

Talvez se todos os usuários do Firefox recebessem tal mensagem, alguém provavelmente informaria os desenvolvedores e eles não permitiriam que o certificado expirasse. “Não me lembro de um único servidor DNSCrypt na lista de servidores DNS públicos cujo certificado tenha expirado nos últimos dois ou três anos”, escreve Frank Denis. De qualquer forma, provavelmente é melhor avisar os usuários primeiro, em vez de desabilitar as extensões sem avisar.

Fonte: habr.com