Det första postkvantsteget som ert CDN inte tar åt er
En ingenjör som öppnar Cloudflares statussida om postkvantsäkerhet har i tre år kunnat läsa goda nyheter utan att göra någonting. På sträckan mellan en besökares webbläsare och Cloudflares kant har den postkvantsäkra krypteringen varit påslagen som standard sedan 2023, med den hybrida nyckelutväxling som i dag skrivs X25519MLKEM768, och ingen kund har konfigurerat den. Den kom så som vädret kommer.
Den 29 juli upphörde den arbetsformen. Cloudflare tillkännagav postkvantsäker autentisering på den andra sträckan, mellan sitt nät och de origin-servrar kunderna själva driver, med signaturer enligt ML-DSA. Autentisering är inget som en proxy kan sköta åt er, eftersom det som styrks är er server. För att använda den måste den servern förvara och visa upp ett certifikat signerat med en algoritm som den sannolikt aldrig har sett.
Vad som faktiskt levererades
Två produkter bär förändringen. Authenticated Origin Pulls är den mekanism genom vilken Cloudflare visar upp ett klientcertifikat för er origin, så att den kan avvisa anslutningar som inte kom via Cloudflare, och den godtar nu ML-DSA på konfigurationsnivåerna per zon och per värdnamn. Den globala nivån anges komma senare. Custom Origin Trust Store, där en kund kan lägga in egna certifikatutfärdare i stället för att luta sig mot den publika uppsättningen, tar nu emot utfärdare som signerar med ML-DSA, så att ett origin-certifikat kan valideras mot en postkvantsäker signerare.
Samtliga tre parameteruppsättningar ur FIPS 204 stöds: ML-DSA-44, ML-DSA-65 och ML-DSA-87. Anslutningens nyckelutväxling förblir den hybrida X25519MLKEM768. Med andra ord var sekretessen på den sträckan redan löst, och det som ändrats är den del som styrker vem som sitter i vardera änden.
Fem saker som måste ändras på en maskin ni själva äger
Kravlistan är kort och varje punkt landar på er sida av anslutningen. På origin behövs OpenSSL 3.5.0 eller senare enbart för att över huvud taget kunna framställa en ML-DSA-certifikatkedja. Certifikatet ska laddas upp i den fröbaserade kodning som FIPS 204 fastställer, vilken inte är den kodning de flesta verktyg levererar av gammal vana. Webbservern på origin, i Cloudflares eget exempel NGINX, måste ställas in att antingen visa upp ML-DSA-certifikatet eller kontrollera klientcertifikatet mot det. Använder ni Custom Origin Trust Store ska zonens SSL/TLS-läge stå på Full (strict). Och förtroendet för den kvantsårbara mekanismen måste tas bort efteråt, för låter man den stå kvar kan en angripare förhandla fram den gamla vägen, och den nya blir ren prydnad.
Inget av detta är udda. OpenSSL 3.5.0 kom den 8 april 2025 som en linje med långt stöd och uppdateringar fram till april 2030, och var den första utgåvan som bar NIST:s tre postkvantstandarder inbyggda. Svårigheten sitter inte i versionsnumret. Den sitter i att origin ofta är den minst besökta maskinen i hela serverparken: en apparat, en låda som en leverantör sköter, en virtuell maskin som ingen byggt om sedan den skapades, eller en lastdelare vars TLS-lager är någon annans problem tills det inte längre är det.
Cloudflares egen utrullning är argumentet för ett teststeg. Den 10 juni 2026 fick bolaget ett produktionsfel under just denna spridning, orsakat av kontrollen av KeyUsage-fältet i certifikaten. Det är en detalj i en certifikatutökning, och den träffade ett lag som bygger TLS-bibliotek på heltid, på infrastruktur de styr från ände till ände. Ett medelstort företag som gör samma ändring en torsdagseftermiddag bör räkna med att hitta något liknande.
Varför den rekommenderade uppsättningen är den minsta
Cloudflare rekommenderar ML-DSA-44 för de flesta tillämpningar och beskriver den som det mest prestandavänliga alternativet. Det är ett försvarbart tekniskt val, och det är samtidigt den minsta av de tre uppsättningarna i FIPS 204, placerad i NIST:s säkerhetskategori 2. Den vanligare standardrekommendationen på andra håll är ML-DSA-65, kategori 3. Postkvantsäkra signaturer är stora jämfört med dem de ersätter, och på en sträcka som bär varje enskild begäran mellan kant och origin är storleksskillnaden en verklig kostnad i svarstid och bandbredd, inte en teoretisk.
Det som räknas för en ägare är att här uppstår ett beslut med ert namn på. Har er säkerhetspolicy eller er revisor redan fastnat för kategori 3 vid signering skapar ni ett undantag som måste förklaras senare om ni tyst övertar CDN-leverantörens rekommendation. Skriv ned parameteruppsättningen och skälet innan någon annan upptäcker skillnaden vid en genomgång.
Tidsfristen som är verklig och den som inte är det
Var tydliga med hur bråttom det är, för postkvantsäkerhetens två halvor går verkligen efter olika klockor. Krypterad trafik som spelas in i dag kan avkodas av en framtida maskin, och det är just det som gör nyckelutväxling till ett problem i nutid. En signatur går inte att förfalska bakåt på samma vis: ingen tar en kvantdator i anspråk 2032 för att i efterhand dikta upp en handskakning från i morse. Skälet att börja nu är inte att ni är under angrepp, utan längden på kön bakom ändringen, som löper genom certifikatutfärdare, hårdvara, leverantörers apparater och varje origin ni hade glömt bort.
Cloudflare har satt datum på sin egen kö: full postkvantsäkerhet över produkterna till 2029, och en första spridning av Merkle Tree Certificates på besökssidan med 2027 som mål. Det är bolagets tidsfrister, inte era. Er är nästa granskning som frågar vad som skyddar förbindelsen mellan ert CDN och era servrar, och i Sverige är det Myndigheten för samhällsskydd och beredskap som anger riktningen. Det ärliga svaret i dag lyder för nästan alla: klassisk kryptografi, med en stödd efterträdare stående oanvänd bredvid.
Läs vidare: Flera transitleverantörer betyder inte att du väljer vägen | Albaniens domäner slocknade. Tysklands gjorde det i maj.



