Let's Encrypt gaat binnenkort ook Certificate Revocation Lists ondersteunen
Certificaatautoriteit Let's Encrypt gaat binnenkort ook Certificate Revocation Lists ondersteunen die informatie over ingetrokken certificaten bevatten. Dit moet voorkomen dat internetgebruikers via ingetrokken certificaten kunnen worden aangevallen. Dat heeft Let's Encrypt aangekondigd. Tls-certificaten zorgen voor een versleutelde verbinding tussen website en bezoekers en maken het mogelijk om websites te identificeren.
Vertrouwen in deze certificaten is dan ook belangrijk. Wanneer een certificaat niet meer is te vertrouwen, bijvoorbeeld door een incident zoals bij DigiNotar, kan het tls-certificaat worden ingetrokken. Deze informatie moet vervolgens aan de browser worden gecommuniceerd. Hiervoor zijn Certificate Revocation Lists (CRLs) en het Online Certificate Status Protocol (OCSP) bedacht.
CRLs zijn eigenlijk gewoon lijsten met alle ingetrokken certificaten van een bepaalde certificaatautoriteit. Dergelijke lijsten zijn dan ook vaak zeer groot en daardoor inefficiënt om te downloaden als de browser één specifiek certificaat van een bezochte website wil controleren. Als alternatief werd OCSP ontwikkeld. Hierbij wordt alleen het certificaat van de bezochte website gecontroleerd..
De browser moet hiervoor wel verbinding met een OCSP-server kunnen maken. Wanneer de browser geen antwoord ontvangt zal die in veel gevallen het certificaat in kwestie gewoon accepteren. Aanvallers kunnen hier misbruik van maken door al het verkeer naar de OCSP-server te blokkeren. Doordat de browser voor elke bezochte website een OCSP-request verstuurt kan een malafide of gedwongen certificaatautoriteit daarnaast bijhouden welke websites iemand bezoekt.
Volgens Let's Encrypt zijn beide oplossingen dan ook niet ideaal. CRLs zijn inefficiënt en OCSP is onbetrouwbaar. Een mogelijk beter alternatief zijn browserspecifieke CRLs. In plaats van elke browser bij gebruikers grote CRLs te laten downloaden, downloadt de browserleverancier die centraal. Vervolgens wordt de CRL in een kleiner formaat opgedeeld en daarna onder gebruikers als update verstuurd. Firefox noemt dit CRLite en verstuurt elke zes uur updates met ingetrokken certificaten.
Hierdoor zijn de grootste problemen met de traditionele CRLs opgelost. Downloads zijn snel, hebben geen impact bij het bezoeken van websites en de controle van ingetrokken certificaten vindt lokaal plaats. Apple en Mozilla eisen vanaf 1 oktober dat alle certificaatautoriteiten CRLs gaan uitgeven waar Safari en Firefox gebruik van kunnen maken voor de certificaatcontrole.
Bij de start van Let's Encrypt besloot de certificaatautoriteit om alleen OCSP te ondersteunen en geen CRLs uit te geven. Destijds eisten browserleveranciers ook alleen OCSP. Vanwege de nieuwe vereisten is Let's Encrypt hierop teruggekomen en gaat nu ook CRLs aanbieden.
Hierbij wordt door de server die de website aanbied een OSCP response toegevoegd aan de TLS handshake.
https://en.wikipedia.org/wiki/OCSP_stapling
Om het weglaten van de stapling te voorkomen kan je vervolgens certificaten met de 'must-staple' aanvragen, uiteraard ten koste van een stukje beschikbaarheid als de webserver het OCSP bewijs niet snel genoeg kan aanvragen. Op dat moment kan een webbrowser de verbinding niet garanderen, waardoor de website niet geladen kan worden.
Kortom, een mooie oplossing en fijn dat Let's Encrypt CRL's gaat publiceren, maar de problemen van OCSP zijn al zo goed als opgelost op een veel slimmere manier met OCSP Stapling.
de einddatum verstreken is, en dat is bij letsencrypt al na 3 maanden.
Als er zoveel certificaten revoked moeten worden is het uitgiftemechanisme kapot. Beter daar even naar kijken dan!
Dat browsermakers dit doen suggereert wel dat ze OCSP stapling niet ideaal vinden. Wellicht werkt het in de praktijk niet zo goed als in theorie zou kunnen.
Ik kan zo iets bedenken waar dat heel goed aan zou kunnen liggen. OCSP stapling moet op de webserver geconfigureerd worden. Dus eindeloos veel beheerders van eindeloos veel webservers moeten het aanzetten. Afgaande op hoe dat meestal uitpakt denk ik dat je er gif op kan innemen dat het heel vaak wordt nagelaten. En dan is zo'n mechanisme misschien theoretisch geweldig, maar in de praktijk is het niet beter dan hoe vaak het wordt toegepast.
Een mechanisme waarbij al die webserverbeheerders simpelweg worden overgeslagen, waarbij elke webbrowserleverancier zelf in de hand heeft dat de revocatiegegevens verspreid worden naar alle gebruikers, heeft dan de voorkeur.
de einddatum verstreken is, en dat is bij letsencrypt al na 3 maanden.
Wat er gaande is is dat ooit OCSP is bedacht omdat CRLs inefficiënt waren, maar dat OCSP blijkbaar ook niet je van het is, en dat browsermakers (Mozilla, Google) nu toch weer teruggaan naar CRLs, maar dan verspreid via de browsermakers zelf, op een slimmere manier die de grote overhead vermijdt en dat nadeel van CRLs dus ondervangt.
Let's Encrypt doet eigenlijk niets anders dan dat ondersteunen omdat het nou eenmaal die kant op gaat, en ze geven een korte (en niet volledige) uitleg van wat er gaande is. Dit is geen ontwikkeling waar Let's Encrypt op aanstuurt, en het heeft niets te maken met de vraag hoeveel certificaten door Let's Encrypt ingetrokken worden. Het is een ontwikkeling die de browsermakers hebben ingezet waar Let's Encrypt in meegaat omdat het internet wel moet blijven werken.
Je loopt dan nog steeds die paar maanden risico. Daarvoor is juist een CRL uitgevonden.
Bijzonder dat LE dit standaard niet ondersteund trouwens. Ik had dit niet verwacht bij LE. Dit is toch vrij standaard voor een CA?
de einddatum verstreken is, en dat is bij letsencrypt al na 3 maanden.
Wat er gaande is is dat ooit OCSP is bedacht omdat CRLs inefficiënt waren, maar dat OCSP blijkbaar ook niet je van het is, en dat browsermakers (Mozilla, Google) nu toch weer teruggaan naar CRLs, maar dan verspreid via de browsermakers zelf, op een slimmere manier die de grote overhead vermijdt en dat nadeel van CRLs dus ondervangt.[/quote]
Ik had gelezen dat hun CRL 8 gigabyte was. Maar nu ik nog eens terug kijk zie ik dat dit helemaal niet zo is maar dat
dit uitging van de theoretische case dat ze ALLE certificaten moesten revoken. In dat geval kun je beter het eerstvolgende
level certificaat revoken lijkt me.
Hierbij wordt door de server die de website aanbied een OSCP response toegevoegd aan de TLS handshake.
https://en.wikipedia.org/wiki/OCSP_stapling
Nou, ook daar zit een kanttekening aan. Bij het inschakelen van OCSP stapling leg je namelijk een extra taak bij de webserver in kwestie neer én daarbij een extra externe afhankelijkheid. Ik heb meegemaakt dat webservers vol liepen met openstaande processen omdat er een storing was bij de OCSP responders bij een grote CA. En ja, daar zijn timeouts voor te configureren, maar dat neemt niet weg dat je het onherroepelijk gaat merken qua performance. We schakelen allemaal reverse lookups uit in een webserver om soortgelijke problematiek te voorkomen, maar OCSP stapling creëert hetzelfde probleem als je pech hebt.
Dus nee, ik schakel het tegenwoordig standaard uit. Laat de browser/client maar lekker die OCSP lookups uitvoeren.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
