Postkvante kræver OpenSSL 3.5 på jeres origin

Det første postkvantetrin, jeres CDN ikke tager for jer

En ingeniør, der åbner Cloudflares statusside om postkvantesikkerhed, har i tre år kunnet læse gode nyheder uden selv at gøre noget. På strækningen mellem en besøgendes browser og Cloudflares kant har den postkvantesikre kryptering været slået til som standard siden 2023, med den hybride nøgleudveksling, der i dag skrives X25519MLKEM768, og ingen kunde har sat den op. Den kom, som vejret kommer.

Den 29. juli holdt den arbejdsform op. Cloudflare annoncerede postkvantesikker godkendelse på den anden strækning, mellem sit net og de origin-servere, kunderne selv driver, med signaturer efter ML-DSA. Godkendelse er ikke noget, en proxy kan klare på jeres vegne, for det, der bliver bevist, er jeres server. For at bruge den skal serveren opbevare og fremvise et certifikat, der er signeret med en algoritme, den efter alt at dømme aldrig har set.

Hvad der faktisk blev leveret

To produkter bærer ændringen. Authenticated Origin Pulls er den mekanisme, hvormed Cloudflare fremviser et klientcertifikat over for jeres origin, så den kan afvise forbindelser, der ikke kom gennem Cloudflare, og den accepterer nu ML-DSA på konfigurationsniveauerne pr. zone og pr. værtsnavn. Det globale niveau er angivet som noget, der kommer senere. Custom Origin Trust Store, hvor en kunde kan lægge sine egne certifikatmyndigheder ind i stedet for at læne sig op ad det offentlige sæt, optager nu myndigheder, der signerer med ML-DSA, så et origin-certifikat kan valideres mod en postkvantesikker signerende part.

Alle tre parametersæt fra FIPS 204 understøttes: ML-DSA-44, ML-DSA-65 og ML-DSA-87. Forbindelsens nøgleudveksling er fortsat den hybride X25519MLKEM768. Fortroligheden på netop den strækning var altså allerede på plads, og det, der har ændret sig, er den del, der beviser, hvem der sidder i hver ende.

Fem ting, der skal laves om på en maskine, I selv ejer

Kravlisten er kort, og hvert punkt lander på jeres side af forbindelsen. På origin-serveren skal der køre OpenSSL 3.5.0 eller nyere, alene for at kunne fremstille en ML-DSA-certifikatkæde. Certifikatet skal lægges op i den frøbaserede kodning, som FIPS 204 fastlægger, og det er ikke den kodning, de fleste værktøjer leverer af vane. Webserveren på origin, i Cloudflares eget eksempel NGINX, skal sættes op til enten at fremvise ML-DSA-certifikatet eller at kontrollere klientcertifikatet imod det. Bruger I Custom Origin Trust Store, skal zonens SSL/TLS-tilstand stå på Full (strict). Og tilliden til den kvantesårbare mekanisme skal fjernes bagefter, for lader man den blive, kan en angriber forhandle sig frem til den gamle vej, og den nye bliver ren pynt.

Intet af det er eksotisk. OpenSSL 3.5.0 udkom den 8. april 2025 som en langtidsunderstøttet linje med opdateringer frem til april 2030 og var den første udgave, der havde NIST's tre postkvantestandarder indbygget. Vanskeligheden ligger ikke i versionsnummeret. Den ligger i, at origin ofte er den mindst besøgte maskine i hele serverparken: en boks, en kasse en leverandør passer, en virtuel maskine ingen har bygget om, siden den blev oprettet, eller en belastningsfordeler, hvis TLS-lag er en andens problem, indtil det ikke er det længere.

Cloudflares egen udrulning er argumentet for et testtrin. Den 10. juni 2026 fik selskabet en driftsfejl under netop denne udbredelse, udløst af kontrollen af KeyUsage-feltet i certifikaterne. Det er en detalje i en certifikatudvidelse, og den ramte et hold, der bygger TLS-biblioteker til dagligt, på infrastruktur, de styrer fra ende til anden. En mellemstor virksomhed, der laver den samme ændring en torsdag eftermiddag, bør regne med at finde noget tilsvarende.

Hvorfor det anbefalede parametersæt er det mindste

Cloudflare anbefaler ML-DSA-44 til de fleste anvendelser og kalder det den mest ydedygtige mulighed. Det er et forsvarligt teknisk valg, og det er samtidig det mindste af de tre sæt i FIPS 204, placeret i NIST-sikkerhedskategori 2. Den mere udbredte standardanbefaling andre steder er ML-DSA-65 i kategori 3. Postkvantesikre signaturer er store sammenlignet med dem, de afløser, og på en strækning, der bærer hver eneste forespørgsel mellem kant og origin, er størrelsesforskellen en reel udgift i svartid og båndbredde, ikke en teoretisk.

Det, der tæller for en ejerleder, er, at der her opstår en beslutning med jeres navn på. Har jeres sikkerhedspolitik eller jeres revisor allerede lagt sig fast på kategori 3 ved signering, skaber I en undtagelse, I senere skal forklare, hvis I stiltiende overtager anbefalingen fra jeres CDN. Skriv parametersættet og begrundelsen ned, før en anden opdager forskellen under et eftersyn.

Fristen, der er virkelig, og den, der ikke er

Vær præcis om, hvor meget det haster, for de to halvdele af postkvantesikkerheden løber virkelig efter hvert sit ur. Krypteret trafik, der optages i dag, kan afkodes af en fremtidig maskine, og det er netop dét, der gør nøgleudveksling til et problem i nutid. En signatur kan ikke forfalskes bagud på samme måde: ingen tager en kvantecomputer i brug i 2032 for med tilbagevirkende kraft at opdigte et håndtryk fra i morges. Grunden til at gå i gang nu er ikke, at I bliver angrebet, men længden af køen bag ændringen, som løber gennem certifikatmyndigheder, hardware, leverandørers kasser og hver eneste origin, I havde glemt.

Cloudflare har sat datoer på sin egen kø: fuld postkvantesikkerhed på tværs af produkterne i 2029 og en første udbredelse af Merkle Tree Certificates på besøgssiden med 2027 som mål. Det er selskabets frister, ikke jeres. Jeres er det næste eftersyn, der spørger, hvad der beskytter forbindelsen mellem jeres CDN og jeres servere, og i Danmark er det Center for Cybersikkerhed, der sætter pejlemærket. Det ærlige svar i dag lyder for næsten alle: klassisk kryptografi, med en understøttet afløser stående ubrugt ved siden af.

Læs videre: Flere transitudbydere betyder ikke, at du vælger vejen  |  Albaniens domæner forsvandt. Tysklands gjorde det i maj.