Let's Encrypt stopt wegens privacyrisico's met OCSP-support (2024)

Reageer met quote

Oorspronkelijke doel van https servercertificaten

Aanvankelijk was het doel van https servercertificaten tweeledig:

1) Authenticatie
Doel 1: aantonen dat de browser verbinding heeft met de bedoelde website van een specifieke eigenaar, die door de internetter wordt vertrouwd - door drie essentiële attributen op te nemen in zo'n certificaat:
1.a) Identificerende gegevens van de eigenaar van de server(s) met de gegeven domeinnaam of -namen;
1.b) Domeinnaam (of domeinnamen);
1.c) Public key (de bijpassende private key bevindt zich op de server).

Vaak is dat vertrouwen gebaseerd op reputatie van de eigenaar (zoals bij ing.nl of digid.nl). Toegegeven, ook zonder dat je precies weet wie de eigenaar is, kan een domeinnaam een reputatie opbouwen (denk aan security.nl of bol.com), maar effectief is dat dan de "naam van de organisatie" die mensen onthouden (waarbij het vertrouwen daarin groter wordt naarmate een domeinnaam langer bestaat en zelden of nooit negatief in het nieuws komt).

2) Encryptie (van de sessiesleutel)
Doel 2: het versleuteld naar de client sturen van een, door de server gegenereerde, symmetrische sessie-encryptiesleutel. Dat gebeurde door de, random door de client verzonnen symmetrische (AES bijvoorbeeld) sessiesleutel te versleutelen met de public key uit het servercertificaat.

Dankzij asymetrische encryptie kan alleen de bezitter van de private key de versleutelde sessiesleutel decrypten. De client kan die versleutelde sessiesleutel dus veilig naar de server sturen (over de dan nog onversleutelde verbinding). De server verkrijgt de gewenste "plain text" sessiesleutel door de versleutelde sessiesleutel met diens private key te ontsleutelen. Daarna kan het datadeel van tussen de server en client (en vice versa) uitgewisselde TCP/IP pakketjes door de verzender worden versleuteld en door de ontvanger worden ontsleuteld.

Punt 2 hierboven vervalt door forward secrecy

Sinds forward secrecy wordt gebruikt (middels het Diffie Hellman key-agreement algoritme (*)), zijn we (jaren geleden) gestopt met punt 2.

(*) Vereenvoudigd uitgelegd wordt, bij forward secrecy, voor élke sessie een, éénmalig te gebruiken, asymmetrisch sleutelpaar gegenereerd, bijv. door de server - die de public key daarvan naar de client stuurt. De client verzint een random symmetrische sessiesleutel en versleutelt deze met de public key uit het éénmalig gebruikte sleutelpaar - dus in plaats van met de public key uit het certificaat, dat voorheen langdurig (maanden of jaren) tevens voor dit doel (2) werd gebruikt. Daarna gaat het verder zoals uitgelegd onder punt 2 vanaf "Dankzij asymetrische encryptie ...".

Doel van forward secrecy

Het doel van forward secrecy is het voorkómen dat éérder afgeluisterde en opgeslagen versleutelde sessiedata, op een later tijdstip kan worden ontsleuteld, namelijk op het moment dat de langdurig geldige private key (horend bij een public key in een certificaat) in handen van de bezitters van (indirect met die private key) opgeslagen versleutelde sessiedata valt. Daarbij moet vooral aan geheime diensten worden gedacht.

Voordelen van authenticate-only certs

Door certificaten géén onderdeel meer te laten zijn van de versleuteling van de sessie, worden twee vliegen in één klap geslagen (die tweede duurde wat langer, nl. tot de introductie van TLS v1.3):

a) Forward secrecy
Zoals gezegd, je realiseert forward secrecy (d.w.z., met een gelekte of opgeëiste private key kunnen geheime diensten en/of kwaadwillenden geen eerder opgeslagen versleutelde sessiedata decrypten);

b) Certificaat geheel niet meer zichtbaar "op de lijn"
Er kan gewacht worden met het door de server naar de client sturen van het servercertificaat (en intermediate certificaten) totdat de verbinding is versleuteld - hetgeen de privacy ten goede *kan* komen. Overigens nauwelijks, want IP-adressen in netwerkpakketjes worden niet versleuteld door https (uitgezonderd bij "SSL-VPN's - maar zo'n VPN eindigt altijd ergens vóór de webserver). En bij IP-adressen waar vele domeinnamen achter zitten, heb je het kip-ei probleem dat de browser aan die server zal moeten vertellen met welke domeinnaam deze verbinding wil maken. Anyway, het vormt een praktisch bewijs dat certificaten geen onderdeel meer uitmaken van het proces om verbindingen te versleutelen.

Aanpak om doel 1 te bereiken

Wat je ook doet, doel 1 zal nooit met 100% betrouwbaarheid worden bereikt.

De manier waarop certificaten worden uitgegeven, moet ertoe leiden dat elke (van álle) door internetters vertrouwde certificaatuitgever pas een certificaat uitgeeft nadat die certificaatuitgever (op de, voor genoemde internetters, minimale en voldoende betrouwbare wijze) heeft vastgesteld dat:

a) De domeinnaam/namen van de aanvrager zijn
De domeinnaam/namen in de certificaataanvraag allen leiden naar één of meer servers "die van de aanvrager zijn" (meestal zijn ze gehuurd, de aanvrager moet aantonen een specifieke schrijftoegang te hebben tot die server(s). Er bestaan ook andere protocollen voor deze "Domein Validatie").

b) Optionele, naar verantwoordelijken herleidbare identificerende gegevens correct zijn
Optioneel, doch essentieel voor kritische (risicovolle qua uitgewisselde info) websites: met (meer of minder vergaande) eisen gesteld aan de betrouwbaarheid ervan: de certificaataanvrager toont aan wie zijn of hij zegt te zijn - én, indien van toepassing, de aanvrager toont aan (met minimaal gelijkwaardige betrouwbaarheid) dat deze door de, in het certificaat genoemde, organisatie geautoriseerd is om dat certificaat aan te vragen.

M.b.t. punt b: deze aanvullende identificerende gegevens zijn simpelweg noodzakelijk voor kritische websites, omdat géén enkel normaal mens van alle ooit eerder bezochte sites de exacte (en volledige, inclusief TLD) domeinnaam kan onthouden, en bij (mogelijk) niet eerder bezochte websites met onbekende (of niet herinnerde) domeinnamen, daaruit met voldoende zekerheid kan herleiden wie de verantwoordelijke daarvoor is.

Als aan de gestelde minimale betrouwbaarheidseisen wordt voldaan (en de uitgever diverse metadata heeft toegevoegd aan de aanvraag), zet de certificaatuitgever een digitale handtekening onder de certificaataanvraag waamee het, in principe, een geldig certificaat is geworden (bij CT, Certificate Transparency, zijn counter-signatures, gezet door andere certuitgevers, noodzakelijk om een certificaat geldig te laten zijn).

Reden voor doel 1

De reden om certificaatverstrekkers (derde partijen die moeten worden vertrouwd door internetters) de identiteit van aanvragers te laten checken, is dat:

Niet elke individuele internetter dat zelf maar voor elkaar moet zien te krijgen.

Iets dat totaal niet schaalt en in de praktijk simpelweg onmogelijk gemaakt is (zelfs whois vertelt je alleen nog maar "Redacted for privacy reasons").

De primaire voorwaarde voor elke individuele internetter voor dit systeem is dat zij elke (allemaal dus) certificaatuitgever van de in de browsers en/of besturingssystemen op hun apparaten opgenomen rootcertificaten moet vertrouwen, en dat dit vertrouwen terecht is.

Terug naar jouw stelling

Een MitM kan een eigen certificaat laten maken. Dat is juist het probleem [...]

De essentie van, of, zo je wilt - het ontlenen van haar bestaansrecht aan, het publieke (op PKI gebaseerde) certificatensysteem is precies het voorkómen dat kwaadwillenden, als MitM's, identiteitsfraude kunnen plegen.

Daarbij moet worden opgemerkt dat DV-certiticaten niet alleen grotendeels waardeloos zijn voor internetters omdat zij totaal geen info bevatten over de identiteit van de verantwoordelijke voor een domeinnaam, maar óók omdat DV-certificaten in steeds meer gedocumenteerde gevallen aan MitM's, onrechtmatige domeinnaamkapers, zijn verstrekt.

Notabene exact de reden waarom, aldus de DV-fanclub, allerlei uitgevers van OV, EV en QWA-certificaten zouden hebben gefaald (dat deden ze, maar de pot verwijt de ketel) en zúllen falen.

Probleem: de slager keurt diens eigen vlees - bestemd voor consumenten.