Tidligere udløb certifikater ofte, fordi de skulle opdateres manuelt. Folk glemte simpelthen at gøre det. Med fremkomsten af Let’s Encrypt og en automatisk opdateringsprocedure burde problemet være løst. Men en nylig viser, at det faktisk stadig er relevant. Desværre fortsætter certifikater med at udløbe.
Hvis nogen har misset denne historie, stoppede næsten alle Firefox-udvidelser pludselig med at fungere ved midnat den 4. maj 2019.
Som det viste sig, opstod der en massiv fejl, fordi Mozillas , der blev brugt til at signere udvidelserne. Derfor blev de markeret som "ugyldige" og bestod ikke kontrol (). På forumene blev det anbefalet at deaktivere signaturkontrol for udvidelser i about:config eller ændre systemuret.
Mozilla udgav hurtigt en opdatering til Firefox 66.0.4, som løser problemet med det ugyldige certifikat, og alle udvidelser vender tilbage til normal. Udviklerne anbefaler at installere den og nogle genveje for at omgå signaturkontrollen, da de kan konflikte med opdateringen.
Alligevel viser denne historie igen, at udløb af certifikater stadig er et aktuelt problem i dag.
I denne forbindelse er det interessant at se på den ret originale metode, som udviklerne af protokollen har håndteret denne opgave. Deres løsning kan opdeles i to dele. For det første er det kortvarige certifikater. For det andet advarsel til brugerne om udløbet af langtidscertifikater.
DNSCrypt
DNSCrypt er en protokol til kryptering af DNS-trafik. Den beskytter DNS-kommunikation mod opsnapning og MiTM og giver også mulighed for at omgå blokeringer på DNS-forespørgselsniveau.
Protokollen indkapsler DNS-trafik mellem klient og server i en kryptografisk struktur, der arbejder over transportprotokollerne UDP og TCP. For at bruge det skal både klienten og DNS-resolveren understøtte DNSCrypt. For eksempel, siden marts 2016 har det været aktiveret på Yandex' DNS-servere og i deres browser. Nogle andre udbydere, herunder Google og Cloudflare, har også annonceret støtte. Desværre er der ikke mange af dem (152 offentlige DNS-servere er opført på det officielle websted). Men programmet det kan installeres manuelt på klienter under Linux, Windows og MacOS. Der er også .
Hvordan fungerer DNSCrypt? Kort sagt, klienten tager den offentlige nøgle fra den valgte udbyder og bruger den til at kontrollere dens certifikater. Her findes kortvarige offentlige nøgler til sessionen og identifikatoren for krypteringsmetoden. Klienter anbefales at generere en ny nøgle til hver forespørgsel, mens serverne bør ændre nøglerne hver 24 timer. Under nøgleudvekslingen anvendes algoritmen X25519, til signaturer bruges EdDSA, og til blokdækning anvendes XSalsa20-Poly1305 eller XChaCha20-Poly1305.
En af udviklerne af protokollen, Frank Denis , at automatisk udskiftning hver 24. time løste problemet med udløbne certifikater. I princippet accepterer den referencerklient, dnscrypt-proxy, certifikater med enhver gyldighedsperiode, men udsteder en advarsel om, at "Periode for dnscrypt-proxy-nøgler til denne server er for lang", hvis den er gyldig i over 24 timer. Samtidig blev der udgivet et Docker-billede, der muliggjorde hurtig nøgleudskiftning (og certifikater).
For det første er det ekstremt nyttigt for sikkerheden: hvis serveren er kompromitteret eller nøglen er lækket, kan gårsdagens trafik ikke dekrypteres. Nøglen er allerede blevet ændret. Dette vil sandsynligvis udgøre et problem for implementeringen af "Yarovaya-loven", som tvinger udbydere til at gemme al trafik, herunder den krypterede. Det antages, at den senere kan dekrypteres ved behov ved at anmode om nøglen fra webstedet. Men i dette tilfælde vil webstedet simpelthen ikke kunne give den, fordi det bruger kortvarige nøgler og sletter de gamle.
Men vigtigst af alt, skriver Denis, får kortvarige nøgler serverne fra første dag til at sætte automatisering i gang. Hvis serveren tilsluttes nettet, og scripts til nøgleudskiftning ikke er konfigureret eller ikke fungerer, vil dette straks blive opdaget.
Når automatiseringen ændrer nøgler hvert par år, kan man ikke stole på det, og folk kan glemme udløbsdatoen for certifikatet. Ved daglig ændring af nøgler vil dette straks blive opdaget.
Samtidig, hvis automatiseringen er korrekt indstillet, betyder det ikke noget, hvor ofte nøglerne skiftes: hvert år, hvert kvartal eller tre gange om dagen. Hvis alt fungerer i mere end 24 timer, vil det fungere for evigt, skriver Frank Denis. Ifølge ham har anbefalingen om daglig nøgleskift i den anden version af protokollen sammen med et klart Docker-billede, der implementerer det, effektivt reduceret antallet af servere med udløbne certifikater, samtidig med at sikkerheden er blevet forbedret.
Dog har nogle udbydere alligevel valgt at etablere en gyldighedsperiode for certifikatet på mere end 24 timer af tekniske årsager. Dette problem er hovedsageligt løst ved hjælp af et par linjer kode i dnscrypt-proxy: brugerne modtager en informativ advarsel 30 dage før certifikatets udløb, en anden med højere alvorlighed 7 dage før udløbet og en kritisk meddelelse, hvis der er mindre end 24 timer tilbage. Dette gælder kun for certifikater, der oprindeligt har en lang gyldighedsperiode.
Sådanne meddelelser giver brugerne mulighed for at informere DNS-operatørerne om det kommende udløb af certifikatet, inden det er for sent.
Måske, hvis alle Firefox-brugere havde fået en sådan meddelelse, ville nogen bestemt have informeret udviklerne, og de ville ikke have tilladt udløbet af certifikatet. "Jeg kan ikke huske nogen DNSCrypt-server fra listen over offentlige DNS-servere, som har haft et udløbet certifikat i de sidste to eller tre år," skriver Frank Denis. Under alle omstændigheder er det måske bedre at advare brugerne først, snarere end at deaktivere udvidelser uden advarsel.
Kilde: habr.com
