En el passat, els certificats sovint caducaven perquè s'havien de renovar manualment. La gent simplement s'ha oblidat de fer-ho. Amb l'arribada de Let's Encrypt i el procediment d'actualització automàtica, sembla que el problema s'hauria de resoldre. Però recent demostra que, de fet, encara és rellevant. Malauradament, els certificats continuen caducant.
En cas que us perdeu la història, a la mitjanit del 4 de maig de 2019, gairebé totes les extensions de Firefox van deixar de funcionar de sobte.
Com va resultar, el fracàs massiu es va produir a causa del fet que Mozilla , que s'utilitzava per signar extensions. Per tant, es van marcar com a "no vàlids" i no es van verificar (). Als fòrums, com a solució alternativa, es va recomanar desactivar la verificació de la signatura de l'extensió about: config o canviar el rellotge del sistema.
Mozilla va llançar ràpidament el pedaç de Firefox 66.0.4, que resol el problema amb un certificat no vàlid i totes les extensions tornen a la normalitat. Els desenvolupadors recomanen instal·lar-lo i no hi ha cap solució per evitar la verificació de la signatura perquè poden entrar en conflicte amb el pedaç.
Tanmateix, aquesta història mostra una vegada més que la caducitat del certificat segueix sent un problema urgent avui dia.
En aquest sentit, és interessant veure d'una manera força original com els desenvolupadors de protocols van afrontar aquesta tasca . La seva solució es pot dividir en dues parts. En primer lloc, es tracta de certificats a curt termini. En segon lloc, advertir els usuaris sobre la caducitat dels a llarg termini.
DNSCrypt
DNSCrypt és un protocol de xifratge de trànsit DNS. Protegeix les comunicacions DNS d'intercepcions i MiTM, i també us permet evitar el bloqueig a nivell de consulta DNS.
El protocol embolcalla el trànsit DNS entre el client i el servidor en una construcció criptogràfica, que funciona mitjançant els protocols de transport UDP i TCP. Per utilitzar-lo, tant el client com el resolutor DNS han de ser compatibles amb DNSCrypt. Per exemple, des del març de 2016, s'ha habilitat als seus servidors DNS i al navegador Yandex. Diversos altres proveïdors també han anunciat suport, inclosos Google i Cloudflare. Malauradament, no n'hi ha molts (152 servidors DNS públics es mostren al lloc web oficial). Però el programa es pot instal·lar manualment als clients Linux, Windows i MacOS. Hi ha també .
Com funciona DNSCrypt? En resum, el client agafa la clau pública del proveïdor seleccionat i l'utilitza per verificar els seus certificats. Les claus públiques a curt termini per a la sessió i l'identificador de la suite de xifratge ja hi són. Es recomana als clients que generin una nova clau per a cada sol·licitud i als servidors es recomana que les canviïn cada 24 hores. Quan s'intercanvien claus, s'utilitza l'algoritme X25519, per a la signatura - EdDSA, per a l'encriptació de blocs - XSalsa20-Poly1305 o XChaCha20-Poly1305.
Un dels desenvolupadors del protocol Frank Denis que la substitució automàtica cada 24 hores va resoldre el problema dels certificats caducats. En principi, el client de referència dnscrypt-proxy accepta certificats amb qualsevol període de validesa, però emet un avís "El període de clau dnscrypt-proxy per a aquest servidor és massa llarg" si és vàlid durant més de 24 hores. Al mateix temps, es va publicar una imatge de Docker, en la qual es va implementar un canvi ràpid de claus (i certificats).
En primer lloc, és molt útil per a la seguretat: si el servidor està compromès o la clau es filtra, el trànsit d'ahir no es pot desxifrar. La clau ja ha canviat. Això probablement suposarà un problema per a la implementació de la Llei Yarovaya, que obliga els proveïdors a emmagatzemar tot el trànsit, inclòs el trànsit xifrat. La implicació és que després es pot desxifrar si cal sol·licitant la clau al lloc. Però en aquest cas, el lloc simplement no ho pot proporcionar, perquè utilitza claus a curt termini, eliminant les antigues.
Però el més important, escriu Denis, les claus a curt termini obliguen els servidors a configurar l'automatització des del primer dia. Si el servidor es connecta a la xarxa i els scripts de canvi de clau no estan configurats o no funcionen, això es detectarà immediatament.
Quan l'automatització canvia les claus cada pocs anys, no es pot confiar en ella i la gent pot oblidar-se de la caducitat del certificat. Si canvieu les claus diàriament, això es detectarà a l'instant.
Al mateix temps, si l'automatització es configura amb normalitat, no importa la freqüència amb què es canvien les claus: cada any, cada trimestre o tres vegades al dia. Si tot funciona durant més de 24 hores, funcionarà per sempre, escriu Frank Denis. Segons ell, la recomanació de la rotació diària de claus en la segona versió del protocol, juntament amb una imatge de Docker preparada que la implementa, va reduir efectivament el nombre de servidors amb certificats caducats, alhora que millorava la seguretat.
Tanmateix, alguns proveïdors encara van decidir, per alguns motius tècnics, establir el període de validesa del certificat en més de 24 hores. Aquest problema es va resoldre en gran mesura amb unes quantes línies de codi a dnscrypt-proxy: els usuaris reben un avís informatiu 30 dies abans que caduqui el certificat, un altre missatge amb un nivell de gravetat més alt 7 dies abans de la caducitat i un missatge crític si el certificat en queda. vigència inferior a 24 hores. Això només s'aplica als certificats que inicialment tenen un període de validesa llarg.
Aquests missatges donen als usuaris l'oportunitat d'avisar als operadors DNS de la caducitat imminent del certificat abans que sigui massa tard.
Potser si tots els usuaris de Firefox reben aquest missatge, probablement algú n'informaria els desenvolupadors i no permetria que el certificat caduqui. "No recordo cap servidor DNSCrypt a la llista de servidors DNS públics que hagi caducat el seu certificat en els últims dos o tres anys", escriu Frank Denis. En qualsevol cas, probablement sigui millor avisar primer els usuaris en lloc de desactivar les extensions sense avisar.
Font: www.habr.com