Internetbeveiliging wordt vaak een delicate dans van veiligheid, functionaliteit en gebruikerservaring. Een goed voorbeeld is de voortdurende strijd om browsers te verbinden met informatie die door CA's wordt verstrekt over ingetrokken certificaten. Deze FAQ beschrijft de primaire mechanismen die in de loop van de tijd voor dit doel zijn gebruikt, inclusief CRL's, OCSP, OCSP-nieten en Moet nietenen, meest recentelijk, CRLite.
De eerste poging van CA's om de intrekkingsstatus van hun uitgegeven certificaten te publiceren, was voorbij certificaatintrekkingslijsten (CRL's). Een CRL is simpelweg een lijst van alle certificaten die de CA ooit heeft ingetrokken voordat ze vervallen. Deze worden regelmatig bijgewerkt door de CA's en browsers moesten ze vóór elke HTTPS-verbinding controleren. Na verloop van tijd groeiden de CRL's in omvang, evenals de taak van elke browser om ze te beoordelen. Naarmate de tijd die nodig was om een grote (en groeiende) CRL te downloaden en te ontleden, groeide, namen ook de vertragingen voor de gebruiker toe. In een poging om deze problemen te verminderen, hebben browsers en CA's het Online Certificate Status Protocol (OCSP) ontwikkeld en geïmplementeerd.
De Online Certificaat Status Protocol (OCSP) is het internetprotocol dat door webbrowsers wordt gebruikt om de intrekkingsstatus van SSL /TLS certificaten geleverd door HTTPS-websites. Terwijl SSL /TLS certificaten worden altijd uitgegeven met een vervaldatum, er zijn bepaalde omstandigheden waarin een certificaat moet worden ingetrokken voordat het verloopt (bijvoorbeeld als de bijbehorende privésleutel mogelijk gecompromitteerd is). Daarom moet de huidige geldigheid van het certificaat van een website altijd worden gecontroleerd door klanten, ongeacht de vervaldatum.
In zijn eenvoudigste vorm werkt OCSP als volgt:
1. Een webbrowser ontvangt een certificaat van een HTTPS-website.
2. De webbrowser stuurt een verzoek naar een OCSP-responder, een server die wordt beheerd door de certificeringsinstantie (CA) die het certificaat heeft uitgegeven.
3. Het ondertekende antwoord van de OCSP-responder aan de browser geeft aan of het certificaat geldig is of is ingetrokken.
Helaas kwam OCSP met een aantal problemen. Veel OCSP-implementaties waren niet betrouwbaar genoeg, wat ongeduldige browsers en andere clientsoftware ertoe aanzette OCSP-controle in soft-fail-modus te implementeren. Dit betekent dat als een OCSP-server niet op tijd kon worden bereikt tijdens het reageren, het certificaat als geldig zou worden beschouwd en ze zouden doorgaan met de HTTPS-verbinding.
Man-in-the-middle-aanvallen hebben hiervan misbruik gemaakt door alle OCSP-queries of verbindingen te blokkeren, met behulp van een gestolen certificaat om toegang te krijgen tot een vertrouwde HTTPS-verbinding. Dit zou ertoe kunnen leiden dat gevoelige informatie wordt gedeeld met slechte actoren, wat leidde tot OCSP Stapling als oplossing.
Hoewel OCSP aanvankelijk werd geïntroduceerd om de bandbreedte- en schaalproblemen van certificaatintrekkingslijsten (CRL's) op te lossen, introduceerde het verschillende eigen prestatie- en beveiligingsproblemen die momenteel worden aangepakt via OCSP-nieten. Bij OCSP-nieten:
1. Een webserver vraagt en verkrijgt een ondertekend OCSP-antwoord voor zijn certificaat van een OCSP-responder, die maximaal 7 dagen in de cache kan worden opgeslagen.
2. De server neemt de in de cache opgeslagen OCSP-reactie samen met (of "geniet aan") zijn certificaat op in zijn HTTPS-reacties op webbrowsers.
3. Om een mogelijke aanval te voorkomen waarbij een website een gestolen ingetrokken certificaat aanbiedt zonder een geniet OCSP-antwoord, kunnen certificaten worden uitgegeven met een must-niet-extensie, waardoor OCSP-nieten voor het certificaat verplicht zijn.
Gemotiveerd door kwaadaardige bewegingen door MITM-aanvallers, introduceerden CA's en browserverkopers een extensie voor SSL-certificaten die bekend staat als OCSP moet nieten (gedefinieerd in RFC 7633, hoewel daar niet naar verwezen als "OCSP Must-Staple").
OCSP Must-Staple vereist OCSP-nieten voor het certificaat. Komt een browser in aanraking met een certificaat zonder OCSP Stapling, dan wordt het geweigerd. Must-Staple vermindert niet alleen de dreiging van downgrade-aanvallen, het vermindert ook onnodig verkeer naar de OCSP-responders van de CA, waardoor het reactievermogen en de algehele OCSP-prestaties worden verbeterd.
CRLite is een nieuw voorgestelde standaard die informatie zou verzenden over ALLE ingetrokken SSL /TLS certificaten rechtstreeks naar de browsers. Dit zou mogelijk alle belastende processen en onbetrouwbare verbindingen tussen browsers en CA's wegnemen door de informatie over ingetrokken CA's rechtstreeks in de browsers te integreren.
Een belangrijk punt van zorg kan de enorme hoeveelheid informatie zijn die wordt opgeslagen, aangezien de grote en groeiende omvang van CRL's een van de kernproblemen met OCSP-processen was en is. CRLite gebruikt bloeifilters om grote hoeveelheden gegevens te comprimeren, waardoor ze beter beheersbaar worden voor de browsers.
Als een certificaat te nieuw is, wat betekent dat de browser nog niet is opgenomen in updates, zou dan OCSP gebruiken (geniet of actief bevraagd).
