Tidigare gick certifikat ofta ut eftersom de behövde uppdateras manuellt. Folk glömde helt enkelt att göra det. Med Let’s Encrypt och en automatisk uppdateringsprocedur borde problemet vara löst. Men den senaste historien med Firefox visar att det faktiskt fortfarande är aktuellt. Tyvärr fortsätter certifikat att löpa ut.

Om någon missade denna historia, så slutade nästan alla Firefox-tillägg att fungera vid midnatt den 4 maj 2019.

Som det visade sig uppstod det en massiv driftstörning på grund av att Mozilla hade ett certifikat som varit giltigt, vilket användes för att signera tillägg. Därför markerades de som "ogiltiga" och passerade inte kontrollen (tekniska detaljer). På forumen rekommenderade man som en tillfällig lösning att stänga av kontrollen av tilläggens signaturer i about:config eller ändra systemklockan.

Mozilla släppte snabbt en patch för Firefox 66.0.4, som löser problemet med det ogiltiga certifikatet, och alla tillägg återställdes till det normala. Utvecklarna rekommenderar att installera det och inte använda några tillfälliga lösningar för att kringgå signaturkontroller, eftersom de kan kollidera med patchen.

Denna historia visar ändå återigen att certifikatens utgång kvarstår som ett aktuellt problem även idag.

I detta sammanhang är det intressant att titta på ett ganska originellt sätt som utvecklarna av protokollet DNSCrypthar löst detta problem. Deras lösning kan delas upp i två delar. För det första, korttidscertifikat. För det andra, att meddela användarna om utgången av långtidscertifikat.

DNSCrypt

DNSCrypt är ett protokoll för kryptering av DNS-trafik. Det skyddar DNS-kommunikation från avlyssning och MiTM, samt gör det möjligt att kringgå blockeringar på DNS-frågenivå.

Protokollet kapslar in DNS-trafik mellan klienten och servern i en kryptografisk konstruktion och fungerar över transportprotokollen UDP och TCP. För att använda det måste både klienten och DNS-upplösaren stödja DNSCrypt. Till exempel har Yandex aktiverat det på sina DNS-servrar och i sin webbläsare sedan mars 2016. Flera andra leverantörer, inklusive Google och Cloudflare, har också meddelat sitt stöd. Tyvärr är de inte så många (det finns 152 offentliga DNS-servrar listade på den officiella webbplatsen). Men programmet dnscrypt-proxy manuellt installeras på klienter under Linux, Windows och MacOS. Det finns också serverimplementationer.

Hur fungerar DNSCrypt? Kort sagt, klienten tar den offentliga nyckeln från den valda tjänsteleverantören och kontrollerar dess certifikat med hjälp av den. Där finns kortvariga offentliga nycklar för sessionen och en identifierare för chiffersatsen. Det rekommenderas att klienter genererar en ny nyckel för varje begäran, och servrar bör byta nycklar var 24:e timme. Vid nyckelutbyte används algoritmen X25519, för signering – EdDSA, för blockkryptering – XSalsa20-Poly1305 eller XChaCha20-Poly1305.

En av protokollutvecklarna, Frank Denis skriver, sade att den automatiska bytet var 24:e timme löste problemet med utgångna certifikat. I grund och botten accepterar referensklienten dnscrypt-proxy certifikat med vilken giltighetstid som helst, men ger en varning "Periode av dnscrypt-proxy nycklar för denna server är för lång" om den är giltig längre än 24 timmar. Samtidigt släpptes en Docker-bild där snabb nyckelbyten (och certifikat) implementerades.

För det första är det oerhört användbart för säkerheten: om servern har blivit komprometterad eller nyckeln har läckt, kan gårdagens trafik inte avkodas. Nyckeln har redan bytts ut. Detta kommer sannolikt att bli ett problem för tillämpningen av "Yarovaya-lagen", som tvingar tjänsteleverantörer att lagra all trafik, inklusive krypterad trafik. Det förutsätts att den senare kan avkodas vid behov genom att begära nyckeln från webbplatsen. Men i det här fallet kan webbplatsen helt enkelt inte tillhandahålla den, eftersom den använder kortvariga nycklar och raderar gamla.

Men huvudpunkten, skriver Denis, är att kortvariga nycklar tvingar servrar att automatisera från första dagen. Om servern ansluter till nätverket, och skripten för nyckelbyten inte är inställda eller inte fungerar, kommer det att upptäckas omedelbart.

När automatisering byter nycklar några år, kan man inte lita på den, och människor kan glömma utgångsdatumet för certifikatet. Vid daglig nyckelbyte kommer detta att upptäckas omedelbart.

Samtidigt, om automatiseringen är korrekt inställd, spelar det ingen roll hur ofta nycklar byts: varje år, kvartalsvis eller tre gånger om dagen. Om allt fungerar i mer än 24 timmar, kommer det att fortsätta fungera för alltid, skriver Frank Denis. Enligt honom har rekommendationen att byta nycklar dagligen i den andra versionen av protokollet tillsammans med en färdig Docker-bild som genomför detta effektivt minskat antalet servrar med utgångna certifikat, samtidigt som säkerheten förbättrades.

Men vissa leverantörer har ändå valt av tekniska skäl att sätta giltighetstiden för certifikat till mer än 24 timmar. Detta problem löstes i huvudsak med hjälp av några rader kod i dnscrypt-proxy: användarna får en informationsvarning 30 dagar innan certifikatets utgång, ett annat meddelande med högre allvarlighet 7 dagar innan utgång och ett kritiskt meddelande om det finns mindre än 24 timmar kvar på certifikatet. Detta gäller endast certifikat som från början har en längre giltighetstid.

Dessa meddelanden ger användarna möjlighet att informera DNS-operatörerna om det kommande utgångsdatumet för certifikatet, innan det är för sent.

Kanske, om alla Firefox-användare hade fått ett sådant meddelande, skulle någon säkert ha informerat utvecklarna så att de inte skulle låta certifikatet gå ut. "Jag minns inget DNSCrypt-server från de offentliga DNS-servrarna som har haft utgångna certifikat de senaste två eller tre åren," skriver Frank Denis. I vilket fall som helst, kanske det är bättre att först varna användarna än att stänga av tillägg utan förvarning.

Källa: habr.com