Tidigare gick certifikat ofta ut eftersom de måste förnyas manuellt. Folk glömde helt enkelt att göra det. Med tillkomsten av Let's Encrypt och den automatiska uppdateringsproceduren verkar det som att problemet borde vara löst. Men nyligen visar att det faktiskt fortfarande är relevant. Tyvärr fortsätter certifikaten att löpa ut.
Om du missade historien, vid midnatt den 4 maj 2019, slutade plötsligt nästan alla Firefox-tillägg att fungera.
Som det visade sig inträffade det massiva misslyckandet på grund av att Mozilla , som användes för att signera tillägg. Därför markerades de som "ogiltiga" och verifierades inte (). På forumen, som en lösning, rekommenderades det att inaktivera verifiering av tilläggssignatur i about: config eller ändra systemklockan.
Mozilla släppte snabbt Firefox 66.0.4-patchen, som löser problemet med ett ogiltigt certifikat, och alla tillägg återgår till det normala. Utvecklarna rekommenderar att du installerar det och inga lösningar för att kringgå signaturverifiering eftersom de kan komma i konflikt med patchen.
Den här historien visar dock än en gång att certifikatets utgång förblir en akut fråga idag.
I detta avseende är det intressant att se på ett ganska originellt sätt hur protokollutvecklarna hanterade denna uppgift . Deras lösning kan delas upp i två delar. För det första är det kortsiktiga certifikat. För det andra, varna användare om utgången av långsiktiga sådana.
DNSCrypt
DNSCrypt är ett DNS-trafikkrypteringsprotokoll. Det skyddar DNS-kommunikation från avlyssningar och MiTM, och låter dig även kringgå blockering på DNS-frågenivå.
Protokollet omsluter DNS-trafik mellan klient och server i en kryptografisk konstruktion, som fungerar över UDP- och TCP-transportprotokollen. För att använda det måste både klienten och DNS-resolvern stödja DNSCrypt. Till exempel, sedan mars 2016, har det varit aktiverat på sina DNS-servrar och i Yandex-webbläsaren. Flera andra leverantörer har också meddelat stöd, inklusive Google och Cloudflare. Tyvärr finns det inte många av dem (152 offentliga DNS-servrar är listade på den officiella webbplatsen). Men programmet kan installeras manuellt på Linux-, Windows- och MacOS-klienter. Det finns också .
Hur fungerar DNSCrypt? Kort sagt, klienten tar den offentliga nyckeln för den valda leverantören och använder den för att verifiera sina certifikat. De kortsiktiga publika nycklarna för sessionen och chiffersvitsidentifieraren finns redan där. Klienter uppmuntras att generera en ny nyckel för varje begäran, och servrar uppmuntras att byta nycklar var 24:e timme. Vid utbyte av nycklar används X25519-algoritmen, för signering - EdDSA, för blockkryptering - XSalsa20-Poly1305 eller XChaCha20-Poly1305.
En av protokollutvecklarna Frank Denis att automatiskt byte var 24:e timme löste problemet med utgångna certifikat. I princip accepterar dnscrypt-proxy-referensklienten certifikat med vilken giltighetstid som helst, men utfärdar en varning "Dnscrypt-proxynyckelperioden för den här servern är för lång" om den är giltig i mer än 24 timmar. Samtidigt släpptes en Docker-bild, där ett snabbt byte av nycklar (och certifikat) implementerades.
För det första är det extremt användbart för säkerheten: om servern har äventyrats eller nyckeln läckt kan gårdagens trafik inte dekrypteras. Nyckeln har redan ändrats. Detta kommer sannolikt att utgöra ett problem för implementeringen av Yarovaya-lagen, som tvingar leverantörer att lagra all trafik, inklusive krypterad trafik. Innebörden är att den senare kan dekrypteras vid behov genom att begära nyckeln från webbplatsen. Men i det här fallet kan webbplatsen helt enkelt inte tillhandahålla det, eftersom den använder kortsiktiga nycklar och tar bort gamla.
Men viktigast av allt, skriver Denis, tvingar kortsiktiga nycklar servrar att ställa in automatisering från dag ett. Om servern ansluter till nätverket och nyckeländringsskripten inte är konfigurerade eller inte fungerar, kommer detta att upptäckas omedelbart.
När automatisering byter nycklar med några års mellanrum går det inte att lita på det, och folk kan glömma att certifikatet löper ut. Om du byter nycklar dagligen kommer detta att upptäckas direkt.
Samtidigt, om automatisering är konfigurerad normalt, spelar det ingen roll hur ofta nycklarna byts: varje år, varje kvartal eller tre gånger om dagen. Om allt fungerar i mer än 24 timmar kommer det att fungera för alltid, skriver Frank Denis. Enligt honom minskade rekommendationen om daglig nyckelrotation i den andra versionen av protokollet, tillsammans med en färdig Docker-bild som implementerar det, antalet servrar med utgångna certifikat, samtidigt som säkerheten förbättrades.
Vissa leverantörer beslutade dock, av vissa tekniska skäl, att sätta certifikatets giltighetstid till mer än 24 timmar. Detta problem löstes till stor del med några rader kod i dnscrypt-proxy: användare får en informativ varning 30 dagar innan certifikatet löper ut, ett annat meddelande med en högre svårighetsgrad 7 dagar före utgången och ett kritiskt meddelande om certifikatet har några kvarvarande giltighet, mindre än 24 timmar. Detta gäller endast certifikat som initialt har lång giltighetstid.
Dessa meddelanden ger användarna möjlighet att meddela DNS-operatörer om förestående certifikats utgång innan det är för sent.
Kanske om alla Firefox-användare fick ett sådant meddelande, skulle någon förmodligen informera utvecklarna och de skulle inte tillåta att certifikatet löper ut. "Jag kommer inte ihåg en enda DNSCrypt-server på listan över offentliga DNS-servrar som har fått sitt certifikat att löpa ut under de senaste två eller tre åren", skriver Frank Denis. I vilket fall som helst är det förmodligen bättre att varna användare först än att inaktivera tillägg utan förvarning.
Källa: will.com