No pasado, os certificados adoitaban caducar porque tiñan que ser renovados manualmente. A xente simplemente esqueceuse de facelo. Coa chegada de Let's Encrypt e o procedemento de actualización automática, parece que o problema debería resolverse. Pero recente demostra que, de feito, segue sendo relevante. Desafortunadamente, os certificados seguen caducando.
No caso de que perdeches a historia, á medianoite do 4 de maio de 2019, case todas as extensións de Firefox deixaron de funcionar de súpeto.
Como se viu, o fracaso masivo ocorreu debido ao feito de que Mozilla , que se utilizaba para asinar extensións. Polo tanto, foron marcados como "non válidos" e non se verificaron (). Nos foros, como solución alternativa, recomendábase desactivar a verificación da sinatura da extensión sobre: config ou cambiar o reloxo do sistema.
Mozilla lanzou inmediatamente o parche 66.0.4 de Firefox, que resolve o problema cun certificado non válido e todas as extensións volven á normalidade. Os desenvolvedores recomendan instalalo e non hai solucións para evitar a verificación da sinatura porque poden entrar en conflito co parche.
Non obstante, esta historia mostra unha vez máis que a caducidade do certificado segue sendo un problema urxente hoxe en día.
Neste sentido, é interesante ver dun xeito bastante orixinal como os desenvolvedores do protocolo trataron esta tarefa . A súa solución pódese dividir en dúas partes. En primeiro lugar, son certificados a curto prazo. En segundo lugar, avisar aos usuarios sobre a caducidade dos a longo prazo.
DNSCrypt
DNSCrypt é un protocolo de cifrado de tráfico DNS. Protexe as comunicacións DNS de interceptacións e MiTM, e tamén permite evitar o bloqueo a nivel de consulta de DNS.
O protocolo envolve o tráfico DNS entre o cliente e o servidor nunha construción criptográfica, que opera sobre os protocolos de transporte UDP e TCP. Para usalo, tanto o cliente como o resolvedor de DNS deben admitir DNSCrypt. Por exemplo, desde marzo de 2016, está habilitado nos seus servidores DNS e no navegador Yandex. Varios outros provedores tamén anunciaron soporte, incluíndo Google e Cloudflare. Desafortunadamente, non hai moitos deles (152 servidores DNS públicos están listados no sitio web oficial). Pero o programa pódese instalar manualmente en clientes Linux, Windows e MacOS. Tamén os hai .
Como funciona DNSCrypt? En resumo, o cliente toma a clave pública do provedor seleccionado e utilízaa para verificar os seus certificados. Xa están alí as claves públicas a curto prazo para a sesión e o identificador do conxunto de cifrado. Anímase aos clientes a xerar unha nova clave para cada solicitude e aos servidores a que cambien as claves cada 24 horas. Ao intercambiar claves, utilízase o algoritmo X25519, para a sinatura - EdDSA, para o cifrado de bloques - XSalsa20-Poly1305 ou XChaCha20-Poly1305.
Un dos desenvolvedores do protocolo Frank Denis esa substitución automática cada 24 horas resolveu o problema dos certificados caducados. En principio, o cliente de referencia dnscrypt-proxy acepta certificados con calquera período de validez, pero emite un aviso "O período da clave dnscrypt-proxy para este servidor é demasiado longo" se é válido durante máis de 24 horas. Ao mesmo tempo, lanzouse unha imaxe de Docker, na que se implementou un cambio rápido de claves (e certificados).
En primeiro lugar, é moi útil para a seguridade: se o servidor está comprometido ou se filtra a chave, o tráfico de onte non se pode descifrar. A chave xa cambiou. Isto probablemente suporá un problema para a implementación da Lei Yarovaya, que obriga aos provedores a almacenar todo o tráfico, incluído o cifrado. A implicación é que posteriormente se pode descifrar se é necesario solicitando a clave do sitio. Pero neste caso, o sitio simplemente non pode proporcionalo, porque usa claves a curto prazo, eliminando as antigas.
Pero o máis importante, escribe Denis, as claves a curto prazo obrigan aos servidores a configurar a automatización desde o primeiro día. Se o servidor se conecta á rede e os scripts de cambio de clave non están configurados ou non funcionan, detectarase inmediatamente.
Cando a automatización cambia as claves cada poucos anos, non se pode confiar nela e a xente pode esquecerse da caducidade do certificado. Se cambias as teclas diariamente, detectarase ao instante.
Ao mesmo tempo, se a automatización se configura normalmente, non importa a frecuencia con que se cambien as claves: cada ano, cada trimestre ou tres veces ao día. Se todo funciona durante máis de 24 horas, funcionará para sempre, escribe Frank Denis. Segundo el, a recomendación da rotación diaria de chaves na segunda versión do protocolo, xunto cunha imaxe de Docker preparada que a implementa, reduciu efectivamente o número de servidores con certificados caducados, á vez que melloraba a seguridade.
Non obstante, algúns provedores aínda decidiron, por algúns motivos técnicos, establecer o período de validez do certificado en máis de 24 horas. Este problema resolveuse en gran parte cunhas poucas liñas de código en dnscrypt-proxy: os usuarios reciben un aviso informativo 30 días antes de que caduque o certificado, outra mensaxe cun nivel de gravidade superior 7 días antes da caducidade e unha mensaxe crítica se o certificado ten algún resto. vixencia.menos de 24 horas. Isto só se aplica aos certificados que inicialmente teñen un longo período de validez.
Estas mensaxes dan aos usuarios a oportunidade de notificar aos operadores de DNS da inminente caducidade do certificado antes de que sexa demasiado tarde.
Quizais se todos os usuarios de Firefox recibisen unha mensaxe deste tipo, entón alguén probablemente informaría aos desenvolvedores e non permitirían que o certificado expirase. "Non recordo ningún servidor DNSCrypt da lista de servidores DNS públicos que teña o seu certificado caducado nos últimos dous ou tres anos", escribe Frank Denis. En calquera caso, probablemente sexa mellor avisar primeiro aos usuarios en lugar de desactivar as extensións sen previo aviso.
Fonte: www.habr.com