No passado, os certificados geralmente expiravam porque precisavam ser atualizados manualmente. As pessoas simplesmente se esqueceram de fazê-lo. Com o advento do Let's Encrypt e um procedimento de atualização automática, o problema parece estar resolvido. Mas uma
história recente
com o Firefox mostra que, de fato, ainda é relevante. Infelizmente, os certificados continuam a expirar.
Se alguém perdeu essa história, quase todas as extensões do Firefox pararam de funcionar à meia-noite de 4 de maio de 2019.
Como se viu, ocorreu uma falha maciça porque o Mozilla
expirou o certificado usado para assinar as extensões. Portanto, eles foram marcados como "inválidos" e não passaram no teste (
detalhes técnicos ). Nos fóruns, como solução alternativa, recomendamos desativar a verificação das assinaturas de extensão em
about: config ou traduzindo o relógio do sistema.
A Mozilla lançou rapidamente o patch do Firefox 66.0.4, que resolve o problema com um certificado inválido, e todas as extensões retornam à sua forma normal. Os desenvolvedores recomendam instalá-lo e
não usar nenhuma solução alternativa para ignorar a verificação de assinatura, porque eles podem entrar em conflito com o patch.
No entanto, essa história mostra mais uma vez que a expiração de certificados continua sendo um problema urgente hoje.
Nesse sentido, é interessante observar de uma maneira bastante original como os desenvolvedores do protocolo
DNSCrypt lidaram com essa tarefa. Sua solução pode ser dividida em duas partes. Em primeiro lugar, esses são certificados de curto prazo. Em segundo lugar, alertando os usuários sobre a expiração dos de longo prazo.
DNSCrypt
DNSCrypt - protocolo de criptografia de tráfego DNS. Ele protege as comunicações DNS contra interceptações e MiTM e também permite ignorar o bloqueio no nível das consultas DNS.
O protocolo envolve o tráfego DNS entre o cliente e o servidor em um design criptográfico, trabalhando nos protocolos de transporte UDP e TCP. Para usá-lo, o cliente e o resolvedor DNS devem oferecer suporte ao DNSCrypt. Por exemplo, desde março de 2016, ele foi ativado em seus servidores DNS e no navegador Yandex. O suporte foi anunciado por vários outros fornecedores, incluindo Google e Cloudflare. Infelizmente, não existem muitos (152 servidores DNS públicos estão listados no site oficial). Mas o programa
dnscrypt-proxy pode ser instalado manualmente em clientes sob Linux, Windows e MacOS. Existem
implementações de servidor .
Como o DNSCrypt funciona? Em resumo, o cliente pega a chave pública do provedor selecionado e, com sua ajuda, verifica seus certificados. Já existem chaves públicas de curto prazo para a sessão e o identificador do conjunto de criptografia. Os clientes são aconselhados a gerar uma nova chave para cada solicitação e os servidores são incentivados a alterar as chaves a
cada 24 horas . Ao trocar chaves, o algoritmo X25519 é usado, EdDSA para assinatura e XSalsa20-Poly1305 ou XChaCha20-Poly1305 para criptografia de bloco.
Frank Denis, um dos desenvolvedores de protocolo,
escreve que a 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 exibe 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, uma imagem do Docker foi lançada, na qual eles implementaram uma rápida alteração de chaves (e certificados).
Primeiro, é extremamente útil para 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. Isso provavelmente será um problema para a implementação da "Lei da Primavera", que força os provedores a armazenar todo o tráfego, incluindo o tráfego criptografado. Entende-se que posteriormente pode ser descriptografado, se necessário, solicitando uma chave do site. Mas, neste caso, o site simplesmente não poderá fornecê-lo, porque usa chaves de curto prazo, excluindo as antigas.
Mas, o mais importante, escreve Denis, 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, você não pode confiar nela, e as pessoas podem esquecer a expiração do certificado. Com uma alteração diária da chave, isso será detectado instantaneamente.
Ao mesmo tempo, se a automação estiver configurada normalmente, não importa com que frequência as chaves são alteradas: 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 uma alteração diária da chave na segunda versão do protocolo, juntamente com a imagem pronta do Docker que implementa isso, reduziu efetivamente o número de servidores com certificados expirados, além de melhorar a segurança.
No entanto, alguns fornecedores ainda decidiram, por alguns motivos técnicos, definir o período de validade do certificado para mais de 24 horas. Esse problema foi resolvido principalmente com algumas linhas de código no dnscrypt-proxy: os usuários recebem um aviso informativo 30 dias antes da expiração do certificado, outra mensagem com um nível de severidade mais alto 7 dias antes da expiração do certificado e uma mensagem crítica se o certificado permanecer menos de 24 horas. Isso se aplica apenas a certificados que inicialmente possuem um longo período de validade.
Essas mensagens permitem que os usuários informem os operadores DNS sobre a expiração do próximo certificado antes que seja tarde demais.
Talvez se todos os usuários do Firefox recebessem essa mensagem, alguém provavelmente teria informado os desenvolvedores e não teria permitido que o certificado expirasse. "Não me lembro de um único servidor DNSCrypt da lista de servidores DNS públicos que expiraram um certificado nos últimos dois ou três anos", escreve Frank Denis. De qualquer forma, provavelmente é melhor avisar os usuários primeiro e não desativar as extensões sem aviso.
