Een PQC downgrade attack, ook wel TLS rollback aanval genoemd, is een actieve aanval waarbij een tegenstander de TLS-handshake manipuleert zodat een verbinding terugvalt op klassieke, kwantumkwetsbare cryptografie, zelfs als beide communicerende partijen post-quantum algoritmen ondersteunen. Dit type aanval is geen theoretische curiositeit: het is de meest directe aanvalsvector tijdens de lopende hybride overgangsperiode naar post-quantum cryptografie (PQC), en het raakt organisaties die zichzelf als soeverein en veilig beschouwen precies op het moment dat ze denken te moderniseren.
Waarom de hybride overgangsperiode een specifiek aanvalsvenster opent
Zolang servers zowel klassieke als PQC-algoritmen accepteren om backward compatibility te garanderen, bestaat er een aanvalsoppervlak dat niet bestaat in een volledig klassieke of volledig post-quantum omgeving.
De dreiging achter PQC-migratie is concreet. Tegenstanders passen de strategie “harvest now, decrypt later” toe: zij onderscheppen vandaag versleuteld TLS-verkeer en bewaren dat totdat een voldoende krachtige quantumcomputer beschikbaar is om de klassieke sleuteluitwisseling te breken. NIST-wiskundige en PQC-projectleider Dustin Moody formuleerde dit als volgt:
“Harvest now, decrypt later is not a theoretical threat. Organizations that do not begin their cryptographic migration today are accepting future liability today.”
Volgens een enquête van het Global Risk Institute uit 2023 schatten experts de kans dat een relevante quantumcomputer RSA-2048 binnen tien jaar kan breken op gemiddeld 17 procent. Dat lijkt bescheiden, maar voor sectoren als defensie, rechtspraak en financiën is zelfs een kans van een paar procent over een periode van tien jaar onacceptabel als het om vertrouwelijke gegevens gaat.
Een downgrade aanval hoeft de quantumdrempel helemaal niet te overschrijden. De aanvaller forceert simpelweg dat de TLS-sessie via ECDH of RSA verloopt in plaats van via ML-KEM (FIPS 203). Daarmee is al het onderschepte verkeer direct bruikbaar zodra quantumcapaciteit beschikbaar komt, en de verbinding heeft op het moment van onderschepping ook al alle bescherming verloren die PQC zou bieden.
IETF draft-sheffer-tls-pqc-continuity-02: het mechanisme
Het IETF-document draft-sheffer-tls-pqc-continuity-02 introduceert een TLS-extensie die servers in staat stelt aan clients te verklaren dat toekomstige verbindingen naar hetzelfde domein uitsluitend via PQC-authenticatie mogen verlopen.
Het mechanisme werkt als volgt. Tijdens een succesvolle TLS-handshake waarbij de server een PQC-certificaat gebruikt (op basis van ML-DSA conform FIPS 204), voegt de server een PQC Continuity-extensie toe aan het ServerHello-bericht. Daarin staan het maximale aantal seconden dat de policy geldig blijft en een indicatie van welke PQC-algoritmen de server ondersteunt. De client slaat deze verklaring op, vergelijkbaar met hoe browsers een HSTS-header opslaan, en weigert bij een volgende verbinding naar hetzelfde domein elke handshake waarbij de server een klassiek certificaat aanbiedt.
Yaron Sheffer, auteur van het draft en actief IETF-contributor, omschrijft het concept als volgt:
“The PQC Continuity mechanism is analogous to HSTS: once a server has committed to post-quantum authentication, clients can enforce that commitment on subsequent connections.”
Het draft wordt besproken binnen de IETF LAMPS werkgroep (Limited Additional Mechanisms for PKIX and SMIME), die ook de bredere post-quantum certificaatprofielen voor gebruik in PKI uitwerkt. De extensie is bewust ontworpen als opt-in: een server die de extensie niet verstuurt, valt buiten de scope van de policy, zodat legacy-servers geen problemen ondervinden.
PQC Continuity versus HSTS: overeenkomsten en operationele verschillen
PQC Continuity en HSTS delen dezelfde “trust on first use”-logica, maar opereren op een ander beschermingsniveau.
| Kenmerk | HSTS | PQC Continuity |
|---|---|---|
| Wat het afdwingt | Gebruik van HTTPS in plaats van HTTP | Gebruik van PQC-authenticatie binnen HTTPS |
| Transportlaag | HTTP-responseheader | TLS-extensie in ServerHello |
| Opslaglocatie client | Browser HSTS-store | TLS-clientcache (implementatie-afhankelijk) |
| Max-age instelling | Ja, in seconden | Ja, in seconden |
| Preload-lijst mogelijk | Ja (browsers) | Nog niet gestandaardiseerd |
| Eerste verbinding beschermd? | Nee (tenzij preloaded) | Nee (tenzij preloaded) |
De operationele implicatie is dat de eerste verbinding naar een server altijd kwetsbaar blijft voor een downgrade, precies zoals bij HSTS. Organisaties die hoge zekerheid nodig hebben, moeten aanvullend een preload-mechanisme of pinning overwegen voor kritieke interne endpoints. Voor externe clientcommunicatie, zoals burgerportalen of API-koppelingen met ketenpartners, is een gefaseerde uitrol met monitoring op gebruikte ciphersuites de praktische route.
PKI-inrichting: backward compatibility en PQC-afdwinging combineren
De kern van de uitdaging zit in certificaatbeheer. FIPS 204 (ML-DSA / CRYSTALS-Dilithium) definieert de handtekeningalgoritmen voor PQC-certificaten, maar het overgrote deel van de bestaande PKI-infrastructuur is gebouwd op RSA en ECDSA.
De praktisch werkende tussenstap is het gebruik van hybride certificaten: certificaten die zowel een klassieke handtekening (ECDSA P-256 of RSA-2048) als een ML-DSA-handtekening bevatten. Een PQC-capabele client valideert de ML-DSA-handtekening; een legacy-client valideert de klassieke handtekening. De IETF LAMPS werkgroep werkt aan gestandaardiseerde profielen voor deze hybride certificaten, waardoor interoperabiliteit tussen implementaties gewaarborgd wordt.
OpenSSL 3.5, uitgebracht in april 2025, is de eerste OpenSSL-release met ingebouwde ondersteuning voor ML-KEM (FIPS 203) en ML-DSA (FIPS 204). Dit verlaagt de drempel voor serverbeheerders aanzienlijk: applicaties die op OpenSSL 3.5 draaien kunnen hybride handshakes uitvoeren zonder externe bibliotheken of patches. NIST heeft in augustus 2024 drie post-quantum standaarden gepubliceerd, waaronder FIPS 203 en FIPS 204, als eerste definitieve PQC-normen, wat de basis legt voor brede adoptie.
Voor de inrichting van de certificaatautoriteit (CA) zelf geldt: de root CA moet zo vroeg mogelijk een ML-DSA-sleutel krijgen. Intermediaire CA’s kunnen in de overgangsperiode hybride zijn. Leaf-certificaten voor eindgebruikers en servers volgen als laatste, zodra het clientlandschap PQC-ready is.
Legacy-systemen als structurele hindernis
De grootste praktische blokkade voor het uitfaseren van klassieke certificaten is niet de serverinfrastructuur, maar het clientlandschap. Embedded systemen, OT-apparatuur, IoT-sensoren en oudere mobiele applicaties gebruiken TLS-stacks die ML-DSA en ML-KEM niet kennen en die ook niet via een softwareupdate zijn bij te werken.
Specifieke risicogroepen zijn: SCADA-systemen en industriële controllers met vaste firmwareversies, legacy-ERP-clients met hard-coded certificaatvalidatielogica, oudere Java-runtimes zonder PQC-provider, en API-koppelingen met ketenpartners die hun eigen certificaatbeleid voeren. Voor overheidsorganisaties komen daar nog koppelingen met e-overheidsplatforms bij die eigen PKI-standaarden hanteren.
De beheersstrategie is drieledig. Ten eerste: inventariseer welk percentage van uw inkomende TLS-verbindingen per endpoint PQC-capabele ciphersuites onderhandelt. Dit is meetbaar via TLS-inspectie in uw firewall of loadbalancer. Ten tweede: stel per legacy-systeem een technische levensduur vast en koppel die aan een harde uitfaserdatum voor klassieke certificaten op het bijbehorende endpoint. Ten derde: isoleer legacy-clients op aparte netwerkzones met eigen endpoints, zodat u op de hoofdinfrastructuur sneller PQC Continuity kunt activeren zonder de legacy-uitzonderingen mee te slepen.
Risico’s voor soevereine on-premise infrastructuur bij gemengde TLS-endpoints
Organisaties die kiezen voor soevereine on-premise opslag, bijvoorbeeld als alternatief voor Amerikaanse clouddiensten waarvoor de CLOUD Act en de Patriot Act extraterritoriale toegang mogelijk maken, lopen een specifiek risico als hun externe TLS-endpoints nog klassieke certificaten accepteren.
De redenering is: data die intern op kwantumveilige opslag staat, maar via een klassiek TLS-endpoint naar buiten communiceert, is kwetsbaar voor “harvest now, decrypt later”. De soevereiniteit van de opslaglocatie biedt dan geen werkelijke bescherming voor de data in transit. Dit geldt voor API-koppelingen met externe partijen, voor remote-access-oplossingen van medewerkers, en voor e-mailgateways die TLS-verbindingen opzetten naar externe mailservers.
Voor organisaties die NIS-2-verplichtingen hebben, zoals aanbieders van essentiële diensten en overheidsinstanties, geldt artikel 21 van de NIS-2-richtlijn als relevante grondslag: technische beveiligingsmaatregelen moeten in verhouding staan tot de risico’s. Het niet adresseren van een bekende, gestandaardiseerde aanvalsvector als de PQC downgrade attack terwijl er een IETF-mechanisme beschikbaar is, kan worden uitgelegd als een lacune in de risicobeheersing.
Praktisch betekent dit dat de cryptografische migratie niet alleen interne systemen betreft. Elke TLS-terminatiepunt, inclusief reverse proxies, loadbalancers, VPN-gateways en e-mailrelays, moet in scope zijn van de PQC-migratieplanning. Soevereiniteit is een eigenschap van het gehele communicatiepad, niet alleen van de opslaglaag.
FAQ
Wat is precies een PQC downgrade attack en verschilt dit van een klassieke SSL-stripping aanval?
Bij een PQC downgrade attack manipuleert een aanvaller de TLS-handshake zodanig dat client en server overeenkomen een klassiek, kwantumkwetsbaar algoritme te gebruiken, ook als beide partijen PQC ondersteunen. Een SSL-stripping aanval verwijdert HTTPS volledig. Een PQC downgrade laat de versleuteling intact maar maakt haar toekomstbestendigheid ongedaan, wat de aanval lastiger te detecteren maakt.
Hoe werkt het PQC Continuity mechanisme in de praktijk?
De server stuurt tijdens een eerste TLS-verbinding een PQC Continuity-extensie mee waarin staat dat toekomstige verbindingen naar hetzelfde domein uitsluitend met PQC-authenticatie mogen verlopen. De client slaat dit op, vergelijkbaar met een HSTS-header, en weigert vervolgens verbindingen waarbij de server terugvalt op klassieke certificaten. Het mechanisme is gedefinieerd in IETF draft-sheffer-tls-pqc-continuity-02.
Welke algoritmen zijn nu relevant voor TLS-servers die willen beginnen met PQC?
Voor sleuteluitwisseling is ML-KEM (FIPS 203, ook bekend als CRYSTALS-Kyber) de aangewezen standaard. Voor digitale handtekeningen op certificaten geldt ML-DSA (FIPS 204, ook bekend als CRYSTALS-Dilithium). OpenSSL 3.5 ondersteunt beide algoritmen, wat implementatie in bestaande webservers aanzienlijk vereenvoudigt zonder afhankelijkheid van externe bibliotheken.
Wat moeten compliance officers in gereguleerde sectoren nu concreet doen?
Begin met een cryptografische inventarisatie van alle TLS-endpoints, certificaten en PKI-componenten. Identificeer welke systemen FIPS 203 en FIPS 204 nog niet ondersteunen. Stel een migratieplanning op met hybride certificaten als tussenstap, en zorg dat het beleid aansluit bij NIS-2-verplichtingen rond technische beveiligingsmaatregelen conform artikel 21 van de NIS-2-richtlijn.
Zijn legacy-clients die geen PQC ondersteunen een reden om PQC Continuity uit te stellen?
Nee, maar ze vereisen een gefaseerde aanpak. Gebruik in de overgangsperiode hybride certificaten die zowel een klassieke als een PQC-handtekening bevatten. Activeer PQC Continuity pas nadat u hebt vastgesteld dat een acceptabel percentage van uw clientbasis PQC-capabele TLS-stacks gebruikt. Isoleer legacy-endpoints in aparte zones en stel harde uitfaserdata vast per systeem.
