Certificaatautoriteit Let's Encrypt gestopt met support van OCSP
Certificaatautoriteit Let's Encrypt is gestopt met de support van het Online Certificate Status Protocol (OCSP). Volgens de certificaataanbieder vormt OCSP een groot risico voor de privacy op internet. Daarnaast wil Let's Encrypt de eigen infrastructuur zo eenvoudig mogelijk houden. De ondersteuning van OCSP nam aanzienlijke middelen in beslag die beter zijn te besteden aan andere onderdelen van de operatie, aldus Josh Aas, directeur van de Internet Security Research Group (ISRG), de organisatie achter Let's Encrypt.
Tls-certificaten, zoals Let's Encrypt uitgeeft, 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.
Informatie over ingetrokken tls-certificaten moet aan de browser van gebruikers 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 die de OCSP responder beheert daarnaast bijhouden welke websites iemand vanaf een bepaald ip-adres bezoekt. "Zelfs wanneer een certificaatautoriteit deze informatie bewust niet bewaart, zoals het geval is met Let's Encrypt, kan het per ongeluk worden bewaard of kunnen certificaatautoriteiten juridisch worden gedwongen om het te verzamelen. CRLs hebben dit probleem niet", aldus Aas.
Daarnaast nam OCSP volgens de ISRG-directeur ook aanzienlijke middelen in beslag en voegde complexiteit toe aan de infrastructuur van Let's Encrypt. "Op het hoogtepunt van het verkeer van de OCSP-service verwerkten we 340 miljard OCSP requests per maand. Dat is meer dan 140.000 requests per seconde verwerkt door ons content delivery network, met 15.000 requests per seconde verwerkt door onze herkomst."
In het artikel staat de argumentatie voor die risico-inschatting.
Op welke argumenten is jouw claim gebaseerd?
Omdat OV en EV praktisch verdwenen is, dient een certificaat enkel nog om de TLS verbinding te beveiligen.
En dit systeem introduceert extra kwetsbaarheden bovenop de registrar en webserver zelf:
- Alle Certificate Authorities. (CAA en CT zijn lapmiddelen)
- De internet verbinding tussen de server en CA. (Certificaat via HTTP challenge)
- De internet verbinding tussen de DNS en CA. (Certificaat via DNS challenge, indien geen DNSSEC)
Ik denk dat DNSSEC+DANE dit probleem oplost omdat dat de hele CA middle-man eruit sloopt.
Het OV en EV gedeelte van certificaten kan een plek krijgen in ./well-known/identity.crt.
Daar mag het dan een persoon of organisatie identificeren zonder noodzaak om private keys veilig te houden.
(Maar Erik is het niet eens met deze oplossing.)
In het artikel staat de argumentatie voor die risico-inschatting.
Op welke argumenten is jouw claim gebaseerd?
Op notabene dezelfde dag verstrekte LE, onterecht, minstens 34 certificaten aan cybercriminelen voor [*.]dydx.exchange. De cybercriminelen kregen dit voor elkaar middels een BGP-hijack (waar Josh Aas liever over zwijgt) [NOOT: zie de correctie onderaan].
Van die 34 certificaten heeft LE er, meer dan 6 uur later, 27 ingetrokken.
Waarom het zo lang duurde, en waarom slechts 27 van 34, weet ik niet.
FEIT: OCSP werkt instantaan. Bij dit soort calamiteiten kan OCSP het aantal slachtoffers aanzienlijk beperken.
Alle details lees je in mijn rapportage (Engelstalig) in https://infosec.exchange/@ErikvanStraten/112914047006977222.
En zoals je in die draad kunt lezen, was dit allesbehalve het enige incident waarbij LE onterecht certificaten uitgaf (nog even los van hun medeplichtigheid aan phishing en andere cybercriminaliteit).
Aanvulling 13:59: het privacy-argument is volstrekte bullshit. Iedereen die bijv. NoScript gebruikt, weet dat de mensen die niet zoiets als NoScript gebruiken, nul privacy hebben. O.a. LE-vriend (en sponsor) Google weet alles van hen.
Daarnaast zou de enkeling die denkt dat OCSP een afschuwelijke inbreuk op diens privacy vormt, zélf OCSP kunnen uitzetten (of een browser van een maker gebruiken die sowieso niet in OCSP gelooft, zoals Chrome - veel succes gewenst met jouw gewonnen privacy).
En NoScript helpt niet tegen Cloudflare (die dankzij DV-certs alle https-verbindingen openbreekt, zie bijv. https://infosec.exchange/@ErikvanStraten/114981460517174434), een rap groeiend risico met malloten als Trump aan de macht.
Ook de paar kolossale (plus enorme aantallen kleinere) hosting/cloud providers kijken heus niet een andere kant op.
Vroeger betekende TLS dat je E2EE had, met als endpoints jouw browser en een server van een door jou vertouwde partij.
DV heeft dat allemaal kapotgemaakt. Het internet is er allesbehalve veiliger door geworden. En dat was 100% by design - door Big Tech, Google en Cloudflare voorop.
Aanvulling 14:07: FIDO2 harware keys (zoals Yubikey) en passkeys zijn KANSLOOS bij nepsites met onterecht verkregen certificaten.
Diginotar moest dood na onterecht certificaten te hebben uitgegeven. LE flierefluit vrolijk verder, samen met andere big tech die van internet één grote criminele bende maken.
Correctie 14:17: dat cybercriminelen nepservers voor [*.]dydx.exchange konden opzetten, kwam niet door een BGP-hijack (mijn exuses, ik was in de war met een andere aanval) maar door ongeautoriseerde schrijftoegang tot DNS-records (iets dat vaker vóórkomt dan BGP-omleidingen). DV maakt website-certificaten 1FA.
Wel heeft OCSP het probleem dat daarmee een enkele (zeer grote) CA inzicht krijgt in het browse-gedrag van gebruikers (en systemen) omdat elk certificaat gecontroleerd moet worden. OCSP stapling zou dit deels kunnen voorkomen (hoewel dit niet voorkomt dat een CA nog steeds weet welke sites je hebt bezocht, aleen niet hoe vaak).
Je bent niet ingelogd 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.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?