Wat is certificaattransparantie (CT)?

Elke keer dat je op het hangslotje in je browser klikt, vertrouw je erop dat de website is wie hij beweert te zijn. Lange tijd was er een ernstig probleem met dat vertrouwen, namelijk de onjuiste uitgifte van certificaten. Certificate Transparency (CT) is ontwikkeld om dat probleem op te lossen en vormt tegenwoordig de kern van hoe Chrome, Safari en andere moderne browsers bepalen of ze een SSL/TLS-certificaat kunnen vertrouwen.

Dit artikel legt uit wat Certificate Transparency is, waarom het is ontwikkeld, hoe het werkt en wat uw organisatie moet weten om te voldoen aan de regelgeving en beschermd te blijven.

Wat is certificaattransparantie (CT)?

Certificate Transparency (CT) is een open framework, oorspronkelijk voorgesteld door Google in 2013 en gestandaardiseerd in RFC 6962. Het maakt de uitgifte van SSL/TLS-certificaten openbaar controleerbaar. Simpel gezegd beantwoordt CT één belangrijke vraag: hoe weet je of een certificeringsinstantie (CA) een certificaat voor je domein rechtmatig heeft uitgegeven en niet per ongeluk of door een beveiligingslek?

Voordat CT bestond, kon een CA een certificaat uitgeven voor elk domein zonder dat de domeineigenaar daar ooit iets van wist. Een aanvaller die erin slaagde een CA te misleiden of te compromitteren, kon een geldig certificaat verkrijgen voor google.com of yourbank.com, en browsers zouden dit zonder meer vertrouwen. De DigiNotar-hack in 2011 maakte deze dreiging zeer reëel, toen aanvallers frauduleuze certificaten verkregen voor belangrijke domeinen, waaronder Google.

Certificaattransparantie lost dit op door te vereisen dat elk publiekelijk vertrouwd certificaat wordt vastgelegd in een openbaar, alleen-toevoegend logboek voordat browsers het vertrouwen. Hierdoor verandert de uitgifte van certificaten van een privéhandeling in een publiekelijk verifieerbare handeling.

Waarom werd transparantie van certificaten ingevoerd?

Het Public Key Infrastructure (PKI) -model werkt op basis van een vertrouwensketen. Browsers vertrouwen een reeks root-certificeringsinstanties (CA's). Deze CA's geven certificaten uit aan websites, en browsers accepteren deze. In theorie werkt dit goed, maar in de praktijk creëerde het een zwakke schakel: de CA's zelf.

Het DigiNotar-incident was geen op zichzelf staand geval. Door nalatigheid, menselijke fouten of een beveiligingslek is er in de loop der jaren bij meerdere certificeringsinstanties (CA's) onjuiste certificaatuitgifte geweest. Het echte probleem was niet alleen dat er ongeldige certificaten werden uitgegeven. Het probleem was dat niemand buiten de CA ervan wist. Domeineigenaren hadden geen inzicht, beveiligingsonderzoekers konden geen audits uitvoeren en browsers konden de fraude niet tijdig opsporen.

Certificaattransparantie heeft die verantwoordingskloof gedicht. Door te eisen dat alle certificaten openbaar worden geregistreerd, wordt elk onjuist uitgegeven certificaat snel zichtbaar voor domeineigenaren, beveiligingsonderzoekers en browsers, voordat het daadwerkelijk schade kan aanrichten.

Hoe Certificate Transparency Logs werken

De motor achter Certificate Transparency is het CT-logboek, een openbaar toegankelijk register waaraan alleen gegevens kunnen worden toegevoegd en dat elk certificaat registreert dat eraan wordt toegevoegd. Zie het als een openbare notaris voor internetcertificaten. Zo werkt het proces:

• Certificaatuitgifte: Een certificeringsinstantie (CA) verstrekt een SSL/TLS-certificaat voor een domein. Het certificaat, of een voorlopig certificaat, wordt vóór of kort na de uitgifte naar een of meer CT-logboeken verzonden.
• Logboekvermelding en SCT: De logserver accepteert de inzending en retourneert een Signed Certificate Timestamp (SCT), een cryptografisch ondertekend ontvangstbewijs dat bewijst dat het certificaat op een specifiek tijdstip is geregistreerd.
• Merkle-boomstructuur: CT-logs gebruiken een Merkle-hashboom om certificaten vast te leggen in een manipulatiebestendige structuur. Elke vermelding is cryptografisch gekoppeld aan de voorgaande, waardoor elke poging om een ​​historische vermelding te wijzigen of te verwijderen direct detecteerbaar is.
• Handhaving door alleen toevoegen: Logboeken kunnen alleen worden aangevuld. Certificaten kunnen worden toegevoegd, maar nooit verwijderd. Dit betekent dat een certificeringsinstantie (CA) op geen enkele manier stilletjes bewijs van een onjuist uitgegeven certificaat kan wissen.
• Publieke toegankelijkheid: CT-logs zijn voor iedereen toegankelijk. Onderzoekers, domeineigenaren en beveiligingstools kunnen ze raadplegen om alle geregistreerde certificaten voor elk domein te bekijken.

Er bestaan ​​tegenwoordig meerdere CT-logs, beheerd door Google, Cloudflare, DigiCert en anderen. Browsers houden een lijst bij van vertrouwde logs, en alleen SCT's uit deze goedgekeurde logs tellen mee voor de CT-compliance.

Inzicht in tijdstempels van ondertekende certificaten (SCT's)

Een Signed Certificate Timestamp (SCT) is het cryptografische bewijs dat een certificaat is ingediend bij een CT-logboek. De browser controleert dit om te bevestigen dat het certificaat publiekelijk is geregistreerd voordat de verbinding wordt vertrouwd.

Een SCT (Security Certificate Certificate) bevat drie elementen: de log-ID die aangeeft door welk CT-logboek het certificaat is uitgegeven, een tijdstempel dat aangeeft wanneer het certificaat is geregistreerd, en een digitale handtekening uit het logboek die bevestigt dat de vermelding authentiek is. SCT's kunnen op drie manieren aan browsers worden geleverd: direct ingebed in het certificaat zelf, opgenomen in de TLS-handshake via een TLS-extensie, of geleverd via OCSP- stapling. De meeste moderne CA's (Certificate Authority) sluiten SCT's direct in op het moment van uitgifte, waardoor het proces onzichtbaar is voor serverbeheerders.

Browsers vereisen doorgaans twee of meer SCT's (Security Control Tests) uit verschillende, goedgekeurde logbestanden. Deze redundantie betekent dat zelfs als één logbestand offline gaat of niet langer betrouwbaar is, de naleving van de CT's nog steeds kan worden geverifieerd aan de hand van de overige SCT's.

Waarom Chrome en Safari certificaattransparantie vereisen

Google Chrome begon in april 2018 met het vereisen van CT-conformiteit voor alle publiekelijk vertrouwde certificaten. Apple's Safari volgde kort daarna met een eigen CT-beleid, dat alle certificaten omvatte die na 15 oktober 2018 waren uitgegeven. Dit waren geen willekeurige beslissingen. Ze kwamen na jaren van gedocumenteerde tekortkomingen van certificeringsinstanties en de erkenning dat de vrijwillige invoering van CT te traag verliep.

Als een certificaat geen geldige SCT's (Security Certificate Transactions) uit browservertrouwde logboeken bevat, zullen Chrome en Safari een certificaatfout weergeven. De site zal als onbetrouwbaar worden beschouwd, gebruikers zullen waarschuwingen te zien krijgen en in bedrijfsomgevingen kunnen geautomatiseerde systemen de verbinding volledig blokkeren.

Een certificaat zonder geldige SCT's wordt door Chrome en Safari hetzelfde behandeld als een verlopen of zelfondertekend certificaat. Voor bedrijven betekent dit onderbroken werkprocessen, omzetverlies en beschadigd klantvertrouwen.

De CT-vereisten van Chrome en Safari hebben het hele CA-ecosysteem ertoe aangezet zich hieraan te conformeren. Elke CA die door deze browsers vertrouwd wil blijven, moet certificaten indienen bij CT-logs, waardoor deelname aan CT een ononderhandelbare vereiste is voor het opereren in de PKI-ruimte. Merk op dat CT-vereisten alleen gelden voor publiekelijk vertrouwde certificaten. Interne certificaten uitgegeven door private CA's voor intranetgebruik zijn vrijgesteld van de browser-CT-vereisten, hoewel het monitoren van interne PKI met CT-achtige logging steeds vaker wordt aanbevolen als een best practice op het gebied van beveiliging.

Hoe encryptieconsultancy kan helpen

Certificaattransparantie geeft uw organisatie inzicht in welke certificaten er voor uw domeinen zijn uitgegeven. Maar dat inzicht is pas echt nuttig als er daadwerkelijk iemand meekijkt. De meeste beveiligingsteams hebben niet de tijd of de tools om naast al het andere beheerwerk ook actief CT-logs te monitoren. Dat is precies de leemte die CertSecure Manager wil opvullen.

CertSecure Manager is het platform voor certificaatlevenscyclusbeheer van Encryption Consulting. Naast het beheren van uw eigen certificaatinventaris, biedt het uw team de mogelijkheden voor detectie en monitoring die CT echt nuttig maken in plaats van slechts een verplichte compliance-checklist.

Dit is waar het direct ondersteuning biedt:

• Certificaten opsporen in uw omgeving: CertSecure Manager scant uw infrastructuur om een ​​volledig en actueel overzicht te maken van alle SSL/TLS-certificaten die aan uw domeinen zijn gekoppeld, inclusief certificaten waarvan u mogelijk niet wist dat ze waren uitgegeven. Als er een ongeautoriseerd certificaat verschijnt, wilt u daarvan op de hoogte zijn voordat een aanvaller het kan misbruiken.
• Automatisering van vervaldatum en verlenging: CT-conformiteit vereist geldige SCT's uit door browsers vertrouwde logboeken. Deze vereiste wordt opnieuw ingesteld telkens wanneer een certificaat wordt vernieuwd. CertSecure Manager automatiseert het vernieuwingsproces, zodat uw certificaten altijd actueel en CT-conform zijn en nooit ongemerkt verlopen.
• Auditspoor en nalevingsrapportage: Elke gebeurtenis met betrekking tot certificaten, van uitgifte en verlenging tot intrekking, wordt vastgelegd in CertSecure Manager. Zo beschikt u over de documentatie die uw beveiligings- en compliance-teams nodig hebben wanneer er vragen ontstaan.
• Gecentraliseerde zichtbaarheid: Het beheren van certificaten in meerdere domeinen, omgevingen en teams zonder een gecentraliseerd platform betekent dat je afhankelijk bent van spreadsheets en agendaherinneringen. CertSecure Manager vervangt dit door één gestructureerd overzicht van je volledige certificaatomgeving.

CT-logs zijn openbaar. Dat betekent dat de certificaten die voor uw domeinen zijn uitgegeven, voor iedereen zichtbaar zijn, ook voor aanvallers die op zoek zijn naar een kans. Het is daarom niet langer optioneel om de juiste tools te hebben voor het monitoren en beheren van uw certificaatlandschap.

Conclusie

Certificate Transparency (CT) is een van de weinige beveiligingstechnologieën die daadwerkelijk heeft waargemaakt wat het beloofde. Het heeft de uitgifte van certificaten getransformeerd van een ondoorzichtig proces naar iets dat publiekelijk verifieerbaar en fraudebestendig is. Nu Chrome en Safari de CT-vereisten afdwingen, is naleving simpelweg een basisvereiste voor elke organisatie die actief is op het openbare internet.

Maar naleving alleen is niet genoeg. Organisaties die CT slechts als een vinkje op een lijstje beschouwen, missen de meest nuttige functie ervan: de mogelijkheid om logboeken te controleren op ongeautoriseerde certificaten en actie te ondernemen voordat er schade ontstaat. In een omgeving waar aanvallers geavanceerd zijn en inbreuken op de toeleveringsketen veelvuldig voorkomen, is die mogelijkheid tot vroegtijdige waarschuwing van cruciaal belang.