Korábban a tanúsítványok gyakran lejártak, mert manuálisan kellett megújítani őket. Az emberek egyszerűen elfelejtették megtenni. A Let's Encrypt és az automatikus frissítési eljárás megjelenésével úgy tűnik, hogy a problémát meg kell oldani. De mostanában Firefox történet azt mutatja, hogy valójában még mindig aktuális. Sajnos a tanúsítványok továbbra is lejárnak.

Ha lemaradt volna a történetről, 4. május 2019-én éjfélkor szinte az összes Firefox-bővítmény leállt.

Mint kiderült, a hatalmas hiba annak a ténynek köszönhető, hogy a Mozilla a tanúsítvány lejárt, amelyet a kiterjesztések aláírására használtak. Ezért „érvénytelenként” jelölték meg őket, és nem ellenőrizték (műszaki információk). A fórumokon megkerülő megoldásként azt javasolták, hogy tiltsák le a kiterjesztés aláírásának ellenőrzését about: config vagy megváltoztatja a rendszer órát.

A Mozilla gyorsan kiadta a Firefox 66.0.4-es javítását, amely érvénytelen tanúsítvánnyal oldja meg a problémát, és minden kiterjesztés visszaáll a normál állapotba. A fejlesztők javasolják annak telepítését és ne használja nincs megoldás az aláírás ellenőrzésének megkerülésére, mert ütközhetnek a javítással.

Ez a történet azonban ismét megmutatja, hogy a tanúsítványok lejárata ma is sürgető probléma.

Ebben a tekintetben érdekes egy meglehetősen eredeti módon megvizsgálni, hogyan kezelték a protokollfejlesztők ezt a feladatot DNSCrypt. Megoldásuk két részre osztható. Először is, ezek rövid távú tanúsítványok. Másodszor, figyelmeztesse a felhasználókat a hosszú távúak lejártára.

DNSCrypt

A DNSCrypt egy DNS forgalom titkosítási protokoll. Megvédi a DNS-kommunikációt az elfogásoktól és a MiTM-től, és lehetővé teszi a DNS-lekérdezés szintjén történő blokkolások megkerülését is.

A protokoll az ügyfél és a szerver közötti DNS-forgalmat egy kriptográfiai konstrukcióba csomagolja, amely UDP és TCP szállítási protokollokon keresztül működik. Használatához az ügyfélnek és a DNS-feloldónak is támogatnia kell a DNSCrypt-ot. Például 2016 márciusa óta engedélyezve van a DNS-kiszolgálókon és a Yandex böngészőben. Számos más szolgáltató is bejelentette támogatását, köztük a Google és a Cloudflare. Sajnos nincs belőlük sok (152 nyilvános DNS-szerver szerepel a hivatalos weboldalon). De a program dnscrypt-proxy manuálisan telepíthető Linux, Windows és MacOS kliensekre. Vannak még szerver implementációk.

Hogyan működik a DNSCrypt? Röviden, az ügyfél megkapja a kiválasztott szolgáltató nyilvános kulcsát, és azt használja a tanúsítványok ellenőrzésére. A munkamenet rövid távú nyilvános kulcsai és a titkosítási csomag azonosítója már megvannak. Az ügyfeleket arra ösztönzik, hogy minden kéréshez hozzanak létre új kulcsot, a szervereket pedig a kulcsok megváltoztatására 24 óránként. A kulcsok cseréjekor az X25519 algoritmust használjuk aláíráshoz - EdDSA, blokk titkosításhoz - XSalsa20-Poly1305 vagy XChaCha20-Poly1305.

Az egyik protokollfejlesztő Frank Denis írásokhogy 24 óránkénti automatikus csere megoldotta a lejárt tanúsítványok problémáját. A dnscrypt-proxy referenciakliens elvileg bármilyen érvényességi idejű tanúsítványt elfogad, de figyelmeztetést ad ki: "A dnscrypt-proxy kulcs periódusa ehhez a szerverhez túl hosszú", ha 24 óránál tovább érvényes. Ezzel egy időben megjelent egy Docker image, amelyben a kulcsok (és tanúsítványok) gyors cseréjét valósították meg.

Először is rendkívül hasznos biztonsági szempontból: ha a szerver feltört, vagy a kulcs kiszivárog, akkor a tegnapi forgalom nem dekódolható. A kulcs már megváltozott. Ez valószínűleg problémát jelent a Yarovaya törvény végrehajtása során, amely arra kényszeríti a szolgáltatókat, hogy az összes forgalmat tárolják, beleértve a titkosított forgalmat is. Ebből az következik, hogy később szükség esetén visszafejthető a kulcs lekérésével a webhelyről. De ebben az esetben a webhely egyszerűen nem tudja biztosítani, mert rövid távú kulcsokat használ, törölve a régieket.

De ami a legfontosabb – írja Denis – a rövid távú kulcsok arra kényszerítik a szervereket, hogy az első naptól kezdve automatizálást állítsanak be. Ha a szerver csatlakozik a hálózathoz, és a kulcsmódosítási parancsfájlok nincsenek konfigurálva, vagy nem működnek, a rendszer ezt azonnal észleli.

Amikor az automatizálás néhány évente kulcsot cserél, nem lehet rá támaszkodni, és az emberek elfelejthetik a tanúsítvány lejáratát. Ha naponta cseréli a kulcsokat, a rendszer ezt azonnal észleli.

Ugyanakkor, ha az automatizálás normálisan van konfigurálva, akkor nem számít, milyen gyakran cserélik a kulcsokat: évente, negyedévente vagy naponta háromszor. Ha minden 24 óránál tovább működik, akkor örökké működni fog – írja Frank Denis. Elmondása szerint a protokoll második verziójában szereplő napi kulcsrotáció ajánlása az ezt megvalósító, kész Docker-képpel együtt hatékonyan csökkentette a lejárt tanúsítvánnyal rendelkező szerverek számát, ugyanakkor javította a biztonságot.

Néhány szolgáltató azonban technikai okok miatt mégis úgy döntött, hogy a tanúsítvány érvényességi idejét 24 óránál hosszabbra állítja. Ezt a problémát nagyrészt megoldották néhány soros kóddal a dnscrypt-proxyban: a felhasználók tájékoztató figyelmeztetést kapnak 30 nappal a tanúsítvány lejárta előtt, egy másik üzenetet magasabb súlyossági szinttel 7 nappal a lejárat előtt, és egy kritikus üzenetet, ha a tanúsítványban van még maradék. érvényességi ideje kevesebb, mint 24 óra. Ez csak az eredetileg hosszú érvényességi idejű tanúsítványokra vonatkozik.

Ezek az üzenetek lehetőséget adnak a felhasználóknak, hogy értesítsék a DNS-üzemeltetőket a tanúsítványok közelgő lejáratáról, mielőtt túl késő lenne.

Talán ha minden Firefox felhasználó kapna egy ilyen üzenetet, akkor valószínűleg valaki értesítené a fejlesztőket, és nem engednék lejárni a tanúsítványt. „Egyetlen DNSCrypt-kiszolgálóra sem emlékszem a nyilvános DNS-kiszolgálók listáján, amelynek tanúsítványa lejárt volna az elmúlt két-három évben” – írja Frank Denis. Mindenesetre jobb, ha először figyelmezteti a felhasználókat, mintsem figyelmeztetés nélkül letiltja a bővítményeket.

Forrás: will.com