The protocol handles the handshake, but cipher suites decide what actually gets encrypted and how strong it is. Wrong choices leave data readable by design, and downgrade attacks undo every other precaution we take. Het protocol voert de handshake uit, maar ciphersuites bepalen wat echt wordt versleuteld en hoe sterk dat is. Verkeerde keuzes laten data per ontwerp leesbaar, en downgrade-aanvallen maken elke andere voorzorgsmaatregel ongedaan.
The public website scores well: TLS 1.3 and only AEAD ciphers. Behind it, the picture differs. A partner API, a payment terminal or a TLS-inspection box still offers TLS 1.0 and 3DES "for compatibility". Browsers dropped RC4 in 2016 and TLS 1.0/1.1 in 2020, so they never notice. Old clients, IoT devices and custom integrations do. An attacker who records a long 3DES session can recover secrets such as cookies (Sweet32, 2016), and CBC suites have a long history of padding attacks. Often nobody knows these are still on: the last scan was months ago, and the fix reached staging but not production.
Business impact: an attacker on the network path (a hacked router, a rogue Wi-Fi hotspot, a hijacked route) can attack these weak connections without touching client or server. The padlock looks the same. Weak cryptography is a common audit finding, and PCI DSS 4.0.1 asks for a yearly-reviewed inventory of the cipher suites and protocols in use.
De publieke website scoort goed: TLS 1.3 en alleen AEAD-ciphers. Daarachter ziet het er anders uit. Een partner-API, een betaalterminal of een TLS-inspectiebox biedt nog TLS 1.0 en 3DES aan "voor compatibiliteit". Browsers lieten RC4 in 2016 vallen en TLS 1.0/1.1 in 2020, dus die merken er niets van. Oude clients, IoT-apparaten en maatwerkkoppelingen wel. Wie een lange 3DES-sessie opneemt, kan geheimen zoals cookies terughalen (Sweet32, 2016), en CBC-suites hebben een lange geschiedenis van padding-aanvallen. Vaak weet niemand dat dit nog aan staat: de laatste scan is maanden oud, en de fix ging wel naar staging maar niet naar productie.
Bedrijfsimpact: een aanvaller op het netwerkpad (een gehackte router, een vals wifi-hotspot, een gekaapte route) kan deze zwakke verbindingen aanvallen zonder client of server aan te raken. Het hangslot ziet er hetzelfde uit. Zwakke cryptografie is een veelvoorkomende auditbevinding, en PCI DSS 4.0.1 vraagt om een jaarlijks herziene inventaris van de ciphersuites en protocollen in gebruik.
AI does not make 3DES or CBC suites any weaker than they already are; the attacks on them were published years before AI tools existed. The exposure comes from a configuration nobody disabled, not smarter attackers.AI maakt 3DES- of CBC-suites niet zwakker dan ze al waren; de aanvallen erop werden jaren vóór AI-tools gepubliceerd. De blootstelling komt door een configuratie die niemand uitschakelde, niet door slimmere aanvallers.
Asked to fix a connection problem, an AI assistant will often reproduce an old configuration snippet that re-enables legacy ciphers for compatibility, quietly undoing a hardening effort a previous team already completed.Gevraagd om een verbindingsprobleem op te lossen, geeft een AI-assistent vaak een oud configuratiefragment dat legacy-ciphers weer inschakelt, en draait zo stilletjes eerder hardeningwerk terug.
AI-assisted scanning can check every server and client for weak ciphers continuously instead of once a year, and flag the exact configuration line to remove. Switching legacy suites off is still what closes the gap.AI-ondersteunde scans kunnen elke server en client continu op zwakke ciphers controleren in plaats van eens per jaar, en de exacte configuratieregel aanwijzen. Legacy-suites uitzetten is nog steeds wat het gat dicht.
Modern browsers and TLS libraries resist this attack. TLS 1.3 hides a downgrade marker in the server's reply, and TLS_FALLBACK_SCSV lets a server refuse a forced retry. The risk sits in legacy and custom stacks. An old integration, a batch script or an embedded device retries with a lower version whenever a handshake fails. An attacker on the network only has to make the first attempt fail. The client then completes a TLS 1.0 handshake with a server that still accepts it. Nobody checked that the negotiated version was the one both sides wanted.
Business impact: the connection ends up on a version with known weaknesses and deprecated cipher suites. The IETF formally deprecated TLS 1.0 and 1.1 in 2021 (RFC 8996). Servers that no longer accept them, and clients that fail instead of retrying lower, close this path.
Moderne browsers en TLS-bibliotheken zijn bestand tegen deze aanval. TLS 1.3 verstopt een downgrade-markering in het antwoord van de server, en met TLS_FALLBACK_SCSV kan een server een afgedwongen nieuwe poging weigeren. Het risico zit in oude en zelfgebouwde stacks. Een oude koppeling, een batchscript of een ingebouwd apparaat probeert het met een lagere versie opnieuw zodra een handshake mislukt. Een aanvaller in het netwerk hoeft alleen de eerste poging te laten mislukken. De client voltooit dan een TLS 1.0-handshake met een server die dat nog accepteert. Niemand controleerde of de onderhandelde versie die was die beide kanten wilden.
Bedrijfsimpact: de verbinding belandt op een versie met bekende zwaktes en verouderde ciphersuites. De IETF heeft TLS 1.0 en 1.1 in 2021 formeel afgeschaft (RFC 8996). Servers die ze niet meer accepteren, en clients die afbreken in plaats van lager opnieuw te proberen, sluiten dit pad af.
A downgrade works by making the first handshake fail, a network trick that predates AI by decades. AI gives an attacker no shortcut to the network position needed, or to the client behaviour that makes it work.Een downgrade werkt door de eerste handshake te laten mislukken, een netwerktruc die decennia ouder is dan AI. AI geeft een aanvaller geen kortere weg naar de benodigde netwerkpositie, of naar het clientgedrag dat de terugval mogelijk maakt.
Asked why a connection fails, an AI assistant often suggests lowering the minimum TLS version as the quickest fix, and an administrator under pressure applies it fleet-wide, reopening the exact fallback path meant to be closed.Gevraagd waarom een verbinding faalt, stelt een AI-assistent vaak voor de minimale TLS-versie te verlagen, en een beheerder onder druk past dat overal toe. Zo gaat precies het terugvalpad weer open dat dicht moest blijven.
AI-based monitoring can spot a connection that quietly negotiated an older protocol version than both sides support, something a log file alone rarely surfaces. The safer setting stays strict: fail rather than retry lower.AI-gebaseerde monitoring kan een verbinding signaleren die stilletjes een oudere protocolversie onderhandelde dan beide kanten ondersteunen, iets wat een logbestand zelden laat zien. De veiligere instelling blijft strikt: afbreken in plaats van lager opnieuw proberen.
A bank's server still accepts the old RSA key exchange: the client encrypts a random session key to the server's public key. Secure in the moment. But an attacker records the traffic, and a year later obtains the server's private key (an unpatched server, a storage breach, a departed employee with a copy). Every recorded session can now be decrypted, because each session key was protected by that one static key. Ephemeral key exchange, ECDHE, gives each session its own key, so a stolen server key opens nothing from the past. That is forward secrecy; TLS 1.3 no longer offers the static RSA exchange. The next step is quantum: recorded ECDHE traffic could be decrypted once a large quantum computer exists. The hybrid key exchange X25519MLKEM768 adds post-quantum ML-KEM. It is on by default in current Chrome, Firefox and Safari, in OpenSSL 3.5 and at Cloudflare. NCSC-NL rates it "good" and TLS 1.2 with ECDHE "sufficient" (TLS guidelines 2025-05).
Business impact: without forward secrecy, one lost key exposes years of past traffic. For long-lived secrets the same holds for traffic recorded today and decrypted later by a quantum computer; see Quantum and AI.
De server van een bank accepteert nog de oude RSA-sleuteluitwisseling: de client versleutelt een willekeurige sessiesleutel met de publieke sleutel van de server. Op dat moment veilig. Maar een aanvaller neemt het verkeer op, en krijgt een jaar later de privésleutel van de server in handen (een ongepatchte server, een datalek, een vertrokken medewerker met een kopie). Elke opgenomen sessie is nu te ontsleutelen, omdat elke sessiesleutel door die ene statische sleutel werd beschermd. Kortstondige sleuteluitwisseling, ECDHE, geeft elke sessie een eigen sleutel, zodat een gestolen serversleutel niets uit het verleden opent. Dat heet forward secrecy; TLS 1.3 biedt de statische RSA-uitwisseling niet meer aan. De volgende stap is quantum: opgenomen ECDHE-verkeer kan worden ontsleuteld zodra er een grote quantumcomputer is. De hybride sleuteluitwisseling X25519MLKEM768 voegt daar post-quantum ML-KEM aan toe. Die staat standaard aan in huidige versies van Chrome, Firefox en Safari, in OpenSSL 3.5 en bij Cloudflare. NCSC-NL noemt haar "goed" en TLS 1.2 met ECDHE "voldoende" (TLS-richtlijnen 2025-05).
Bedrijfsimpact: zonder forward secrecy legt één verloren sleutel jaren aan oud verkeer bloot. Voor langlevende geheimen geldt hetzelfde voor verkeer dat vandaag wordt opgenomen en later met een quantumcomputer wordt ontsleuteld; zie Quantum en AI.
Retrospective decryption depends on obtaining the server's private key, through theft, an unpatched system or an insider; AI offers no shortcut to breaking the underlying RSA or Diffie-Hellman mathematics.Retrospectieve ontsleuteling hangt af van het bemachtigen van de privésleutel van de server, via diefstal, een ongepatcht systeem of een insider; AI biedt geen kortere weg om de onderliggende RSA- of Diffie-Hellman-wiskunde te breken.
An insider or attacker with existing access can use AI tools to search file shares and backups faster for an exposed private key, but the underlying weakness, no forward secrecy, is a design choice, not something AI causes.Een insider of aanvaller met bestaande toegang kan met AI-tools sneller bestandsshares en back-ups doorzoeken naar een blootgestelde privésleutel, maar de onderliggende zwakte, geen forward secrecy, is een ontwerpkeuze, geen gevolg van AI.
AI-assisted configuration scanning can find every system still offering static RSA or Diffie-Hellman key exchange across an entire estate in one pass. Moving to ephemeral key exchange is still what removes the risk.AI-ondersteunde configuratiescans kunnen in één keer elk systeem vinden dat nog statische RSA- of Diffie-Hellman-sleuteluitwisseling aanbiedt. Overstappen op kortstondige sleuteluitwisseling is nog steeds wat het risico wegneemt.
Where to look first is your call. Every box that decrypts traffic sets its own TLS version and key exchange, so a strong edge says little about the hops behind it. Hybrid PQ at the edge is often a sensible first step; the amber and red hops usually need an owner and a date.
Waar u eerst kijkt, bepaalt u zelf. Elk blok dat verkeer ontsleutelt, kiest zijn eigen TLS-versie en sleuteluitwisseling. Een sterke rand zegt dus weinig over de hops erachter. Hybride PQ aan de rand is vaak een logische eerste stap; de oranje en rode hops hebben meestal een eigenaar en een datum nodig.
| Control | Contains | In one line |
|---|---|---|
| Cipher audit | Weak ciphers (01) | Scan every server and client continuously, and fix findings before the next release. Automation beats manual review. |
| Disable legacy | Weak ciphers (01) | SSL 2.0/3.0, TLS 1.0 and 1.1 off everywhere, including internal APIs and IoT. A client that cannot connect is worth upgrading, or isolating on its own network segment. |
| AEAD only | Weak ciphers (01) | AES-GCM or ChaCha20-Poly1305. Phase out 3DES and CBC suites; no NULL, EXPORT or RC4. |
| Minimum TLS | Downgrade (02) | TLS 1.2 as the minimum, TLS 1.3 preferred. Worth setting in web servers, VPNs, database drivers and API clients, not just the browser. |
| No fallback | Downgrade (02) | If negotiation fails, close the connection instead of retrying with an older version. Custom clients are where this usually goes wrong. |
| HSTS header | Downgrade (02) | Send Strict-Transport-Security: max-age=31536000; includeSubDomains so browsers always use HTTPS and never fall back to plain HTTP. |
| Forward secrecy | Key exchange (03) | ECDHE only; no static RSA or Diffie-Hellman key exchange. |
| Hybrid post-quantum | Key exchange (03) | Consider X25519MLKEM768 at the edge first, then on internal hops as libraries allow (OpenSSL 3.5+). |
| Configuration as code | All three | Cipher settings in git, reviewed, tested and deployed like application code. Manual tuning drifts and breaks the audit trail. |
| Monitoring | All three | Alert on connections using legacy protocols or weak ciphers, and find out why each one happened. |
| Maatregel | Beheerst | In één zin |
|---|---|---|
| Cipher-audit | Zwakke ciphers (01) | Scan elke server en client continu, en los bevindingen op vóór de volgende release. Automatisering werkt beter dan handmatige controle. |
| Legacy uitschakelen | Zwakke ciphers (01) | SSL 2.0/3.0, TLS 1.0 en 1.1 overal uit, ook bij interne API's en IoT. Een client die niet kan verbinden, kunt u beter upgraden of op een eigen netwerksegment isoleren. |
| Alleen AEAD | Zwakke ciphers (01) | AES-GCM of ChaCha20-Poly1305. Faseer 3DES- en CBC-suites uit; geen NULL, EXPORT of RC4. |
| Minimum TLS | Downgrade (02) | TLS 1.2 als minimum, TLS 1.3 bij voorkeur. Het loont om dit in te stellen op webservers, VPN's, databasedrivers en API-clients, niet alleen in de browser. |
| Geen terugval | Downgrade (02) | Mislukt de onderhandeling, sluit dan de verbinding in plaats van het opnieuw te proberen met een oudere versie. Bij eigen clients gaat dit meestal mis. |
| HSTS-header | Downgrade (02) | Stuur Strict-Transport-Security: max-age=31536000; includeSubDomains zodat browsers altijd HTTPS gebruiken en nooit terugvallen op gewoon HTTP. |
| Forward secrecy | Sleuteluitwisseling (03) | Alleen ECDHE; geen statische RSA- of Diffie-Hellman-sleuteluitwisseling. |
| Hybride post-quantum | Sleuteluitwisseling (03) | Overweeg X25519MLKEM768 eerst aan de rand, daarna op interne hops zodra bibliotheken het ondersteunen (OpenSSL 3.5+). |
| Configuratie als code | Alle drie | Cipherinstellingen in git, gereviewd, getest en uitgerold zoals applicatiecode. Handmatig bijstellen raakt uit de pas en breekt het audittrail. |
| Monitoring | Alle drie | Waarschuw bij verbindingen met legacy-protocollen of zwakke ciphers, en zoek bij elke melding uit hoe die ontstond. |
Weak cipher suites are often enabled for backward compatibility, undetected in configurations that change between deployments, or left in place after migrations.Zwakke ciphersuites staan vaak aan voor achterwaartse compatibiliteit, blijven onopgemerkt in configuraties die per uitrol veranderen, of blijven na migraties achter.
Decryption of traffic in transit, theft of session keys, loss of data confidentiality, and audit and regulatory findings.Ontsleuteling van verkeer onderweg, diefstal van sessiesleutels, verlies van vertrouwelijkheid, en audit- en toezichtsbevindingen.
Continuous scanning and configuration as code reduce likelihood. Risk remains if an old server returns from an unchecked backup, or a supplier's integration still needs a weak cipher.Continu scannen en configuratie als code verkleinen de kans. Er blijft risico als een oude server terugkomt uit een ongecontroleerde back-up, of een koppeling met een leverancier nog een zwakke cipher nodig heeft.
CIO for infrastructure and cipher configuration; CISO for policy and compliance monitoring.CIO voor infrastructuur en cipherconfiguratie; CISO voor beleid en compliancemonitoring.
% of systems offering only TLS 1.2+ with AEAD ciphers · number of systems still accepting TLS 1.0/1.1 or 3DES · % of key exchanges with forward secrecy · % of connections using hybrid post-quantum key exchange.% systemen dat alleen TLS 1.2+ met AEAD-ciphers aanbiedt · aantal systemen dat nog TLS 1.0/1.1 of 3DES accepteert · % sleuteluitwisselingen met forward secrecy · % verbindingen met hybride post-quantum sleuteluitwisseling.
"Misconfiguration or support for weak SSL/TLS cipher suites and protocols enables decryption of encrypted traffic and compromises the confidentiality of data in transit.""Misconfiguratie of ondersteuning van zwakke SSL/TLS-ciphersuites en -protocollen maakt ontsleuteling van versleuteld verkeer mogelijk en tast de vertrouwelijkheid van gegevens onderweg aan."
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | Art. 21 requires policies on the use of cryptography and encryption. In the Netherlands this applies through the Cyberbeveiligingswet (Cbw), in force since 15 August 2026. | Ask for cipher suite and protocol documentation, and evidence of testing for weak algorithms. A configuration screenshot is not audit evidence; repeatable test results are. | A breach enabled by weak ciphers can count as a significant incident if it meets the thresholds. Early warning within 24 hours of becoming aware · incident notification within 72 hours · final report within one month. |
| DORA | For financial entities: ICT risk management includes encryption of data in transit; weak cipher suites are a gap in that control. Include it in ICT governance and third-party oversight. | Read the cryptography section, not the executive summary. It is worth checking that the report names the protocols and cipher suites in use, not just that encryption is present. | A compromise enabled by weak ciphers can be a major ICT incident. Initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware) · intermediate report within 72 hours · final report within one month. |
| SOC 2 | Encryption in transit and change management of encryption configuration fall under the CC6 and CC8 criteria. Weak ciphers represent a deviation. | The report should document the algorithm, key length and key management. If it does not, the control is not fully tested. Ask for detail or a separate cryptographic assessment. | Expect the deviation in the next report. Customers will ask for a remediation timeline and evidence that the issue was not present in prior periods. |
| ISAE 3402 | If you are a service organisation: encryption in transit is usually one of your control objectives. Weak suites found in the period show up as a deviation. | Check that the auditor tested protocol versions and cipher suites, not only that "encryption is used". | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| PCI DSS | Req. 4.2.1: strong cryptography for card data over open, public networks. Req. 12.3.3 (mandatory since 31 March 2025): an inventory of cipher suites and protocols in use, reviewed at least every 12 months. | Ask for a full cipher suite inventory for the systems that handle card data, not a general claim that "encryption is used". | If card data was exposed, your agreements with the card brands and acquirer set the notification duties; expect a forensic investigation. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | Art. 21 vereist beleid voor het gebruik van cryptografie en versleuteling. In Nederland geldt dit via de Cyberbeveiligingswet (Cbw), van kracht sinds 15 augustus 2026. | Vraag om documentatie van ciphersuites en protocolversies, en om bewijs van tests op zwakke algoritmes. Een schermafdruk van de configuratie is geen auditbewijs; herhaalbare testresultaten wel. | Een inbreuk via zwakke ciphers kan als significant incident gelden als het de drempels haalt. Vroegtijdige waarschuwing binnen 24 uur na kennisname · incidentmelding binnen 72 uur · eindverslag binnen een maand. |
| DORA | Voor financiële instellingen: ICT-risicobeheer omvat versleuteling van gegevens onderweg; zwakke ciphersuites zijn een gat in die maatregel. Neem dit mee in ICT-governance en het toezicht op derden. | Lees de cryptografiesectie, niet de managementsamenvatting. Controleer of het rapport de gebruikte protocollen en ciphersuites noemt, niet alleen dat er versleuteling is. | Een compromittering via zwakke ciphers kan een ernstig ICT-incident zijn. Eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na kennisname) · tussentijds verslag binnen 72 uur · eindverslag binnen een maand. |
| SOC 2 | Versleuteling onderweg en wijzigingsbeheer van de versleutelingsconfiguratie vallen onder de criteria CC6 en CC8. Zwakke ciphers zijn een afwijking. | Het rapport hoort het algoritme, de sleutellengte en het sleutelbeheer te beschrijven. Staat dat er niet in, dan is de maatregel niet volledig getest. Vraag om detail of een aparte cryptografische beoordeling. | Verwacht de afwijking in het volgende rapport. Klanten vragen naar een herstelplanning en bewijs dat het probleem niet in eerdere periodes speelde. |
| ISAE 3402 | Als u een serviceorganisatie bent: versleuteling onderweg is meestal een van uw beheersdoelstellingen. Zwakke suites in de periode verschijnen als afwijking. | Controleer of de auditor protocolversies en ciphersuites heeft getest, niet alleen dat "versleuteling wordt gebruikt". | ISAE 3402 schept geen meldplicht richting user auditors. Verwacht een afwijking in het volgende rapport, en vraag in het contract om tussentijdse melding. |
| PCI DSS | Eis 4.2.1: sterke cryptografie voor kaartgegevens over open, publieke netwerken. Eis 12.3.3 (verplicht sinds 31 maart 2025): een inventaris van de ciphersuites en protocollen in gebruik, minstens elke 12 maanden herzien. | Vraag om een volledige ciphersuite-inventaris voor de systemen die kaartgegevens verwerken, geen algemene bewering dat "versleuteling wordt gebruikt". | Zijn kaartgegevens blootgesteld, dan bepalen uw afspraken met de kaartmerken en de acquirer de meldplichten; reken op forensisch onderzoek. |
Checked against: NCSC-NL TLS guidelines (2025-05), RFC 8446 (2018), RFC 7507 (2015), RFC 8996 (2021), Sweet32 (2016), OpenSSL 3.5 notes (Apr 2025), Cloudflare (Oct 2025), PCI DSS v4.0.1 (2024), NIS2 Art. 21 · September 2026.
Gecontroleerd tegen: NCSC TLS-richtlijnen (2025-05), RFC 8446 (2018), RFC 7507 (2015), RFC 8996 (2021), Sweet32 (2016), OpenSSL 3.5-notes (apr 2025), Cloudflare (okt 2025), PCI DSS v4.0.1 (2024), NIS2 art. 21 · september 2026.