A Cloudflare bejelentette, hogy nyilvános hitelesítésszolgáltatóvá, angolul Certificate Authorityvé, röviden CA-vá kíván válni. A lépéssel tovább bővítené szerepét a web bizalmi infrastruktúrájában, miközben a technológiai szolgáltatók a kvantumszámítógépes támadásoknak ellenálló megoldásokra készülnek.
A vállalat szeptember 29-i közlése szerint a tervezett szolgáltatás hagyományos TLS-tanúsítványok mellett Merkle Tree Certificates, röviden MTC-k, vagyis Merkle-fa-alapú tanúsítványok kibocsátását is támogatná. Ez a kialakulóban lévő megközelítés úgy tenné lehetővé a weboldalak posztkvantum-hitelesítését, hogy elkerüli a hagyományos felépítésű, posztkvantum aláírásokat használó tanúsítványláncok jelentős adatforgalmi többletét.
A Cloudflare megállapodott a GlobalSignnal egy már működő, nyilvánosan megbízhatónak tekintett gyökér-CA kulcsanyagának átvételéről, és kérelmet nyújtott be a Chrome, az Apple, a Microsoft és a Mozilla gyökértanúsítvány-programjaiba.
A hagyományos tanúsítványok kibocsátása a megfelelő elfogadási folyamatot követően indulhat el. Az MTC-k éles kibocsátását a vállalat 2027 első negyedévére tervezi. A Cloudflare hivatalos bejelentése
A bejelentés a szolgáltatás kiépítésére és jóváhagyatására vonatkozó vállalás, nem annak megerősítése, hogy a Cloudflare már saját CA-ként bocsát ki nyilvánosan megbízható tanúsítványokat.
A kezdeményezés jelentősége túlmutat egy újabb tanúsítványszolgáltató megjelenésén: egy jelentős infrastruktúra-üzemeltető kapcsolódik be a böngészők bizalmi ellenőrzéseinek korszerűsítésébe.
Új szerep a weboldalak hitelesítésében
A Cloudflare már jelenleg is gondoskodik a szolgáltatásait használó weboldalak tanúsítványairól. Ezek nyilvánosan megbízható kibocsátójává válni azonban külön felelősséget jelent.
A vállalat dokumentációja a Universal SSL tanúsítványaihoz többek között a Let’s Encrypt, a Google Trust Services és az SSL.com szolgáltatókat sorolja fel partnerként. Ezek a kapcsolatok jól mutatják a különbséget a tanúsítványokat telepítő platform és az igényléseket ellenőrző, majd tanúsítványokat kibocsátó szervezet között.
A tanúsítványok egy weboldal azonosítóját kriptográfiai nyilvános kulcshoz kapcsolják. Biztonságos kapcsolat létrehozásakor ez segít a böngészőnek megállapítani, hogy valóban a kívánt végponttal kommunikál-e.
A kibocsátó ezért érzékeny bizalmi szerepet tölt be. Az igénylések ellenőrzésében, az aláírókulcsok védelmében vagy az incidenskezelésben elkövetett hibák az egyébként titkosított kapcsolatok megbízhatóságát is alááshatják.
A Cloudflare belépése újabb kibocsátóval bővítené ezt a rendszert. Az ebből származó ellenálló képesség azonban az üzemeltetés minőségétől és attól is függ, hogyan használják az ügyfelek az új lehetőséget. Egy alternatív kibocsátó akkor igazán hasznos, ha egy incidens során a szervezetek ténylegesen át tudnak állni rá, vagy gyorsan póttanúsítványokat tudnak beszerezni.
A kulcsegyeztetést és a hitelesítést eltérően fenyegetik a kvantumszámítógépek
A bejelentés egy olyan különbségre irányítja rá a figyelmet, amely a „kvantumbiztos” internetes szolgáltatásokról szóló kommunikációban gyakran elmosódik.
A kulcsegyeztetés létrehozza a kapcsolat védelméhez szükséges közös titkos értékeket. A hitelesítés annak igazolásában segít, hogy a másik végpont valóban az, akinek mutatja magát. Az egyik korszerűsítése nem jelenti automatikusan a másik korszerűsítését.
A Cloudflare posztkvantum-megoldásokról szóló dokumentációja is elkülöníti ezt a két képességet:
| Védelmi terület | Mit biztosít? | Milyen kvantumfenyegetésre ad választ? |
|---|---|---|
| Posztkvantum-kulcsegyeztetés | A kapcsolat titkosításához szükséges közös titok létrehozását | A ma rögzített titkosított forgalom későbbi visszafejtését nehezíti meg |
| Posztkvantum-hitelesítés | A kommunikáló végpont azonosságának ellenőrzését | A hitelesítés feltörését és a megbízható rendszer megszemélyesítését akadályozza egy kellően erős kvantumszámítógéppel szemben |
Ebből eltérő prioritások következnek. Az éveken át bizalmasan kezelendő információknál már egy kriptográfiailag releváns kvantumszámítógép megjelenése előtt is fennállhat az adatgyűjtés veszélye. A tanúsítványok hamisításával kapcsolatos fenyegetés akkor válik közvetlenné, amikor a szükséges számítási képesség ténylegesen rendelkezésre áll.
Egy posztkvantum-titkosítást hirdető szolgáltatás értékelésekor ezért pontosítani kell: melyik kapcsolat védett, milyen algoritmusokat használ, és a védelem a kulcsegyeztetésre, a hitelesítésre vagy mindkettőre kiterjed-e?
A szabványok már léteznek, a bevezetés továbbra is összetett
A kriptográfiai átállást már közzétett szabványok támogatják.
Az amerikai Nemzeti Szabványügyi és Technológiai Intézet, a NIST 2024 augusztusában három jelentős posztkvantum-kriptográfiai szabványt hagyott jóvá:
- a FIPS 203 az ML-KEM eljárást írja le közös titkok létrehozásához;
- a FIPS 204 az ML-DSA digitális aláírási eljárást határozza meg;
- a FIPS 205 az SLH-DSA digitális aláírási eljárást szabványosítja.
Ezek az algoritmusok eltérő célokat szolgálnak. Egy kulcsbeágyazási mechanizmus nem helyettesítheti egyszerűen a tanúsítvány hitelesítésére használt aláírást. A kapcsolat minden részéhez megfelelő megoldásra és egymással kompatibilis megvalósításokra van szükség.
A szabványosítás biztosítja a kriptográfiai építőelemeket, a nyilvános weben történő alkalmazásuk azonban további mérnöki munkát igényel. A böngészőknek, szervereknek, tanúsítványkibocsátóknak és támogató szoftvereknek meg kell állapodniuk abban, hogyan ábrázolják, továbbítják és ellenőrzik ezeket az elemeket.
Ezért jelentős egy új hitelesítésszolgáltató bejelentése akkor is, ha a posztkvantum-algoritmusok szabványai már elkészültek. A feladat része, hogy az erősebb kriptográfia a meglévő rendszerekben is praktikusan használható legyen.
Miért okoznak teljesítményproblémát a nagyobb aláírások?
A posztkvantum-hitelesítés egyik fő akadálya az adatok mérete.
A Let’s Encrypt átállási terve szerint egy ML-DSA-44 aláírás körülbelül 2420 bájt, szemben az összehasonlításban szereplő ECDSA-P256 aláírás 64 bájtos ábrázolásával. A nyilvános kulcsok szintén nagyobbak lesznek.
Ha egy tipikus webes TLS-kézfogás több aláírását és kulcsát ML-DSA-alapú megfelelőkre cserélik, a hitelesítési adatcsere mérete 10 kilobájt fölé is nőhet.
Ezeket az adatokat még a szokásos biztonságos kommunikáció megkezdése előtt továbbítani kell. A nagyobb adatcsere növelheti a kapcsolatfelépítés idejét, és különösen kedvezőtlen lehet korlátozott sávszélességű vagy megbízhatatlan hálózatokon. Internetes léptékben a kapcsolatonként kis többlet is jelentős terheléssé válhat.
A Let’s Encrypt szintén az MTC-k bevezetésén dolgozik: 2026 végére tesztkörnyezetet, 2027-re pedig éles használatra kész környezetet céloz meg. Tervei azt mutatják, hogy szélesebb iparági kezdeményezésről van szó, nem kizárólag Cloudflare-ügyfelek számára készülő saját tanúsítványformátumról. A Let’s Encrypt posztkvantum-tervei
Hogyan csökkentik az MTC-k a hitelesítés adatforgalmát?
A Merkle-fa-alapú tanúsítványok megváltoztatják a hitelesítési információk szervezését és továbbítását.
A megoldás alapját Merkle-fák adják. Ezek olyan kriptográfiai adatszerkezetek, amelyekkel ellenőrizhető, hogy egy konkrét bejegyzés egy nagyobb adathalmaz része-e, anélkül, hogy a teljes halmazt át kellene adni az ellenőrző félnek.
A rendszernek így nem kell minden kapcsolathoz hagyományos aláírásláncot továbbítania. Ehelyett használhat egy sok bejegyzést lefedő, aláírt faállapotot, valamint egy tömör bizonyítékot arra, hogy az adott tanúsítvány szerepel a fában.
Az előny abból származik, hogy a hitelesítési információk nagy mennyiségű tanúsítvány és kapcsolat között megoszthatók és újrafelhasználhatók. Bizonyos adatok külön is eljuttathatók a kliensekhez, így csökken az egyes TLS-kézfogások során a szerver által továbbítandó mennyiség. A Cloudflare korábbi MTC-magyarázata
Az MTC nem szünteti meg a megbízható kibocsátók vagy a biztonságos digitális aláírások szükségességét. A bizalom megállapításához használt bizonyítékok elosztását változtatja meg. A kibocsátónak továbbra is helyesen kell ellenőriznie az igényléseket, a kliensnek pedig elegendő hiteles információval kell rendelkeznie a bizonyíték ellenőrzéséhez.
A Chrome-kísérlet előrelépést mutat, de nem kész éles rendszert
A Cloudflare új technikai beszámolója szerint a kísérlet során milliárdos nagyságrendben szolgáltak ki MTC-ket a Chrome Beta felhasználóinak egy kiválasztott körénél.
A teszt hagyományos tanúsítványláncokra támaszkodó kísérleti kibocsátási rendszert használt. Nem abból indult ki, hogy a Cloudflare már önállóan megbízhatónak elfogadott, éles hitelesítésszolgáltató.
A vállalat szerint a hatékony, korábban hitelesített referenciaponthoz – úgynevezett landmarkhoz – viszonyított megoldás a TLS-kézfogásban egy nyilvános kulcsot, egy aláírást és egy egy kilobájtnál kisebb befoglalási bizonyítékot igényelt. Ha ezt a formátumot a felek nem tudták használni, a kísérlet hagyományos tanúsítványláncra váltott vissza.
Ez a különbség az eredmények értelmezésénél is fontos. Egy nagy léptékű megvalósíthatósági teszt értékes bizonyíték arra, hogy a megoldás valós forgalomban működhet, de nem igazolja, hogy a későbbi éles ökoszisztéma minden eleme elkészült.
A Cloudflare közlése szerint a szokásos MTC-kibocsátás ingyenes lesz. A vállalat nyitott kérdéseket is megnevezett: például azt, hogy a független megfigyelőrendszerek képesek lesznek-e lépést tartani az éles naplókkal, és részt vesz-e elegendő kibocsátó, illetve támogató üzemeltető a megfelelő ellenálló képesség biztosításához. A Cloudflare technikai beszámolója
Az átláthatóság a tanúsítványkibocsátás részévé válik
Az IETF PLANTS munkacsoportja olyan mechanizmusokat fejleszt, amelyek a tanúsítványkibocsátást és az átláthatósági naplózást szorosabban összekapcsolják.
A jelenlegi modellben a hitelesítésszolgáltatók és a Certificate Transparency, vagyis CT-naplók külön feladatot látnak el, a kliensek pedig mindkét rendszerből kapnak bizonyítékokat. A nagyobb posztkvantum-aláírások ezekben a rendszerekben összeadódó többletet okozhatnak.
A PLANTS célja a kézfogás során továbbított adatok és a naplóbejegyzések költségének csökkentése, a nyilvános ellenőrizhetőség megőrzése mellett. Munkája kiterjed a tanúsítványok felépítésére, rendelkezésre bocsátására és TLS-en belüli használatára is.
A munkacsoport két, egymással együttműködő megvalósítást ír elő, mielőtt a specifikációkat közzétételi jóváhagyásra az Internet Engineering Steering Group elé terjesztené. Az IETF PLANTS munkacsoportjának feladatai
A biztonsági csapatok számára az átláthatóság ugyanolyan fontos, mint a kisebb sávszélességigény. A nyilvánosan vizsgálható kibocsátás lehetővé teszi a gyanús tanúsítványok keresését és a váratlan események kivizsgálását.
Az átláthatóság és a helyes ellenőrzés azonban külön tulajdonság. Attól, hogy egy kibocsátás láthatóvá válik, még nem bizonyított, hogy az igénylés jogos volt. A működő rendszerhez továbbra is monitorozás, kivizsgálás, valamint a hibák és kompromittálódások kezelésére alkalmas eljárások szükségesek.
A böngészők támogatása meghatározza a bevezetés ütemét
A Google 2026 februárjában közzétett, kvantumálló HTTPS-re vonatkozó ütemterve az MTC-ket jelölte meg a Chrome számára a nyilvánosan megbízható posztkvantum-tanúsítványokhoz vezető tervezett útként.
A Google akkor azt közölte, hogy nincs közvetlen terve posztkvantum-kriptográfiát tartalmazó, hagyományos X.509 tanúsítványok felvételére a meglévő Chrome Root Store-ba. Ehelyett egy külön Chrome Quantum-resistant Root Store kialakítását és fokozatos bevezetést vázolt fel.
A közzétett menetrend 2027 első negyedévére irányozza elő a nyilvános MTC-rendszer kezdeti kiépítését. A harmadik negyedévre tervezett szakasz további hitelesítésszolgáltatók bevonásával és választható visszaminősítés elleni védelemmel foglalkozik. A Google februári biztonsági bejelentései
A visszaminősítés elleni védelem azért fontos, mert egy erősebb tanúsítvány támogatása önmagában nem feltétlenül akadályozza meg, hogy a támadó egy gyengébb, de továbbra is elfogadott alternatíva felé terelje a kapcsolatot.
Az ütemterv a Chrome-ra vonatkozik. Nem tekinthető minden böngészőre, operációs rendszerre vagy vállalati alkalmazásra érvényes közös határidőnek. A kompatibilitás a kapcsolat mindkét végén működő szoftvertől és az elfogadott tanúsítványokra vonatkozó szabályoktól függ.
A régi eszközökhöz külön kompatibilitási megoldás szükséges
A GlobalSignnal tervezett tranzakció azoknak az eszközöknek az elérését segítheti, amelyek már nem kapnak frissítéseket a megbízható gyökértanúsítványaik listájához. A Cloudflare a szokásos zárási feltételek teljesülése mellett két hónapon belül számít az ügylet lezárására.
Egy régóta elfogadott gyökértanúsítvány segíthet abban, hogy a meglévő szoftverek felismerjék a hagyományos tanúsítványokat. Önmagában azonban nem tesz képessé egy régi böngészőt új algoritmusok vagy tanúsítványformátumok értelmezésére.
A gyakorlatban ezért együttélési időszakra kell számítani. A weboldalak üzemeltetőinek az arra képes kliensek számára erősebb hitelesítést kell biztosítaniuk, miközben másoknál megőrzik a megfelelő kompatibilitást. Egy ismert bizalmi kiindulópont és a kvantumálló hitelesítés eltérő problémát old meg.
Az automatizált megújítás az incidenskezelést is támogatja
A Cloudflare műszaki tervei ACME-központú szolgáltatást írnak le, és előírják, hogy a kliensek támogassák az ACME Renewal Information, röviden ARI megoldást.
A tervek között reprodukálható aláírószoftver-buildfolyamatok, hardveres biztonsági modulokhoz kapcsolódó hiteles igazolások és nyilvános üzemeltetési állapotfelület is szerepel. A Cloudflare hitelesítésszolgáltatói tervei
A cél, hogy a tanúsítványcsere rendszeres, összehangolt folyamattá váljon, és ne kézi beavatkozást igénylő vészhelyzet legyen.
Az RFC 9773 határozza meg, hogyan jelezhetik a hitelesítésszolgáltatók az ARI segítségével a javasolt megújítási időablakokat. Ezek szükség esetén korábbra hozhatók, a megújítási kérések pedig időben eloszthatók, elkerülve a hirtelen terhelési csúcsokat. Az ARI szabványa: RFC 9773
A rendszergazdák számára ez mérsékelheti a tanúsítvány-visszavonásokkal járó fennakadásokat. A tanúsítvány lecserélhető, mielőtt használhatatlanná válna, feltéve, hogy a kliens megkapja a jelzést, és végrehajtja a szükséges feladatokat.
A szabvány nem garantál kiesésmentes működést. A megújítószoftvernek működőképesnek kell maradnia, a hibákat kezelni kell, az új tanúsítványnak pedig el kell jutnia ahhoz a szolgáltatáshoz, amely azt bemutatja. Az automatizálás ezért monitorozást és tesztelést is igényel, nem csupán egyszeri beállítást.
A vállalati átállás túlmutat a böngészőn
A Cloudflare már bevezetett posztkvantum-hitelesítést a saját hálózata és az ügyfelek eredeti kiszolgálói, az úgynevezett origin szerverek közötti kapcsolatok egy részénél.
A vállalat júliusi műszaki közleménye az Authenticated Origin Pulls és a Custom Origin Trust Store ML-DSA-támogatását ismertette. Ezek olyan környezetben működnek, ahol a Cloudflare és ügyfelei a nyilvános böngészős ökoszisztémánál szorosabban szabályozott bizalmi kapcsolatot alakíthatnak ki.
Ez jól mutatja, miért haladhat eltérő sebességgel az átállás ugyanazon alkalmazás különböző kapcsolati szakaszain. A böngésző és a Cloudflare hálózati pereme, illetve a hálózati perem és az origin szerver közötti kapcsolat eltérő szoftveres, bizalmi és kompatibilitási követelményekkel működik.
A felkészültség értékelésekor ezért a teljes kapcsolati útvonalat kell vizsgálni. Egyetlen szakasz posztkvantum-védelme nem jelent automatikusan azonos védelmet minden más szakaszon.
A következő mérce a megbízható éles működés lesz
A Cloudflare 2029-re célozza a teljes posztkvantum-védelem elérését, a hitelesítést is beleértve. Ez a vállalat átállási célja, nem igazolt határidő egy olyan kvantumszámítógép megjelenésére, amely képes feltörni a jelenlegi nyilvános kulcsú kriptográfiát.
A vállalat ütemterve azt javasolja a szervezeteknek, hogy a posztkvantum-támogatást építsék be a beszerzési követelményekbe, tartsák naprakészen szoftvereiket, és automatizálják a tanúsítványok kibocsátását.
A biztonsági vezetők számára a közvetlen tervezési kérdés az, hogy szervezetük képes-e kriptográfiai megoldásokat váltani és tanúsítványokat cserélni a szolgáltatások rendelkezésre állásának megőrzésével. A pontos nyilvántartás, az egyértelmű felelősségi körök és a tesztelt megújítási folyamatok kezelhetőbbé teszik az átállást.
A Cloudflare tervezett hitelesítésszolgáltatója újabb lehetséges utat kínál ehhez. A meghatározó mérföldkövek a jóváhagyott bizalmi keretek, az együttműködő megvalósítások, az éles tanúsítványkibocsátás és a valós klienseken, hálózatokon is megbízható működés lesznek. A bejelentés előrelépést jelent a felkészülésben; a széles körű védelem ezek együttes működésétől függ.
Az eredeti angol cikk címe: Cloudflare Announces Public Certificate Authority For The Post-Quantum Web.
