Tidligere udløb certifikater ofte, fordi de skulle fornyes manuelt. Folk glemte simpelthen at gøre det. Med fremkomsten af Let's Encrypt og den automatiske opdateringsprocedure ser det ud til, at problemet burde være løst. Men nyligt viser, at det faktisk stadig er relevant. Desværre fortsætter certifikater med at udløbe.
Hvis du gik glip af historien, ved midnat den 4. maj 2019, holdt næsten alle Firefox-udvidelser pludselig op med at fungere.
Som det viste sig, opstod den massive fiasko på grund af det faktum, at Mozilla , som blev brugt til at signere forlængelser. Derfor blev de markeret som "ugyldige" og blev ikke bekræftet (). På foraene blev det som en løsning anbefalet at deaktivere udvidelsessignaturbekræftelse i about: config eller ændring af systemuret.
Mozilla frigav prompte Firefox 66.0.4-patchen, som løser problemet med et ugyldigt certifikat, og alle udvidelser vender tilbage til normalen. Udviklerne anbefaler at installere det og ingen løsninger til at omgå signaturbekræftelse, fordi de kan være i konflikt med patchen.
Denne historie viser dog endnu en gang, at certifikatudløb er et presserende problem i dag.
I denne forbindelse er det interessant at se på en ret original måde, hvordan protokoludviklerne håndterede denne opgave . Deres løsning kan opdeles i to dele. For det første er der tale om kortsigtede certifikater. For det andet advare brugere om udløbet af langsigtede.
DNSCrypt
DNSCrypt er en DNS-trafikkrypteringsprotokol. Det beskytter DNS-kommunikation mod aflytning og MiTM, og giver dig også mulighed for at omgå blokering på DNS-forespørgselsniveau.
Protokollen indpakker DNS-trafik mellem klient og server i en kryptografisk konstruktion, der fungerer over UDP- og TCP-transportprotokollerne. For at bruge det skal både klienten og DNS-resolveren understøtte DNSCrypt. For eksempel har den siden marts 2016 været aktiveret på sine DNS-servere og i Yandex-browseren. Flere andre udbydere har også annonceret support, herunder Google og Cloudflare. Desværre er der ikke mange af dem (152 offentlige DNS-servere er opført på den officielle hjemmeside). Men programmet kan installeres manuelt på Linux-, Windows- og MacOS-klienter. Der er også .
Hvordan virker DNSCrypt? Kort sagt tager klienten den offentlige nøgle fra den valgte udbyder og bruger den til at verificere sine certifikater. De kortsigtede offentlige nøgler til sessionen og chiffersuite-id'en er der allerede. Klienter opfordres til at generere en ny nøgle for hver anmodning, og servere opfordres til at ændre nøgler hver 24. time. Ved udveksling af nøgler bruges X25519-algoritmen til signering - EdDSA, til blokkryptering - XSalsa20-Poly1305 eller XChaCha20-Poly1305.
En af protokoludviklerne Frank Denis at automatisk udskiftning hver 24 timer løste problemet med udløbne certifikater. I princippet accepterer dnscrypt-proxy-referenceklienten certifikater med enhver gyldighedsperiode, men udsender en advarsel "Dnscrypt-proxy-nøgleperioden for denne server er for lang", hvis den er gyldig i mere end 24 timer. Samtidig blev et Docker-image udgivet, hvor en hurtig ændring af nøgler (og certifikater) blev implementeret.
For det første er det ekstremt nyttigt for sikkerheden: hvis serveren er kompromitteret eller nøglen lækket, så kan gårsdagens trafik ikke dekrypteres. Nøglen er allerede ændret. Dette vil sandsynligvis udgøre et problem for implementeringen af Yarovaya-loven, som tvinger udbydere til at gemme al trafik, inklusive krypteret trafik. Implikationen er, at den senere kan dekrypteres, hvis det er nødvendigt ved at anmode om nøglen fra webstedet. Men i dette tilfælde kan webstedet simpelthen ikke levere det, fordi det bruger kortsigtede nøgler og sletter gamle.
Men vigtigst af alt, skriver Denis, tvinger kortsigtede nøgler servere til at opsætte automatisering fra dag ét. Hvis serveren opretter forbindelse til netværket, og nøgleændringsscripts ikke er konfigureret eller ikke fungerer, vil dette blive opdaget med det samme.
Når automatisering skifter nøgler hvert par år, kan man ikke stole på det, og folk kan glemme alt om certifikatudløb. Hvis du skifter nøglerne dagligt, vil dette blive opdaget med det samme.
På samme tid, hvis automatisering er konfigureret normalt, er det ligegyldigt, hvor ofte nøglerne skiftes: hvert år, hvert kvartal eller tre gange om dagen. Hvis alt virker i mere end 24 timer, vil det fungere for evigt, skriver Frank Denis. Ifølge ham reducerede anbefalingen om daglig nøglerotation i den anden version af protokollen, sammen med et færdiglavet Docker-image, der implementerer det, effektivt antallet af servere med udløbne certifikater, samtidig med at sikkerheden blev forbedret.
Nogle udbydere besluttede dog stadig af tekniske årsager at sætte certifikatets gyldighedsperiode til mere end 24 timer. Dette problem blev stort set løst med et par linjer kode i dnscrypt-proxy: brugere modtager en informativ advarsel 30 dage før certifikatet udløber, en anden besked med et højere alvorlighedsniveau 7 dage før udløb og en kritisk besked, hvis certifikatet har nogen tilbage gyldighed mindre end 24 timer. Dette gælder kun certifikater, der i starten har en lang gyldighedsperiode.
Disse meddelelser giver brugerne mulighed for at underrette DNS-operatører om forestående certifikatudløb, før det er for sent.
Måske hvis alle Firefox-brugere modtog en sådan besked, ville nogen sandsynligvis informere udviklerne, og de ville ikke tillade, at certifikatet udløber. "Jeg kan ikke huske en eneste DNSCrypt-server på listen over offentlige DNS-servere, som har fået sit certifikat udløbet i de sidste to eller tre år," skriver Frank Denis. Under alle omstændigheder er det nok bedre at advare brugerne først i stedet for at deaktivere udvidelser uden varsel.
Kilde: www.habr.com