Az Internet Security Research Group (ISRG) a Let's Encrypt, a Divvi Up és a Prossimo mögött álló nonprofit szervezet. 2013 óta a Let's Encryptet a világ legnagyobb tanúsítványkiállítóvá vált. Különösen nagy pillanat volt, amikor a Let's Encrypt átlépte a 300 000 000 kiszolgált webhelyet.

2022-ben az ISRG-projektek a méret és a hatás tekintetében új csúcsokat értek el: a Let's Encrypt immáron 300 millió weboldal hitelességét tanúsítja, és ehhez már több mint hárommilliárd tanúsítványt állítottak ki. Emellett a szervezet a Prossimo projektjével, a Rust programnyelvi támogatás Linux kernelbe való bekerülését is elősegítette.

A Prossimo projekt 2020-ban indult, egyértelmű céllal: a biztonságérzékeny szoftverinfrastruktúrát memóriabiztos kódba helyezni. Azóta rengeteg kódot írtak az internet memóriabiztonságának javítása érdekében. Az évet azzal zárták, hogy a Linux kernelbe beolvadt a Rust támogatás, és elkészült a memóriabiztonságos NTP kliens és szerver implementációja. A memóriabiztonságosabb kernel nagy lehetőség, de most már csak a Rust illesztőprogramok fejlesztését kell koncentrálnak. Különösen izgalmas az NVMe-illesztőprogram, amely kiváló kezdeti teljesítmény eredményeket mutat, miközben azzal az előnnyel jár, hogy soha nem okoz memóriabiztonsági hibát. Aktívan dolgoznak azon, hogy hasonló előrelépést érjenek el a Rustls, egy nagy teljesítményű TLS könyvtár és a Trust-DNS, egy teljesen rekurzív DNS feloldó esetében is. Mindezt emberek és szervezetek jótékonysági adományai teszik lehetővé világszerte. 2015 óta emberek tízezrei adakoztak az Internet Security Research Group (ISRG) munkájáhozhoz. Vállalati szponzorálással, DAF-jukon keresztül adakoztak, vagy ismétlődő adományokat járultak hozzá. Mindez összesen több mint 17 millió dollárt tett ki, amelyet arra használnak fel, hogy megváltoztassák az internetet szinte mindenki számára, aki használja.

A Rustls-sel végzett munka története egy másik szoftverrel, az OpenSSL-lel kezdődik. Az OpenSSL egy mindenütt jelenlévő TLS könyvtár, amelyet az internetre csatlakozó eszközök nagy százalékában használnak. Sajnos C nyelven íródott, és hosszú története van a memóriabiztonsági sebezhetőségek terén.  Az internet biztonsága szempontjából fontos, hogy eltávolodjanak ezek az alaprendszerek a nem memóriabiztos TLS-könyvtáraktól. Nagyon valószínűtlen, hogy az OpenSSL projektet rávehetik arra, hogy elhagyja a C nyelvet, ezért egy memóriabiztos alternatíván dolgoznak a fejlesztőik. Rá kell vennünk az internet kritikus szoftver-infrastruktúráját, hogy áttérjen erre.  Szerencsére az OpenSSL-nek számos felhasználási esetre van egy kiváló alternatívája. A Rustls egy kiváló minőségű, Rust nyelven írt TLS implementáció lesz.

A Divvi Up csapat hatalmas előrelépést tett egy olyan új szolgáltatás megvalósításában, amely több millió ember számára biztosítja az adatvédelmet tiszteletben tartó mérőszámokat. Az alkalmazások mindenféle mérőszámot gyűjtenek: némelyikük érzékeny, némelyikük nem az, és némelyikük ártalmatlannak tűnik, de felfedhet magánjellegű információkat egy személyről. Újra lehetővé teszik, hogy az alkalmazások aggregált, anonimizált mérőszámokat kapjanak, amelyek népességszintű betekintést nyújtanak, miközben védik az alkalmazásokat használó emberek magánéletét. Mindenki nyer - a felhasználók nagyfokú adatvédelmet kapnak, az alkalmazások pedig az egyéni felhasználói adatok kezelése nélkül jutnak hozzá a szükséges mérőszámokhoz. A 2023-as év felé haladva tovább bővítik a bétatesztelők és partnerek körét.

Az ISRG ezt a felelősségtudatot ma úgy tudja a legjobban átültetni a cselekvésbe, hogy az agilitásra és a rugalmasságra összpontosít. 2020 márciusában a Let's Encryptnek egy olyan incidensre kellett reagálnia, amely közel hárommillió tanúsítványt érintett. Ez azt jelentette, hogy nagyon rövid időn belül rá kellett venniük a felhasználókat, hogy újítsák meg ezt a hárommillió tanúsítványt, különben a webhelyek elérhetőségi problémái lesznek. A rendelkezésre álló javítási lehetőségeket figyelembe véve elég jól kezelték ezt az incidenst, de egyértelmű volt, hogy a jövőben az ehhez hasonló események esetén a fokozatos fejlesztések nem jelentenek majd elegendő változást. Olyan rendszereket kellett bevezetniük, amelyek lehetővé teszik számukra, hogy a jövőben jelentősen rugalmasabbak és ellenállóbbak legyünk a hibákkal szemben. Azóta kidolgoztak egy specifikációt a tanúsítványmegújítási jelzések automatizálására, hogy előfizetők ugyanolyan egyszerűen tudják kezelni a visszavonási, illetve megújítási eseményeket, mint ahogyan a tanúsítványokat is megkapják.  Ez automatikusan történik a háttérben. Ez a specifikáció most halad át az IETF szabványosítási folyamatán, hogy az egész ökoszisztéma élvezhesse az előnyeit, és tervezik, hogy hamarosan a Let's Encryptnél is bevezetik. Más lépésekkel kombinálva, amelyeket a megújítási forgalmi hullámok könnyebb kezelése érdekében tettek, a Let's Encryptnek egészen más szinten kell tudnia reagálni, amikor legközelebb jelentős számú előfizetőt kell megkérniük a korai megújításra. Az ilyen jellegű, az agilitás és a rugalmasság érdekében végzett munka kritikus fontosságú, ha a biztonságot és az adatvédelmet a weben méretarányosan javítani akarják.

A 2022-es év nagy részében a webhely megbízhatósági mérnökeik és fejlesztőik egyik fő célja az volt, hogy javítsák a Let's Encrypt kezelését az Online Certificate Status Protocol (OCSP) válaszok gyorsítótárazása során. Az év elején az OCSP-forgalmuk 98-99%-át a CDN-jeik kezelték. De mi történik akkor, ha egy CDN-nek problémája van, aminek következtében a Let's Encryptnek kell átvennie a terhelés egy részét? Mivel a Let's Encrypt 300 millió tartományt szolgál ki, másodpercenként körülbelül 100 000 OCSP-kérést gyorsítótárba helyeztek. Történelmileg a Let's Encrypt ennek a forgalomnak körülbelül 6%-át tudta egyedül gyorsítótárba helyezni. De ha ennél sokkal nagyobb forgalmat tapasztalnának, a Let's Encrypt összeomlását kockáztatnák. Ez nem ideális helyzet sem kiszolgálói, sem az internet számára. A csapat drámaian javította az OCSP-válaszok kiszolgálásának képességét azzal, hogy a Redis-t memórián belüli gyorsítótárazási rétegként telepítette, amely segít megvédeni az adatbázisunkat. Az első teszt a válaszok 1/16-ának gyorsítótárba helyezése volt. Ez a kezdeti teszt másodpercenként 12 500 kérést kezelt. Az egymást követő tesztek 1/8-ad, majd 1/4-ad, majd 1/2-ad, végül 100%-ra emelkedtek. Összességében ez a javulás azt jelenti, hogy a Let's Encrypt ma megbízhatóbb, mint valaha volt, és hogy egy újabb észbontó statisztikát tudhatunk magunk mögött.

Amikor egy tanúsítvány megbízhatatlanná válik (például azért, mert a titkos kulcsát felfedték), a tanúsítványt vissza kell vonni, és ezt az információt nyilvánosságra kell hozni, hogy a jövőben senki ne hagyatkozhasson rá. A webes nyilvános kulcsú infrastruktúra (a webes PKI) világában azonban az a jól bevált mondás, hogy a visszavonás nem működik. A Web PKI története során két elsődleges mechanizmus létezett annak kijelentésére, hogy egy TLS/SSL-tanúsítvány nem megbízható többé: A tanúsítvány-visszavonási listák (CRL) és az OCSP. Sajnos mindkettőnek komoly hátrányai vannak. A CRL-ek alapvetően nem mások, mint egy adott tanúsítványkiadó (CA) által kiadott, de visszavont tanúsítványok listái. Ez azt jelenti, hogy gyakran nagyon nagyok - könnyen elérik egy egész film méretét. A böngésző számára nem hatékony a visszavont tanúsítványok óriási listájának letöltése, csak azért, hogy ellenőrizze, hogy az éppen meglátogatott webhely egyetlen tanúsítványát visszavonták-e. Ezek a lassú letöltések és ellenőrzések lassúvá tették a weboldalak betöltését, ezért alternatívaként kifejlesztették az OCSP-t. Az OCSP egyfajta "mi lenne, ha minden egyes tanúsítványhoz külön CRL lenne": amikor ellenőrizni szeretné, hogy egy adott tanúsítványt visszavontak-e, a böngésző a hitelesítésszolgáltató OCSP-szolgáltatásával kapcsolatba lépve ellenőrizheti az adott tanúsítvány állapotát. Mivel azonban az OCSP-infrastruktúrának folyamatosan működnie kell, és ugyanúgy szenvedhet leállástól, mint bármely más webes szolgáltatás, a legtöbb böngésző a válasz elmaradását egyenértékűnek tekinti a "nem visszavont" válasz megadásával. Ez azt jelenti, hogy a támadók megakadályozhatják, hogy megtudja, hogy egy tanúsítványt visszavontak, egyszerűen azzal, hogy blokkolják az OCSP-információkra irányuló összes kérést. A hitelesítésszolgáltatók OCSP-szolgáltatásainak terhelésének csökkentése érdekében az OCSP-válaszok érvényesek, és körülbelül egy hétig tárolhatók a gyorsítótárban. Ez azonban azt jelenti, hogy az ügyfelek nem nagyon gyakran kérik le a frissítéseket, és gyakran még egy héttel a visszavonás után is megbíznak a tanúsítványokban. És ami talán a legrosszabb: mivel a böngésző minden egyes meglátogatott webhelyhez OCSP-kérést küld, egy rosszindulatú (vagy jogilag kényszerített) hitelesítésszolgáltató nyomon követheti a böngészési szokásait, mivel nyomon követi, hogy milyen webhelyekhez kér OCSP-t.

Tehát mindkét létező megoldás nem igazán működik: A CRL-ek annyira nem hatékonyak, hogy a legtöbb böngésző nem ellenőrzi őket, az OCSP pedig annyira megbízhatatlan, hogy a legtöbb böngésző nem ellenőrzi.

Valami jobbra van az internetnek szüksége!

Böngésző-specifikus CRL-ek Az egyik lehetséges megoldás, amely az utóbbi időben egyre nagyobb teret nyer, a saját, böngésző-specifikus CRL-ek ötlete. Bár a különböző böngészők ezt különbözőképpen valósítják meg (pl. a Mozilla a sajátját CRLite-nek, a Chrome-ét pedig CRLSet-nek hívják), az alapötlet ugyanaz. Ahelyett, hogy minden felhasználó böngészője nagyméretű CRL-eket töltene le, amikor ellenőrizni szeretné a visszavonást, a böngészőgyártó központilag tölti le a CRL-eket. A CRL-eket egy kisebb formátumba, például Bloom-szűrőbe dolgozza fel, majd az új tömörített objektumot a már meglévő gyors frissítési mechanizmusok segítségével az összes telepített böngészőpéldányhoz eljuttatja. A Firefox például akár 6 óránként is küld frissítéseket. Ez azt jelenti, hogy a böngészők idő előtt letölthetik a visszavonási listákat, így az oldalbetöltés gyors marad, és a vanília CRL-ek legrosszabb problémái is enyhülnek. A visszavonási ellenőrzések helyi szinten maradnak, és a továbbított frissítések azonnal hatályba léphetnek anélkül, hogy megvárnák az OCSP cache potenciálisan napokig tartó lejáratát, így megelőzhetők az OCSP-vel kapcsolatos legrosszabb problémák. A böngésző által összefoglalt CRL-ek ígéretének köszönhetően mind az Apple, mind a Mozilla programja megköveteli, hogy minden hitelesítésszolgáltató 2022. október 1-je előtt kezdje meg a CRL-ek kiadását. Konkrétan megkövetelik, hogy a hitelesítésszolgáltatók kezdjenek el kiadni egy vagy több CRL-t, amelyek együttesen lefedik az adott hitelesítésszolgáltató által kiadott összes tanúsítványt, és hogy az ezekre a CRL-ekre mutató URL-ek listáját közzétegyék a közös hitelesítésszolgáltatói adatbázisban (CCADB). Ez lehetővé teszi, hogy a Safari és a Firefox átálljon a visszavonások a böngésző által összefoglalt CRL-ellenőrzésére.

Új infrastruktúra

A Let's Encrypt alapításakor kifejezetten cél volt, hogy csak az OCSP-t támogatás legyen, és egyáltalán nem készít CRL-eket. Ennek oka az volt, hogy az akkori program-követelmények csak az OCSP-t írták elő, és mindkét visszavonási mechanizmus fenntartása növelte volna azon helyek számát, ahol egy hiba megfelelőségi incidenshez vezethetett volna. Amikor nekiláttak a CRL-infrastruktúra fejlesztésének, a hatékonyságra és az egyszerűségre helyezték a hangsúlyt. Az elmúlt néhány hónapban kifejlesztettek néhány új infrastruktúraelemet, amelyek lehetővé teszik a CRL-ek közzétételét a közelgő követelményeknek megfelelően. Mindegyik komponens könnyű, egyetlen feladat elvégzésére és annak jó elvégzésére szolgál, és képes lesz a jelenlegi igényeinket jóval meghaladó méretezéshez. A Let's Encrypt jelenleg több mint 200 millió aktív tanúsítványt használ egy adott napon. Ha egy olyan incidensünk lenne, amikor egyszerre kellene visszavonni minden egyes tanúsítványt, a keletkező CRL több mint 8 gigabájtos lenne. Annak érdekében, hogy a dolgok kevésbé legyenek nehézkesek, a CRL-eket 128 részre osztják, amelyek mindegyike a legrosszabb esetben legfeljebb 70 megabájt lehet. Néhány gondosan felépített matematikai módszerrel biztosítják, hogy - amíg a részek száma nem változik - minden tanúsítvány ugyanazon a részen belül marad, amikor a CRL-eket újra kiállítják, így minden egyes rész egységes hatókörű mini-CRL-ként kezelhető. A tanúsítványok kibocsátása során követett bevált gyakorlatnak megfelelően minden CRL-t az RFC 5280 és az alapkövetelményeknek való megfelelés szempontjából ellenőrzik, mielőtt a kibocsátó közvetítőik aláírnák azokat.

Bár a népszerű zlint könyvtár még nem támogatja a CRL-ek ellenőrzését, mi megírták a saját ellenőrzési gyűjteményüket. A jövőben remélhetőleg ezeket a zlinthez is hozzá tudják majd kapcsolni. Ezek az ellenőrzések segítenek majd megelőzni a megfelelőségi incidenseket, és biztosítják a zökkenőmentes kibocsátási és megújítási ciklust. Ezen új képességek fejlesztésének részeként számos fejlesztést végeztek a Go szabványkönyvtár CRL generálásának és elemzésének implementációján is. A további fejlesztésekkel járulnak hozzá, ahogy a Go közösség többi tagja a jövőben egyre gyakrabban dolgozik a CRL-ekkel. Bár minden általuk kibocsátott tanúsítványra kiterjedő CRL-t fognak készíteni, ezeket az URL-eket nem fogjuk feltüntetni a tanúsítványaik CRL Distribution Point kiterjesztésében. Egyelőre, ahogyan azt az alapkövetelmények előírják, a tanúsítványaik továbbra is tartalmazni fognak egy OCSP URL-t, amelyet bárki használhat az egyes tanúsítványok visszavonási információinak lekérdezésére. Az új CRL URL-jeinket csak a CCADB-ben tesszük közzé, hogy az Apple és a Mozilla programjai anélkül használhassák azokat, hogy kitennék őket az internet többi részének potenciálisan nagy letöltési forgalmának.

A visszavonás jövője

Még hosszú út áll előttük, amíg a visszavonás a webes PKI-ban valóban megoldódik. Az OCSP-vel kapcsolatos adatvédelmi aggályok csak akkor fognak enyhülni, ha az összes ügyfelek már nem támaszkodnak rá, és még jó módszereket kell kidolgozni a nem böngésző-ügyfelek számára a visszavonási információk megbízható ellenőrzésére. Az Internet Security Research Group (ISRG) várja a további együttműködést a Web PKI közösség többi tagjával, hogy a visszavonás-ellenőrzést mindenki számára priváttá, megbízhatóvá és hatékonnyá tegyék.