image

Let's Encrypt gaat binnenkort ook Certificate Revocation Lists ondersteunen

donderdag 8 september 2022, 11:23 door Redactie, 10 reacties

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.

Reacties (10)
08-09-2022, 12:46 door Anoniem
Het verbaast mij dat OCSP stapling niet wordt genoemd.
Hierbij wordt door de server die de website aanbied een OSCP response toegevoegd aan de TLS handshake.

https://en.wikipedia.org/wiki/OCSP_stapling
08-09-2022, 12:53 door Anoniem
Het privacyprobleem van OCSP kan voorkomen worden door gebruik te maken van OCSP Stapling. Dan vraagt de webserver het OCSP bewijs aan en stuurt deze door naar de webbrowser. De webbrowser hoeft dan niet zelf meer het internet op, wat sneller en privacy vriendelijker is.

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.
08-09-2022, 13:08 door Anoniem
De titel had ook kunnen zijn "Let's Encrypt moet binnenkort ook Certificate Revocation Lists gaan ondersteunen". Bij de titel krijg ik het gevoel dat Let's Encrypt iets toevoegd terwijl het ze min of meer opgelegd wordt.
08-09-2022, 13:59 door Anoniem
Door Anoniem: De titel had ook kunnen zijn "Let's Encrypt moet binnenkort ook Certificate Revocation Lists gaan ondersteunen". Bij de titel krijg ik het gevoel dat Let's Encrypt iets toevoegd terwijl het ze min of meer opgelegd wordt.
Ik lees niks over moete. Die certificaten verlopen toch al na een paar maanden toch? Dat is sneller dan mijn winbox ge-update is.
08-09-2022, 16:12 door Anoniem
Waarom heeft letsencrypt van die gigantische revocation lists? Je kunt een certificaat toch van die lijst afgooien als
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!
08-09-2022, 17:12 door Anoniem
Door Anoniem: 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.
Let's Encrypt vermeldt in dat stukje inderdaad niet dat OCSP stapling ook nog bestaat. Wat ze wel vermelden is dat ze CRL's gaan aanbieden omdat browsers bezig zijn die kant op te gaan en omdat zowel Mozilla als Apple het binnenkort van CA's eisen.

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.
09-09-2022, 07:54 door Anoniem
Door Anoniem: Waarom heeft letsencrypt van die gigantische revocation lists? Je kunt een certificaat toch van die lijst afgooien als
de einddatum verstreken is, en dat is bij letsencrypt al na 3 maanden.
Ze zijn echt wel zo snugger om dat te doen. Ze hebben het erover dat CRLs in het algemeen inefficiënt zijn, niet per se omdat hun eigen CRLs buitensporig groot zijn maar omdat ze in het algemeen groot kunnen zijn. Er zijn nog altijd CA's die certificaten met een geldigheidsduur van een jaar uitgeven. Die tellen ook mee in hoe goed CRLs werken.

Als er zoveel certificaten revoked moeten worden is het uitgiftemechanisme kapot. Beter daar even naar kijken dan!
Als een certificaat ingetrokken moet worden hoeft niet aan het uitgiftemechanisme te liggen. Het kan er bijvoorbeeld ook aan liggen dat op een webserver is ingebroken of omdat een beheerder heeft geblunderd met de configuratie. Dat soort dingen heeft een CA niet in de hand, daarvoor moet je bij de beheerder van die webserver zijn.

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.
09-09-2022, 08:05 door Anoniem
Door Anoniem:
Door Anoniem: De titel had ook kunnen zijn "Let's Encrypt moet binnenkort ook Certificate Revocation Lists gaan ondersteunen". Bij de titel krijg ik het gevoel dat Let's Encrypt iets toevoegd terwijl het ze min of meer opgelegd wordt.
Ik lees niks over moete. Die certificaten verlopen toch al na een paar maanden toch? Dat is sneller dan mijn winbox ge-update is.
Dus? dat maakt toch niet uit?

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?
09-09-2022, 10:12 door Anoniem
Door Anoniem:
Door Anoniem: Waarom heeft letsencrypt van die gigantische revocation lists? Je kunt een certificaat toch van die lijst afgooien als
de einddatum verstreken is, en dat is bij letsencrypt al na 3 maanden.
Ze zijn echt wel zo snugger om dat te doen. Ze hebben het erover dat CRLs in het algemeen inefficiënt zijn, niet per se omdat hun eigen CRLs buitensporig groot zijn maar omdat ze in het algemeen groot kunnen zijn. Er zijn nog altijd CA's die certificaten met een geldigheidsduur van een jaar uitgeven. Die tellen ook mee in hoe goed CRLs werken.
Maar daar heeft letsencrypt niet mee te maken dus dat houdt hen niet tegen een CRL te maken.

Als er zoveel certificaten revoked moeten worden is het uitgiftemechanisme kapot. Beter daar even naar kijken dan!
Als een certificaat ingetrokken moet worden hoeft niet aan het uitgiftemechanisme te liggen. Het kan er bijvoorbeeld ook aan liggen dat op een webserver is ingebroken of omdat een beheerder heeft geblunderd met de configuratie. Dat soort dingen heeft een CA niet in de hand, daarvoor moet je bij de beheerder van die webserver zijn.

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.
09-09-2022, 13:59 door Anoniem
Door Anoniem: Het verbaast mij dat OCSP stapling niet wordt genoemd.
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.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.