TLS-versies uitfaseren: zo schakel je 1.0 en 1.1 veilig uit

Schakel TLS 1.0 en TLS 1.1 uit. Accepteer minimaal TLS 1.2 en geef waar mogelijk voorkeur aan TLS 1.3. Deze aanbeveling volgt direct uit de richtlijnen van het NCSC, de verwachtingen van de Autoriteit Persoonsgegevens en PCI DSS. Het proces verloopt in vier logische stappen: inventariseren, testen, gefaseerd uitrollen en structureel monitoren.

Kort samengevat:

• TLS 1.0 en 1.1 zijn onveilig vanwege kwetsbaarheden en worden officieel afgekeurd volgens RFC 8996, wat naleving en veiligheid in gevaar brengt.
• Organisaties moeten alle TLS-eindpunten inventariseren, testen, gefaseerd uitrollen en jaarlijks monitoren om een succesvolle migratie te waarborgen.
• Het uitschakelen van oude protocollen vereist bovendien het aanpassen van configuraties op webservers, mailservers en load balancers, en verifiëren met tools zoals OpenSSL en SSL Labs.
• Voor een volledige en veilige migratie is het aan te raden om dit proces uit te besteden aan gespecialiseerde partijen zoals NLXS, die start met een gratis ICT-scan.
• Verouderde TLS-configuraties kunnen leiden tot niet-naleving van de AVG en PCI DSS, met mogelijke juridische en financiële risico’s voor de organisatie.

Inhoudsopgave

• Waarom moet je TLS 1.0 en 1.1 uitfaseren?
• Hoe pak je de TLS-migratie in vijf stappen aan?
• Hoe configureer je Nginx, Apache, HAProxy, Postfix en Dovecot?
• Hoe test en verifieer je dat TLS 1.0/1.1 echt uitstaat?
• Wat betekent TLS-uitfasering voor compliance en governance?
• NLXS-checklist: wanneer laat je de migratie uitvoeren?
• Auteursperspectief: valkuilen uit de praktijk
• Laat NLXS de TLS-migratie voor je uitvoeren
• Bronnen
• Veelgestelde vragen

Waarom moet je TLS 1.0 en 1.1 uitfaseren?

TLS 1.0 en 1.1 zijn technisch verouderd. Beide versies zijn gevoelig voor aanvallen zoals BEAST en POODLE, en steunen op verzwakte handshake-mechanismen die nog afhankelijk zijn van SHA-1. De internetstandaardisatie-organisatie IETF heeft dit vastgelegd in RFC 8996, dat TLS 1.0 en 1.1 formeel afkeurt als onveilig voor productiegebruik.

Het NCSC hanteert een classificatiesysteem met vier niveaus: ‘goed’, ‘voldoende’, ‘uitfaseren’ en ‘onvoldoende’. TLS 1.0 en 1.1 vallen in de categorie ‘uitfaseren’ of erger, en dat label is geen vrijblijvend advies. Het NCSC staat ‘uitfaseren’ alleen toe wanneer er een gedocumenteerd migratieplan met einddatum aan gekoppeld is.

Voor organisaties die persoonsgegevens verwerken, komt daar een juridische laag bovenop. De Autoriteit Persoonsgegevens waarschuwt dat verouderde TLS-configuraties kunnen leiden tot niet-naleving van artikel 24 en 32 van de AVG, die passende technische beveiligingsmaatregelen verplichten. Voor betaalomgevingen geldt een harde deadline: PCI DSS staat sinds 30 juni 2018 geen gebruik van verouderde TLS-versies meer toe.

Drie argumenten wegen het zwaarst:

• Technische kwetsbaarheid: BEAST, POODLE en verzwakte SHA-1-afhankelijkheden maken TLS 1.0/1.1 aantoonbaar onveilig.
• Regelgeving: RFC 8996 keurt beide versies formeel af als internetstandaard.
• Aansprakelijkheid: AVG en PCI DSS koppelen concrete compliance-risico’s aan het gebruik van verouderde configuraties.

Hoe pak je de TLS-migratie in vijf stappen aan?

Een TLS-migratieproces mislukt meestal niet door gebrek aan kennis, maar door gebrek aan overzicht. Beheerders vergeten vaak een enkele legacy-terminator, en dat ene vergeten eindpunt ondermijnt de hele exercitie. Volg deze vijf stappen in vaste volgorde.

1. Inventariseer alle TLS-eindpunten. Breng elke plek in kaart waar TLS wordt afgehandeld: webservers, mailservers, API-gateways, load balancers en interne diensten die onderling versleuteld verkeer afhandelen. Vergeet interne terminators niet, die worden het vaakst overgeslagen.
2. Meet het werkelijke clientgebruik. Analyseer serverlogs en draai externe scans om te zien welke clients nog TLS 1.0 of 1.1 gebruiken. Vaak blijkt een groot deel van dat ‘legacy-verkeer’ afkomstig van bots of verouderde scanners, niet van echte gebruikers.
3. Test in een niet-productieomgeving. Schakel de oude protocollen uit op een canary-server of testomgeving en monitor handshake-fouten voordat je verder gaat.
4. Rol gefaseerd uit en verwijder volledig. Schakel per dienst uit, begin met laag-risico omgevingen, en verwijder TLS 1.0/1.1 daarna volledig. Laat geen fallback-optie staan.
5. Documenteer en plan een jaarlijkse hercontrole. Leg einddata en acceptatiecriteria vast, en herhaal de controle jaarlijks als vast onderdeel van je risicobeheer.

Pro-tip: Draai de scan uit stap 2 minimaal twee weken voordat je iets uitschakelt. Kortdurende metingen missen vaak periodieke processen, zoals een maandelijkse batchverbinding van een oud extern systeem.

Hoe configureer je Nginx, Apache, HAProxy, Postfix en Dovecot?

Elke TLS-terminator vraagt zijn eigen configuratie. Er bestaat geen systeembrede schakelaar die alle applicaties tegelijk dekt, zo blijkt uit praktijkgidsen over het uitschakelen van TLS 1.0 en 1.1 op Linux-servers. Werk daarom terminator voor terminator.

Nginx

Stel de toegestane protocollen expliciet in:

ssl_protocols TLSv1.2 TLSv1.3;

Controleer eerst je OpenSSL-versie, want oudere builds ondersteunen TLS 1.3 niet. Test de configuratie met nginx -t voordat je herlaadt, en herlaad daarna pas met een reload, niet met een harde restart die actieve verbindingen afbreekt.

Apache

Zet SSLProtocol op een allow-list in plaats van een blokkeerlijst:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Controleer al je virtual hosts afzonderlijk. Een globale instelling in de hoofdconfiguratie wordt regelmatig overschreven door een oudere regel in een specifieke vhost, en dat gat blijft vaak onopgemerkt tot een scan het blootlegt.

HAProxy

Stel het minimale protocolniveau in op de bind-regel:

bind :443 ssl crt /pad/naar/cert.pem ssl-min-ver TLSv1.2

Controleer of je HAProxy-build tegen een OpenSSL-versie is gecompileerd die TLS 1.3 ondersteunt, anders werkt de instelling niet zoals bedoeld.

Postfix en Dovecot

Mailservers worden vaak vergeten bij een TLS-migratie, terwijl STARTTLS-verbindingen exact hetzelfde risico lopen. In Postfix stel je in:

smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

In Dovecot regel je dit via:

ssl_min_protocol = TLSv1.2

Test STARTTLS-poorten (25, 465, 587, 993, 995) apart, want deze worden zelden meegenomen in een standaard webscan.

CDN’s, load balancers en hardware

Controleer ook terminatie bij je CDN, je load balancer en eventuele hardware-appliances. Een correct geconfigureerde origin server betekent niets als de front-end laag nog steeds oude protocollen adverteert aan de buitenwereld. Pas ieder eindpunt afzonderlijk aan en controleer ze een voor een.

Hoe test en verifieer je dat TLS 1.0/1.1 echt uitstaat?

Vertrouw niet op de configuratie alleen; verifieer het resultaat. openssl s_client is het snelste startpunt:

openssl s_client -connect voorbeeld.nl:443 -tls1
openssl s_client -connect voorbeeld.nl:443 -tls1_1

Beide commando’s moeten mislukken met een handshake-foutmelding. Krijg je toch een verbinding, dan staat het oude protocol nog open.

• Draai daarna een externe scan via Qualys SSL Labs of nmap met het script ssl-enum-ciphers om alle luisterende poorten te controleren, niet alleen poort 443.
• Herhaal dit voor elke terminator uit de vorige sectie: webserver, mailserver, load balancer en CDN.
• Correleer handshake-foutstatistieken uit je logs met supporttickets. Een piek in beide rond dezelfde periode wijst vaak op een verouderde interne integratie die je bij de inventarisatie had moeten meenemen.

Statistiek om te onthouden: RFC 8996 keurt TLS 1.0 en 1.1 formeel af als internetstandaard. Dat is geen aanbeveling van een enkele leverancier, maar een besluit van de bredere internetstandaardisatiegemeenschap, wat het gewicht achter de uitfaseringsdruk verklaart.

Wat betekent TLS-uitfasering voor compliance en governance?

Uitfaseren zonder documentatie levert bij een audit meer problemen op dan het oplost. Leg voor elke tijdelijke uitzondering vast waarom die bestaat, onder welke voorwaarden ze acceptabel is en welke einddatum erop staat. Dat sluit aan bij de aanpak die het NCSC en de Autoriteit Persoonsgegevens beide hanteren: risico’s mogen bestaan, maar nooit zonder eigenaarschap en tijdslimiet.

• Documenteer elke ‘uitfaseren’-classificatie met acceptatiecriteria en een harde einddatum.
• Behandel PCI DSS-vereisten als een apart nalevingsproject wanneer je betaalterminals of kaartgegevens verwerkt; de eisen zijn strenger dan algemene webbeveiliging.
• Isoleer onvermijdelijke legacy-clients achter een specifiek, gecontroleerd eindpunt in plaats van de fallback voor je hele infrastructuur open te houden.
• Zet nooit een downgrade-fallback aan voor oude protocollen; dat verhoogt het risico op downgrade-aanvallen aanzienlijk.

Zowel de AVG als PCI DSS verwachten een risicoanalyse die niet eenmalig is, maar herhaald wordt. Een jaarlijkse hercontrole van je TLS-configuratie hoort daarom net zo vast op de agenda als een wachtwoordbeleid of een firewallreview.

NLXS-checklist: wanneer laat je de migratie uitvoeren?

Bij NLXS zien we bij ICT-scans regelmatig dezelfde blinde vlek: een goed beveiligde hoofdwebsite met daarachter een vergeten mailserver of interne API die nog gewoon TLS 1.0 accepteert. Een gestructureerde aanpak dekt dat af met vaste opleverpunten:

• Volledige inventarisatie van alle TLS-eindpunten, inclusief interne diensten.
• Een testplan met canary-uitrol voordat productie wordt aangepast.
• Verificatie via scans en loganalyse na elke stap.
• Een rapportage met einddata en aanbevolen hercontrolemomenten.

Uitbesteden loont vooral wanneer je infrastructuur uit meerdere terminators bestaat of wanneer intern de tijd ontbreekt om elk eindpunt zorgvuldig te testen.

Auteursperspectief: valkuilen uit de praktijk

Wat opvalt bij loganalyse: het merendeel van het ‘legacy-verkeer’ dat beheerders zien, komt van scanners en bots, niet van echte klanten. Toch schrikken teams daar vaak van terug en stellen de uitfasering uit. Communiceer daarom vroeg met interne stakeholders over de geplande einddatum, zodat niemand achteraf verrast wordt door een dichtgetimmerde verbinding.

— Ken

Laat NLXS de TLS-migratie voor je uitvoeren

Bij TLS-migraties is het belangrijk om snel technische problemen op te lossen en dit vaak tegen een vooraf afgesproken maandtarief zonder onverwachte kosten.

Klanten zoals TU Eindhoven en JCI Breda vertrouwen op NLXS voor betrouwbare en veilige infrastructuur, precies het soort omgeving waar een TLS-migratie zorgvuldig en zonder downtime moet verlopen. NLXS start elk traject met een gratis ICT-scan die je TLS-eindpunten, versies en risico’s in kaart brengt, gevolgd door een concreet migratieplan, gefaseerde uitvoering en verificatie achteraf. Voor webshops en bedrijven die hun webhosting volledig willen ontzorgen, inclusief actuele TLS-configuratie, is dit een directe manier om het risico van verouderde protocollen structureel weg te nemen. Plan vandaag nog een vrijblijvend gesprek en vraag de gratis ICT-scan aan om te zien waar jouw infrastructuur nog kwetsbaar is.

Veelgestelde vragen

Wat betekent TLS-versies uitfaseren precies?

Het betekent dat je oudere, onveilige protocolversies zoals TLS 1.0 en 1.1 stopt met accepteren en overschakelt op TLS 1.2 of TLS 1.3 als minimum.

Waarom keurt RFC 8996 TLS 1.0 en 1.1 af?

RFC 8996 keurt beide versies af omdat ze kwetsbaar zijn voor aanvallen zoals BEAST en POODLE en steunen op verzwakte, SHA-1-afhankelijke handshake-mechanismen.

Is TLS 1.2 voldoende of moet het TLS 1.3 zijn?

TLS 1.2 met AEAD- en ECDHE-only cipher suites is acceptabel als minimum, maar het NCSC en encryptiespecialisten geven de voorkeur aan TLS 1.3 waar mogelijk.

Welke boetes riskeer je bij verouderde TLS-configuraties?

De Autoriteit Persoonsgegevens koppelt geen vast boetebedrag aan TLS specifiek, maar waarschuwt dat verouderde configuraties kunnen leiden tot niet-naleving van artikel 24 en 32 van de AVG.

Kan NLXS de TLS-migratie voor mijn organisatie uitvoeren?

Ja, NLXS voert de volledige migratie uit, van inventarisatie en testplan tot gefaseerde uitrol en verificatie, te starten met een gratis ICT-scan.

Aanbevelingen

• Begin op dag 1: serverhardening voor beheerders, 3 acties
• Slimme gebruikers of slimme phishing? Beveilig je netwerk!
• Zakelijke wifi beveiligen: 8 heldere stappen
• Tips voor goede beveiliging van de ICT in jouw bedrijf