Hoe werkt SSL: OCSP en OCSP Stapling


SSL certificaten staan voor veiligheid op het internet, maar u kunt er meer mee dan u denkt. In deze nieuwe serie nemen we een kijkje achter de schermen van SSL en laten we zien hoe u uw SSL certificaat nog beter voor u kunt laten werken.

Hoofdstuk 4: OCSP en OCSP Stapling

In de voorgaande hoofdstukken hebben we laten zien dat de veiligheid van een certificaat zo opgeschroefd kan worden dat het een bijna onneembaar fort wordt. Maar een SSL certificaat is alleen zo veilig als het ook daadwerkelijk nog geldig is. De meeste SSL certificaten hebben tegenwoordig een geldigheidsduur van 1 of 2 jaar, waarna ze vervangen moeten worden. De oude certificaten worden gerevoked, oftewel ingetrokken, door de CA die ze uitgaf. De CA markeert ze daarmee als niet langer geldig. Maar nog lopende certificaten kunnen ook gerevoked worden als ze niet meer veilig zijn: wanneer een hacker toegang krijgt tot de private key, kan hij het certificaat misbruiken om malafide websites te voorzien van een groen slotje. In dat geval wordt het gehackte certificaat gerevoked om verder misbruik te voorkomen.

Deze status moet gecontroleerd worden door de browser voor een gebruiker de website daadwerkelijk bereikt. Hiervoor zijn meerdere methoden, die slim ingezet kunnen worden om zowel de veiligheid als de snelheid van uw website te verbeteren.

CRL

De geldigheid van een certificaat wordt standaard gecontroleerd door de browser met behulp van een Certificate Revocation List (CRL). Een CRL is een blacklist van een CA, waarop de CA alle certificaten plaatst die gerevoked zijn. De browser dient bij elk bezoek van een website met een certificaat een verzoek in bij de CA, waarop de CA de CRL terugstuurt naar de browser. Hierop voert de browser een controle uit van het certificaat in kwestie: komt deze voor op de CRL? Dan is het certificaat ingetrokken door de CA en dus niet meer geldig. De meeste browsers geven in dit geval een foutmelding aan de gebruiker.

CRL

Het gebruik van een CRL komt echter wel met nadelen: de browser moet bij elk certificaat opnieuw de CRL opvragen om te controleren of het certificaat op de blacklist voorkomt. Dit betekent ook dat elke request een zekere hoeveelheid verkeer vraagt van en naar de CA. Bij een populaire website kan dit dus behoorlijk wat verkeer opleveren voor de CA, waardoor het langer kan duren tot de browser reactie terug heeft gekregen. Dit kan zelfs zoveel verkeer opleveren dat het misbruikt kan worden voor een DoS-aanval.

Daarnaast is het geen foutloos proces: mocht de CA niet bereikbaar zijn, wordt er geen CRL teruggegeven aan de browser en gaat de browser er, mogelijk incorrect, van uit dat het certificaat betrouwbaar is. Ook is het aan de CA om de CRL up to date te houden. Mocht de CA een CRL niet tijdig bijwerken, zou een gerevoked certificaat nog steeds als veilig gezien kunnen worden door de browser.

OCSP

Om al deze problemen het hoofd te bieden werd een alternatief bedacht: OCSP. OCSP staat voor Online Certificate Status Protocol en is een protocol dat werkt met een whitelist: in plaats van een volledige blacklist van de CA op te vragen, stuurt de browser nu slechts één certificaat waarvan de status moet worden gecontroleerd. De CA stuurt vervolgens voor dat certificaat de status, die ‘good’, ‘revoked’ of ‘unknown’ kan zijn, terug naar de browser.

Deze check is om meerdere redenen beter dan controle via CRL: de response van de CA is vele malen kleiner omdat er om veel minder gegevens wordt gevraagd, waardoor bij drukbezochte websites de kans op overbelasting kleiner is. Ook is de afhandeling aan de kant van de browser veel compacter omdat er alleen hoeft te worden gekeken naar die response status. Daarnaast is de kans dat een gerevoked certificaat alsnog als veilig gezien wordt veel kleiner, omdat de browser de gebruiker niet alsnog doorstuurt naar de website in kwestie als er geen positief resultaat uit de check rolt. In plaats daarvan toont de browser een foutmelding.

OCSP

OCSP is echter niet de oplossing voor de problemen die CRL’s met zich meebrengen: als de hoeveelheid requests voor een webpagina erg hoog is, kan de CA alsnog in de problemen komen met de afhandeling. In plaats van de gebruiker de pagina gewoon te tonen en er van uit te gaan dat het certificaat niet voorkomt op de blacklist, wordt er nu een foutmelding getoond en kan de gebruiker de pagina alleen bekijken als hij expliciet toestemming geeft aan de browser om het proces te omzeilen. Natuurlijk is dat geen veilige optie: er wordt dan bewust gekozen voor een onbeveiligde verbinding.

Maar over de veiligheid van OCSP zijn ook twijfels. Zo worden er vraagtekens gezet bij de hoeveelheid informatie die een CA kan halen uit de requests van de browsers met betrekking tot de websites die bezocht worden. Ook verloopt de verbinding met de CA altijd over HTTP, waardoor het verkeer open en bloot ligt voor hackers die mee kunnen luisteren en de status af kunnen vangen. Tot slot zijn er ook twijfels over hoe veilig het daadwerkelijk kan zijn als er een derde partij betrokken moet worden bij de controle van de status van een certificaat, zelfs als die derde partij de CA is die het certificaat heeft uitgegeven.

De oplossing: OCSP Stapling

OCSP is wel de beste oplossing, maar had nog steeds meerdere problemen op het gebied van snelheid, veiligheid en stabiliteit. Dat is opgelost met OCSP Stapling. Bij OCSP Stapling wordt er regelmatig vanuit de server zelf een OCSP request gestuurd naar de CA. Vervolgens bevestigt (‘stapled’, oftewel ‘vastgemaakt met een nietje’) de server dit resultaat aan de SSL handshake die aangeroepen wordt als een gebruiker verbinding maakt met een website over HTTPS. Dit betekent dat er veel minder dataverkeer tussen de server en de browser nodig is, omdat het resultaat meegegeven wordt met de SSL verbinding, die toch al opgezet wordt bij elk bezoek. Omdat het resultaat ondertekend moet zijn door de CA, kan er geen misbruik gemaakt worden van dit systeem door frauduleuze resultaten mee te geven.

OCSP-Stapling

Daarbij heeft OCSP Stapling ook de bijkomende voordelen dat het stabieler is dan CRL of OCSP. Omdat het resultaat voor een bepaalde tijd wordt vastgehouden door de server hoeft er alleen periodiek verbinding te worden gemaakt met de OCSP responder van de CA. Mocht de CA niet kunnen reageren, bijvoorbeeld omdat hun servers plat liggen, heeft de server van de website alsnog een resultaat opgeslagen dat gebruikt kan worden. Mocht de server geen ‘vastgeniet’ resultaat terug kunnen geven aan de browser, kan de browser er altijd nog voor kiezen om zelf de OCSP responder van de CA aan te roepen. Krijgt de browser echter een ongeldig ‘vastgeniet’ resultaat terug, verbreekt hij de verbinding.

OCSP Stapling heeft dus enorm veel voordelen: het maakt de verbinding met uw website sneller, veiliger, en stabieler door het antwoord op de request vast te nieten aan de SSL verbinding en de requests onder water met regelmaat te vernieuwen in plaats van steeds maar weer een request te moeten versturen bij elke verbinding. Daarnaast maakt de browser niet meer de verbinding met de CA, waardoor men zich ook geen zorgen hoeft te maken over welke informatie de CA ontvangt over hun browse-gewoonten.

OCSP Stapling is een setting binnen uw webserver-installatie die heel gemakkelijk aan of uit te zetten is. De manier waarop hangt af van de server-software die draait op uw webserver. In dit artikel op het community-gedeelte van Digitalocean staat duidelijk uitgelegd hoe u voor verschillende softwarepakketten OCSP Stapling instelt.

Met dit laatste hoofdstuk komt er een einde aan de serie over SSL en Verder. Vanaf volgende week gaan we een stapje terug met wat lichter leesvoer voor de zomer en beginnen we met hoofdstuk 1: DNS.

Geschreven door Stefanie Weber (Networking4all)

Dit ingezonden artikel is geschreven door Stefanie Weber van Networking4all.

Lees ook de onderstaande artikelen van Networking4all

Stuur ook uw blog, achtergrond artikel of andere bijdrage in!

Indien u zelf een interessante bijdrage, zoals een blog, how-to of achtergrond heeft, dan plaatsen wij die graag en dat kost u niks. Neem contact op met de ISPam.nl redactie via [email protected] of kijk op deze pagina voor meer informatie over het leveren van een bijdrage aan ISPam.nl.

Jurrian, 9 augustus 2016 8:50 am

Laatste artikel in de serie? Ik had nog wel een artikel (of op z'n minst een paragraaf) over DANE verwacht. Hiermee maak je OCSP deels overbodig (hoewel het altijd beter is om de validatie op meerdere manieren uit te voeren) door een hash van je certificaat op te nemen in een TLSA-record onder de hostname(s) die in het certificaat opgenomen zijn.

Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.