In 2016 begon Basisbeveiliging met twee metingen over versleuteling van websites: vertrouwelijkheid en betrouwbaarheid. De metingen waren afkomstig uit het destijds mateloos populaire Qualys SSL Labs, dat uitblonk door eenvoudige rapportcijfers en het meten van de nieuwste kwetsbaarheden. Qualys heeft onlangs de capaciteit van SSL Labs drastisch teruggeschroefd, waardoor het onmogelijk werd om Basisbeveiliging actueel te houden. Daarom is begin maart 2026 de meting uitgeschakeld en worden beide metingen vervangen.
De eerste vervanging wordt aangezet op 19 maart en vervangt de SSL Labs-meting voor betrouwbaarheid van versleuteling. Dit wordt gemeten met een nieuwe scan in Basisbeveiliging. Qua beoordeling loopt deze nagenoeg gelijk met bevindingen van Qualys SSL Labs en Internet.nl, met als toevoeging een zeer uitgebreid overzicht van wat er allemaal mis is. Een beheerder heeft daarmee meteen het volledige overzicht. Als bonus wordt er gemeten op meerdere poorten, dus niet meer alleen op de standaardpoort 443. Tot slot worden direct twee bijzondere situaties meegenomen in de beoordeling; deze leggen we verderop in het artikel uit.
Ergens medio april volgt het tweede deel. Dan wordt de nieuwe versie van Internet.nl vrijgegeven, waarin de nieuwe TLS-richtlijnen van het NCSC zijn verwerkt. De richtlijnen zijn strenger waardoor we veel nieuwe negatieve beoordelingen verwachten. Door het volgen van de richtlijnen is Internet.nl het enige meetinstrument dat aan het versleutelingsbeleid van de overheid voldoet. Basisbeveiliging gebruikt een deel van de metingen van Internet.nl al langere tijd. De richtlijnen gaan over het protocollen, niet over de programmatuur die de protocollen implementeren. Die zijn soms nog steeds kwetsbaar, de richtlijn stelt dat men up-to-date moet blijven: dat is altijd waar.
Met deze twee veranderingen blijft er nog een kleine rest aan kwetsbaarheden over die we nu (tijdelijk) niet meten. Deze komen tot uiting bij het gebruik van museumstukken om online diensten aan te bieden. We overwegen of en hoe we dit alsnog kunnen controleren in een latere meting.
In dit artikel kijken we terug naar de hoogtijdagen van SSL Labs en kwetsbaarheden in versleuteling. Daarna gaan we in op de uitdagingen van onze nieuwe meting: hoe meet je vertrouwen? Het artikel sluit af met twee meetvoorbeelden uit de praktijk.
Wij danken SSL Labs voor de vele jaren leveren van hoogwaardige metingen. Voor ons is deze evolutie een mijlpaal, omdat we hiermee onze bakermat achterlaten.
Vind je transparantie, veiligheid, soevereiniteit, toegankelijkheid en privacy belangrijk? Word dan deelnemer van de Internet Cleanup Foundation en ondersteun onze missie om het internet transparant te maken. We meten al meer dan 10.000 organisaties en 300.000 adressen en maken deze informatie beschikbaar voor iedereen. Meer over deelnemerschap.
Het artikel gaat verder onder de afbeelding.
Kwetsbaarheden als marketing
Waarom Qualys de capaciteit van SSL Labs heeft verminderd, is niet bekend. Ondanks de verminderde capaciteit blijft de tool erg bruikbaar en een goede promotiemachine voor Qualys. Het was een van de eerste online diensten waarmee beheerders van sites op een overzichtelijke manier hun websites konden testen. Dit was waardevol, omdat medio 2010 de kwetsbaarheden om je oren vlogen. SSL Labs was de eerste plek waar je de nieuwste kwetsbaarheden meteen kon meten.
Onderzoekers hadden destijds ook het idee opgevat om hun kwetsbaarheden te voorzien van een naam en logo. Heartbleed was de eerste; dit was een ernstige kwetsbaarheid waarmee het geheugen van computers op afstand kon worden uitgelezen. Dat bevat bijvoorbeeld verwerkte gegevens van gebruikers die gevoelig kunnen zijn, maar ook de sleutels van de versleuteling zelf. Met dat laatste konden verzonden gegevens worden ontsleuteld. Later volgenden er meer gemerkte kwetsbaarheden rondom versleuteling, zoals Ticketbleed, ROBOT en POODLE. Versleuteling was hot en SSL Labs stond in het middelpunt van de aandacht.
SSL Labs stond ook toe dat resultaten opnieuw gepubliceerd mochten worden door anderen. De gebruiker moest dan wel linken naar Qualys om zo reclame te maken voor het bedrijf. Het gebruik moest ook openbaar zijn. Dit is de weg waarop Basisbeveiliging de afgelopen tien jaar deze meting heeft gepubliceerd.
In de afgelopen zeven jaar zijn er geen breed uitgemeten en gemerkte kwetsbaarheden meer toegevoegd aan SSL Labs. Er zijn natuurlijk nog steeds kwetsbaarheden, maar met de komst van nieuwe protocollen zoals TLS 1.2 en TLS 1.3 zitten deze niet meer in het protocol maar in de implementatie ervan. Het is theoretisch mogelijk dat er morgen een nieuwe kwetsbaarheid wordt gepubliceerd, maar ook dan verwachten we niet dat SSL Labs zijn meetcapaciteit nog gaat verhogen. De grootste dreiging die men nu al jaren voorziet, is dat versleuteld verkeer van vandaag in de toekomst makkelijk is te ontsleutelen. Om dat het hoofd te bieden, zijn er al nieuwe manieren van versleuteling beschikbaar.
SSL Labs had in het gebruik wel wat uitdagingen. Zo werd er gemeten vanuit de Verenigde Staten, wat een ander beeld en soms andere resultaten opleverde dan een meting vanuit Nederland. Het project wordt ook gesloten ontwikkeld: het is niet mogelijk om het zelf te draaien of om problemen in de broncode te vinden of op te lossen.
De meeste kwetsbaarheden waar SSL Labs nog op meet, komen bij up-to-date versleuteling niet meer voor. Voor de enkele andere gevallen is een software update nodig. In de volgende tabel staat een overzicht van de kwetsbaarheden waar SSL Labs op controleert, de leeftijd en wat er minimaal nodig is om het probleem te verhelpen. De rode draad is dat het gaat over stukken antiek.
Het artikel gaat verder onder de tabel.
| Kwetsbaarheid | CVE Score (ernst 0 – 10) | Jaar / Kenmerk | Minimale fix |
|---|---|---|---|
| BEAST | 4,3 | CVE-2011-3389 | Gebruik TLS 1.1 of nieuwer |
| Lucky13 | 2,6 | CVE-2013-0169 | Uitzetten CBC |
| Heartbleed | 7,5 | CVE-2014-0160 | Software Update |
| OpenSSL CCS | 7,4 | CVE-2014-0224 | Software Update |
| POODLE (SSLv3 / TLS) | 3,4 | CVE-2014-3566 | Uitzetten CBC |
| OpenSSL Padding Oracle | 5,9 | CVE-2016-2107 | Uitzetten CBC |
| Ticketbleed | 7,5 | CVE-2016-9244 | Update F5 Firewall |
| ROBOT | 7,5 | CVE-2017-13099 | Gebruik Forward Secrecy |
| OpenSSL 0-Length | 5,9 | CVE-2019-1559 | Software Update / Uitzetten CBC |
| Zombie POODLE | 5,9 | CVE-2019-6593 | Uitzetten CBC |
| GOLDENDOODLE | 5,9 | CVE-2019-6593 | Uitzetten CBC |
Meten van betrouwbaarheid
SSL Labs beoordeelde niet alleen de technische vertrouwelijkheid van een meting, maar gaf ook een oordeel over de betrouwbaarheid. Dit is een heel andere manier om naar versleuteling te kijken. Browsers doen dat ook: zij geven een heel duidelijke waarschuwing wanneer versleuteling niet op orde is. In onze nieuwe meting proberen we nog vollediger en behulpzamer te zijn dan SSL Labs.
Om een goede meting neer te zetten, moeten we gaan bepalen wat we betrouwbaar vinden. Over het algemeen bestaan daar afspraken over. Zo is er een beperkt aantal geaccrediteerde bedrijven waarvan we enige vorm van integriteit mogen verwachten. Mochten zij daarin falen, bijvoorbeeld omdat er onterecht geldige certificaten worden uitgegeven onder hun naam, dan wordt het vertrouwen in dat bedrijf ingetrokken en de bijbehorende certificaten ongeldig verklaard. Dit levert daarna de eerder genoemde waarschuwingen in de browser op.
Het vertrouwenssysteem zit zo in elkaar dat iedereen mag bepalen wie ze vertrouwt. Op digitale apparatuur wordt vaak van tevoren een lijst met vertrouwde organisaties meegeleverd en bijgewerkt. Een gebruiker kan dit alsnog volledig naar eigen smaak en wens bepalen en inrichten, bijvoorbeeld omdat er vertrouwen tussen personen of bedrijven is afgesproken op papier.
Basisbeveiliging geeft in haar nieuwe meting ook extra vertrouwen, waar browsers dat niet doen. Wij vertrouwen twee extra organisaties die daardoor in heel specifieke situaties een afwijking mogen hebben. De rest moet dan nog steeds op orde zijn. Wanneer deze situaties optreden, wordt het label “trusted by policy” gegeven en een groene beoordeling. Wie dan naar de pagina surft, ziet alsnog een waarschuwing. Wij maken uitzondering in de volgende twee gevallen:
De Nederlandse staat heeft een aantal certificaten aangewezen als vertrouwd. Deze worden uitgegeven door de Staat der Nederlanden, Digidentity, KPN, QuoVadis, ZOVAR en het UZI-register. Deze certificaten worden regelmatig gemeten. In dit geval vertrouwen wij specifiek de uitgever. Andere controles, zoals de verlooptijd van een certificaat, worden nog steeds uitgevoerd.
Microsoft is de tweede partij die we vertrouwen in een specifiek geval. Het gaat om een aantal subdomeinen die nodig zijn voor online dienstverlening van het product Office 365. Dit is een populair product bij veel overheden. Het gebruik van dit pakket vereist een aantal subdomeinen, zoals “enterpriseenrollment”. Daarop wordt vervolgens een certificaat van Microsoft aangeboden en niet van de domeineigenaar zelf. Het probleem is dat het certificaat niet aansluit op het domein waar het gebruikt wordt: dat is onbetrouwbaar. Maar omdat wij weten welke certificaten dat zijn en de situatie zeer specifiek is, keuren wij deze afwijking goed. Ook hier moet de rest wel goed zijn, zoals dat het certificaat niet is ingetrokken.
Onze nieuwe meting is een drop-in replacement voor de betrouwbaarheidsmeting van SSL Labs, maar dan open source. De uitkomsten zijn hetzelfde in de 20.000 sites waarmee we dit hebben getest. Omdat er onbeperkt veel mogelijkheden zijn voor de inrichting van versleuteling, zullen we ongetwijfeld nog wel nieuwe meetfouten in exotische scenario’s tegenkomen.
In de onderstaande tabel staat hoe de nieuwe meting zich verhoudt tot SSL Labs en Internet.nl
Het artikel gaat verder onder de tabel
| Meetpunt | Qualys SSL Labs | Internet.nl | Basisbeveiliging |
|---|---|---|---|
| Standaardpoort (443) | Ja | Ja | Ja |
| Andere poorten (8443) | Nee | Nee | Ja |
| Vertrouwen | Ja | Ja | Ja |
| Uitgebreid vertrouwen | Ja | Nee | Ja |
| Antieke kwetsbare applicaties | Ja | Nee | Nee |
De inhoud van de betrouwbaarheidsmeting
In het onderstaande voorbeeld is te zien dat de meting zeer uitvoerig en volledig is. Het is daarmee specifieker en diepgaander dan SSL Labs op dit onderwerp. In de meting wordt gewerkt met constateringen en beoordelingen. Constateringen kunnen sommige problemen verklaren, terwijl beoordelingen direct bepalen of iets goed of slecht is. Een beoordeling kan beleidsmatig worden weggestreept; welk beleid wordt gebruikt en de invloed daarvan is ook in de resultaten terug te zien.
In de meting wordt rekening gehouden met de volgende punten:
- Een overzicht van alle ontvangen certificaten met alle details.
- Op welke IP-adressen welke certificaten zijn ontvangen (een domein heeft vaak meerdere IP-adressen om de bezoekersaantallen te verspreiden over meerdere servers. Sommige sites leveren per IP een andere set met certificaten; vaak is dat een onjuiste configuratie, maar het is niet per definitie fout.)
- Welk “validation_path” wordt gebruikt. Dit is het antwoord op de vraag: in welke volgorde moet ik de ontvangen certificaten lezen om bij een vertrouwd punt uit te komen? Overige certificaten worden genegeerd maar wel getoond.
- Constateringen over:
- De geleverde certificaten: is de volgorde juist, zitten er duplicaten in e.d.
- Certificaten afzonderlijk: staat er een naam en onderwerp in
- Beoordelingen over:
- De ketting van certificaten: wordt deze vertrouwd
- De certificaten afzonderlijk: zijn ze geldig, is de naam juist, zijn ze ingetrokken of geblokkeerd, is het doel juist, is de sleutel sterk e.d.
- Onvolledige informatie wordt automatisch aangevuld, voor zover dat mogelijk is. Dat doen we bijvoorbeeld met Authority Information Access.
Zo ziet dat er op de website uit. Deze interface is nog niet helemaal af.
Een voorbeeld van een standaardscenario van Rijksoverheid.nl is hieronder te zien:
{
"hostname": "rijksoverheid.nl",
"port": 443,
"ip_version": 4,
"reports": [
{
"hostname": "rijksoverheid.nl",
"port": 443,
"ip_version": 4,
"ip_addresses": [
"178.22.85.8",
"178.22.85.9",
"178.22.85.10",
"178.22.85.11"
],
"trust_policy": [],
"chain": {
"verify_return_code": 0,
"verify_return_message": "ok",
"order_correct": true,
"incomplete": false,
"certificate_count": 2,
"validation_path": [
0,
1
],
"has_duplicate_certificates": false,
"trust_policy": [],
"issues_after_trust_policy": []
},
"certificates": [
{
"certificate": {
"order": 0,
"subject": "CN=rijksoverheid.nl,O=Rijksoverheid,L=Den Haag,ST=Zuid-Holland,C=NL",
"issuer": "CN=DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1,O=DigiCert Ireland Limited,C=IE",
"serial_number": "20745128947824244504813894076557775527",
"common_name": "rijksoverheid.nl",
"subject_alt_names": [
"feeds.government.nl",
"feeds.rijksoverheid.nl",
"government.nl",
"opendata.government.nl",
"opendata.rijksoverheid.nl",
"rijksoverheid.nl",
"static.rijksoverheid.nl",
"www.government.nl",
"www.rijksoverheid.nl"
],
"not_before": "2025-07-16T00:00:00+00:00",
"not_after": "2026-07-15T23:59:59+00:00",
"crl_uris": [
"http://crl.digicert.eu/DigiCertG2TLSEURSA4096SHA3842022CA1.crl"
],
"ocsp_uris": [
"http://ocsp.digicert.eu"
],
"signature_algorithm": "sha256",
"public_key_algorithm": "RSA",
"public_key_size_bits": 2048,
"sha1_fingerprint": "ad9195b63b7e7e9b9555bf88b5eafd4b184efa80",
"sha256_fingerprint": "4e25c8add553f56d7522d149f7f725e62b2276fd3c4b77809e11df2515b08271"
},
"analysis": {
"expired": false,
"not_yet_valid": false,
"has_common_name": true,
"common_name_matches_hostname": true,
"domain_matches_hostname": true,
"has_subject": true,
"self_signed": false,
"revocation_status": "not_revoked",
"insecure_signature": false,
"insecure_key": false,
"blocklisted": false,
"in_validation_path": true,
"trust_policy": [],
"issues": [],
"issues_after_trust_policy": [],
"observations": []
}
},
{
"certificate": {
"order": 1,
"subject": "CN=DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1,O=DigiCert Ireland Limited,C=IE",
"issuer": "CN=DigiCert Global Root G2,OU=www.digicert.com,O=DigiCert Inc,C=US",
"serial_number": "8388256945268818773803678311110571166",
"common_name": "DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1",
"subject_alt_names": [],
"not_before": "2022-09-19T00:00:00+00:00",
"not_after": "2032-09-18T23:59:59+00:00",
"crl_uris": [
"http://crl3.digicert.com/DigiCertGlobalRootG2.crl"
],
"ocsp_uris": [
"http://ocsp.digicert.com"
],
"signature_algorithm": "sha384",
"public_key_algorithm": "RSA",
"public_key_size_bits": 4096,
"sha1_fingerprint": "5d87007cdf358910925bea5433778f7813749510",
"sha256_fingerprint": "a4adfc2917bb1451d312371d441acdb686107fbc0b3156d5570e99e1121974fa"
},
"analysis": {
"expired": false,
"not_yet_valid": false,
"has_common_name": true,
"common_name_matches_hostname": false,
"domain_matches_hostname": false,
"has_subject": true,
"self_signed": false,
"revocation_status": "could_not_check",
"insecure_signature": false,
"insecure_key": false,
"blocklisted": false,
"in_validation_path": true,
"trust_policy": [],
"issues": [],
"issues_after_trust_policy": [],
"observations": []
}
}
],
"certificate_issues": [],
"certificate_issues_after_trust_policy": [],
"certificate_observations": [],
"chain_issues": [],
"chain_issues_after_trust_policy": [],
"chain_observations": [],
"scan_issues": [],
"error_class": null
}
],
"trust_policy": [],
"certificate_issues": [],
"certificate_issues_after_trust_policy": [],
"certificate_observations": [],
"chain_issues": [],
"chain_issues_after_trust_policy": [],
"chain_observations": [],
"scan_issues": [],
"error_class": null
}
