In het verleden liepen certificaten vaak af doordat ze handmatig verlengd moesten worden. Mensen zijn het gewoon vergeten te doen. Met de komst van Let's Encrypt en de automatische updateprocedure lijkt het probleem opgelost te moeten zijn. Maar recent laat zien dat het in feite nog steeds relevant is. Helaas blijven de certificaten verlopen.
Voor het geval iemand dit verhaal heeft gemist: om middernacht op 4 mei 2019 werkten bijna alle Firefox-extensies plotseling niet meer.
Het bleek dat de enorme storing is ontstaan doordat Mozilla , die werd gebruikt om extensies te ondertekenen. Daarom werden ze gemarkeerd als "ongeldig" en slaagden ze niet voor de test (). Als tijdelijke oplossing adviseerden de forums om verificatie van extensiehandtekeningen uit te schakelen in about: config of door de systeemklok te wijzigen.
Mozilla heeft prompt de Firefox 66.0.4-patch uitgebracht, die het probleem met het ongeldige certificaat verhelpt, en alle extensies worden weer normaal. De ontwikkelaars raden aan om het te installeren en geen tijdelijke oplossingen om handtekeningverificatie te omzeilen, omdat deze mogelijk in strijd zijn met de patch.
Dit verhaal laat echter eens te meer zien dat het verlopen van certificaten vandaag de dag een urgent probleem blijft.
In dit opzicht is het interessant om op een nogal originele manier te kijken hoe de protocolontwikkelaars met deze taak omgingen. . Hun oplossing kan in twee delen worden verdeeld. Ten eerste zijn dit kortlopende certificaten. Ten tweede, gebruikers waarschuwen voor het verstrijken van de lange termijn.
DNSCrypt
DNSCrypt is een coderingsprotocol voor DNS-verkeer. Het beschermt DNS-communicatie tegen onderscheppingen en MiTM, en stelt u ook in staat om blokkering op het niveau van DNS-query's te omzeilen.
Het protocol verpakt het DNS-verkeer tussen de client en de server in een cryptografische constructie en werkt via de UDP- en TCP-transportprotocollen. Om het te gebruiken, moeten zowel de client als de DNS-resolver DNSCrypt ondersteunen. Sinds maart 2016 is het bijvoorbeeld ingeschakeld op zijn DNS-servers en in de Yandex-browser. Verschillende andere providers hebben ook ondersteuning aangekondigd, waaronder Google en Cloudflare. Helaas zijn er niet veel (152 openbare DNS-servers staan vermeld op de officiële website). Maar het programma kan handmatig worden geïnstalleerd op Linux-, Windows- en MacOS-clients. Er zijn ook .
Hoe werkt DNSCrypt? Kortom, de klant neemt de openbare sleutel van de geselecteerde provider en gebruikt deze om zijn certificaten te verifiëren. Er zijn al openbare kortetermijnsleutels voor de sessie en de identifier van de coderingssuite. Klanten worden aangemoedigd om voor elk verzoek een nieuwe sleutel te genereren en servers worden aangemoedigd om sleutels te wijzigen elke 24 uur. Bij het uitwisselen van sleutels wordt het X25519-algoritme gebruikt, voor ondertekening - EdDSA, voor blokversleuteling - XSalsa20-Poly1305 of XChaCha20-Poly1305.
Een van de ontwikkelaars van het protocol, Frank Denis dat automatische vervanging elke 24 uur loste het probleem van verlopen certificaten op. De dnscrypt-proxy-referentieclient accepteert in principe certificaten met elke geldigheidsperiode, maar geeft een waarschuwing "De periode van dnscrypt-proxy-sleutels voor deze server is te lang" als deze langer dan 24 uur geldig is. Tegelijkertijd werd een Docker-image uitgebracht, waarin ze een snelle verandering van sleutels (en certificaten) implementeerden.
Ten eerste is dit uiterst handig voor de veiligheid: als de server wordt gecompromitteerd of de sleutel wordt gelekt, kan het verkeer van gisteren niet worden ontsleuteld. De sleutel is al gewijzigd. Waarschijnlijk zal dit een probleem zijn voor de implementatie van de Yarovaya-wet, die providers dwingt al het verkeer op te slaan, ook versleuteld. Het is duidelijk dat het later indien nodig kan worden gedecodeerd door de sleutel van de site op te vragen. Maar in dit geval kan de site het gewoon niet leveren, omdat het kortstondige sleutels gebruikt en de oude verwijdert.
Maar het belangrijkste, schrijft Denis, dwingen servers op korte termijn om vanaf de eerste dag automatisering in te stellen. Als de server verbinding maakt met het netwerk en de sleutelwijzigingsscripts niet zijn geconfigureerd of niet werken, wordt dit onmiddellijk gedetecteerd.
Wanneer automatisering om de paar jaar van sleutel verandert, kan er niet op worden vertrouwd en kunnen mensen de vervaldatum van het certificaat vergeten. Bij een dagelijkse sleutelwissel wordt dit direct gedetecteerd.
Tegelijkertijd maakt het, als de automatisering goed is ingericht, niet uit hoe vaak de sleutels worden gewisseld: elk jaar, elk kwartaal of drie keer per dag. Als alles langer dan 24 uur werkt, dan werkt het voor altijd, schrijft Frank Denis. Volgens hem heeft het aanbevelen van een dagelijkse nieuwe sleutel in de tweede versie van het protocol, samen met een kant-en-klare Docker-image die dit implementeert, effectief het aantal servers met verlopen certificaten verminderd, terwijl de beveiliging is verbeterd.
Sommige providers hebben om technische redenen toch besloten om de geldigheidsduur van het certificaat vast te stellen op meer dan 24 uur. Dit probleem werd grotendeels opgelost met een paar regels code in dnscrypt-proxy: gebruikers krijgen een informatieve waarschuwing 30 dagen voordat het certificaat verloopt, een ander bericht met een hoger ernstniveau 7 dagen voor de vervaldatum en een crashbericht als het certificaat is vertrokken minder dan 24 uur. Dit geldt alleen voor certificaten die initieel een lange geldigheidsduur hebben.
Dergelijke berichten geven gebruikers de mogelijkheid om DNS-operators te informeren over de naderende certificaatvervaldatum voordat het te laat is.
Als alle Firefox-gebruikers zo'n bericht zouden ontvangen, zou iemand de ontwikkelaars zeker informeren en zouden ze niet toestaan dat het certificaat verloopt. "Ik kan me geen enkele DNSCrypt-server herinneren op de lijst met openbare DNS-servers waarvan het certificaat in de afgelopen twee of drie jaar is verlopen", schrijft Frank Denis. In ieder geval is het waarschijnlijk beter om gebruikers eerst te waarschuwen in plaats van extensies zonder waarschuwing uit te schakelen.
Bron: www.habr.com