Als je enige tijd in de cybersecurity hebt doorgebracht, heb je waarschijnlijk de gouden regel gehoord: "Gebruik altijd HTTPS in productie". Het is hét advies voor het beveiligen van webcommunicatie, en niet voor niets: het versleutelt data-in-transit. Met andere woorden: HTTPS beschermt gevoelige informatie tegen afluisteren. Maar als het gaat om Public Key Infrastructure (PKI), met name voor het beheer van certificaatintrekking, gaat die regel niet altijd op. Bij Encryption Consulting brengen we onze uitgebreide ervaring in met Fortune 500-bedrijven, overheidscontractanten en cloud-native ondernemingen om robuuste PKI-systemen te ontwerpen. Een vraag die ons vaak wordt gesteld, is: "Zouden we niet moeten gebruiken HTTPS voor onze intrekkingseindpunten, zoals CRL's en OCSP?”
Het antwoord zal u misschien verbazen: in deze gevallen doet HTTPS vaak meer kwaad dan goed. Laten we eens kijken waarom HTTP de slimmere keuze kan zijn in PKI voor intrekkingseindpunten.
Herroepingsinformatie wordt digitaal ondertekend door CA
Wanneer een certificaat wordt ingetrokken, bijvoorbeeld vanwege een gecompromitteerde sleutel of een beleidsovertreding, Certificate Authority (CA) moeten vertrouwende partijen op de hoogte stellen. Dit gebeurt via twee primaire methoden. Certificate Revocation Lists (CRL's) zijn ondertekende bestanden die periodiek worden gepubliceerd en een lijst bevatten van alle ingetrokken certificaten. Als alternatief biedt het Online Certificate Status Protocol (OCSP) realtime statuscontroles voor individuele certificaten. Wat beide methoden gemeen hebben, is dat de CA ze cryptografisch ondertekent. Deze handtekening garandeert de authenticiteit en integriteit van de gegevens, ongeacht of deze via HTTP, HTTPS of zelfs een ouderwetse USB-stick worden geleverd.
Als iemand probeert een CRL of OCSP-respons tijdens de overdracht te manipuleren, mislukt de validatiecontrole van de vertrouwende partij en worden de gegevens direct afgewezen. Dus, wat voegt HTTPS in deze context toe? In de meeste gevallen niet veel.
Onverwachte risico's van HTTPS in PKI
Je vraagt je misschien af waarom HTTPS niet de standaard is, gezien de beveiligingsvoordelen. Het antwoord ligt in een subtiel maar cruciaal probleem dat wordt beschreven in RFC 5280, de standaard voor X.509-certificaten en CRL's. Deze standaard raadt het gebruik van HTTPS af voor Certificate Distribution Points (CDP's) of Authority Information Access (AIA)-velden. Het probleem is iets wat een circulaire afhankelijkheid wordt genoemd in dit scenario, waarbij het CRL- of OCSP-eindpunt via HTTPS wordt gehost. Die HTTPS-service is afhankelijk van een certificaat om vertrouwen te creëren. Om een certificaat te valideren, moet een vertrouwende partij de intrekkingsstatus ervan controleren.
Als de intrekkingsstatus echter op hetzelfde HTTPS-eindpunt wordt gehost, raken we verstrikt in een eindeloze lus. RFC 5280 noemt dit "onbegrensde recursie" en het is niet alleen een theoretisch probleem; het kan in de praktijk leiden tot validatiefouten, het verbreken van vertrouwensketens en het verstoren van services.
We hebben dit probleem waargenomen bij een federale contractant die te maken had met strenge DoD- en FedRAMP-nalevingsvereisten. Hun beveiligingsbeleid vereiste het gebruik van HTTPS voor alle eindpunten, inclusief CRL's en OCSP responders. Helaas resulteerde deze opstelling in fouten bij de certificaatvalidatie tijdens TLS-handshakes, wat leidde tot opeenvolgende fouten in hun firewalls en services. En zo fataal kan de circulaire afhankelijkheid zijn. En specifiek in dit geval werd deze gecreëerd door de op HTTPS gehoste intrekkingseindpunten. Door hun infrastructuur opnieuw te ontwerpen om ondertekende CRL's en OCSP-reacties via gewoon HTTP te leveren, hebben we de recursielus geëlimineerd en de functionaliteit hersteld zonder de beveiliging of compliance in gevaar te brengen.
In ons PKI-as-a-Service-platform hanteren we een vergelijkbare aanpak, waarbij we intrekkingsgegevens via HTTP aanbieden met ingebouwde handtekeningen en strikte cachingcontroles. Dit vereenvoudigt validatie in cloudomgevingen en voorkomt dat soortgelijke fouten optreden.
Wanneer HTTPS de juiste keuze kan zijn
Er zijn scenario's waarin HTTPS zinvol kan zijn voor intrekkingseindpunten, maar deze vereisen zorgvuldige planning en overweging. Als u zich bijvoorbeeld zorgen maakt over privacy, zoals het voorkomen van metadatalekken die onthullen welke certificaten worden gecontroleerd, kan HTTPS OCSP-query's en -reacties versleutelen. Het is ook bruikbaar in streng gecontroleerde omgevingen met vastgezette certificaten, waar u ervoor kunt zorgen dat de intrekkingsstatus van het HTTPS-certificaat wordt gevalideerd via een apart, onafhankelijk pad. Een andere optie is het gebruik van out-of-band validatie om circulaire afhankelijkheden volledig te vermijden. Deze gevallen zijn echter de uitzondering, niet de regel, en vereisen een nauwgezette architectuur om nieuwe risico's te voorkomen.
Een slimmer alternatief is OCSP-nieten
Als u live OCSP-opzoekingen volledig wilt omzeilen, is er een betere optie: OCSP-nietenDeze aanpak stelt de server in staat een OCSP-respons op te halen en te cachen, en deze vervolgens tijdens de TLS-handshake aan het certificaat te koppelen. Dit elimineert de noodzaak voor clients om rechtstreeks een OCSP-responder te raadplegen, wat de prestaties verbetert door externe aanroepen te verminderen, de privacy verbetert door validatiegegevens server-side te bewaren en de veerkracht vergroot in het geval dat de OCSP-responder tijdelijk niet beschikbaar is.
Hoe encryptieconsulting PKI voor u laat werken
Bij Encryption Consulting praten we niet alleen over standaarden, we bouwen systemen die deze in de praktijk brengen. Of u nu implementeert Microsoft ADCSdoor gebruik te maken van cloudgebaseerde CA's zoals AWS Private CA of Azure Key Vault, door open-sourceoplossingen zoals EJBCA te gebruiken of door onze PKI-as-a-Service platform zorgen wij ervoor dat uw intrekkingsinfrastructuur veilig en betrouwbaar is. We ontwerpen systemen die ondertekende intrekkingsgegevens via HTTP leveren zonder de validatie te verstoren, implementeren OCSP- en CRL-responders met hoge beschikbaarheid en integreren intrekkingscontroles in CI/CD-pipelines en Zero Trust-omgevingen. CertSecure Manager Het platform automatiseert het beheer van de levenscyclus van certificaten en zorgt ervoor dat uw activiteiten soepel verlopen. Bovendien helpen we u circulaire vertrouwenslussen te voorkomen door alle HTTPS-eindpunten zorgvuldig en onafhankelijk te valideren.
Conclusie
Bij PKI draait beveiliging niet alleen om encryptie; het gaat erom ervoor te zorgen dat gegevens ondertekend, vertrouwd en toegankelijk zijn zonder de vertrouwensketen te verbreken. HTTPS heeft zijn nut, maar voor certificaatintrekking is HTTP vaak betrouwbaarder. Bij Encryption Consulting ontwerpen we PKI systemen die een evenwicht vinden tussen normen en prestaties in de praktijk, zodat u valkuilen kunt vermijden die de uptime of naleving kunnen verstoren.
Klaar om een toekomstbestendige PKI te bouwen? Neem contact op met onze PKI-experts via info@encryptionconsulting.com of bezoek onze website. https://www.encryptionconsulting.com om te ontdekken hoe wij u kunnen helpen.
