CRLite is een innovatieve techniek op de wat onbekendere bloomfilter datastructuur. Helaas lijkt er weinig animo te zijn om OCSP Stapling en Must-Staple volledig uit te rollen. De keuze om OCSP nu volledig te vervangen door CRLite is vanwege de privacy implicaties dan ook wel te begrijpen.

Àl die browsers hebben zo een totale paniekpagina. Als er per ongeluk eens een certificaat verlopen is. Je mag dan enkel Op Eigen Risico door. Als dat al mag van je browser. Het lijkt wel of de Russen en de Chinezen tot aan de tanden bewapend voor je deur staan!

Kijk, ik vind security ook heel belangrijk hoor. Daar niet van. Maar je kunt ook overdrijven.

Daarnaast, als vrijwel geheel gratispaginaleverancier kost het me wel traffic op mijn kittige websitejes. Allemaal lieve bezoekers doodsbang gemaakt, dat ze misschien gehekt en gespoeft zijn, met paniek om niks, stelletje securitylullos met nul gevoel voor emoties!

Brengt het lokaal opslaan van de revocation list niet allerlei security risico's met zich mee?

Of je fixt gewoon even een certificaat..

Ik herinner mij m'n werk op een servicedesk.

"Oke meneer, nu gaat u Outlook aanklikken en dan gaat de foutmelding waar u last van heeft in beeld komen. Ik wil graag dat u dan niet doorklikt, dan kan ik de foutmelding lezen."

Zelfs met die disclaimer, kan een gebruiker die je 5 minuten moet uitleggen waar de start knop zich bevindt in Windows, de knop om een foutmelding weg te klikken in een picoseconde vinden en aanklikken.

En dat is de reden dat er zoveel toeters en bellen nodig zijn.

neerleggen, en weer achteraan in de telefoonrij laten aansluiten....

Dat is uiterst onhandig geformuleerd: bij moderne TLS-verbindingen, waarbij gebruik gemaakt wordt van "forward secrecy", heeft het TLS servercertificaat NIETS meer te maken met de versleuteling van TLS-verbindingen.

Reden: als een veiligheidsdienst of criminelen versleuteld verkeer tussen de server en één of meer clients opslaan, hebben ze daar (nagenoeg) niets aan. Echter, zodra zij de eigenaar van de server met succes hebben gedwongen om diens private key af te staan, kunnen zij al het eerder opgeslagen versleutelde netwerkverkeer ontsleutelen.

Bij moderne TLS-verbindingen kan dat niet meer doordat het certificaat niets meer met de versleuteling van de verbinding te maken heeft.

SSL- en TLS-verbindingen gebruiken symmetrische versleuteling (de hele verbinding met asymmetrische encryptie versleutelen zou onwerkbaar traag zijn). Bij symmetrische versleuteling wordt dezelfde sleutel zowel door de server als door de client gebruikt, vergelijkbaar met de voordeursleutel: je kunt de deur er zowel mee op slot doen (vergrendelen, versleutelen) als van het slot halen (ontgrendelen, ontsleutelen).

Het probleem is om, als één van de partijen een sleutel verzint, die sleutel veilig bij de tegenpartij te krijgen (ervan uitgaande dat er "meekijkers op de lijn kunnen zitten", passief of zelfs actief). Dat klinkt als een kip-ei probleem, en dat is het ook.

De oplossing, om de symmetrische sleutel ongezien bij de andere partij te krijgen, is asymmetrische cryptografie (zie ook https://security.nl/posting/884482/Public+keys+voor+leken).

Dat betekent dat er sprake is van twee verschillende, aan elkaar gerelateerde, sleutels. Wat je met sleutel A versleutelt, kun je uitsluitend met bijpassende sleutel B ontsleutelen. Andersom kan ook (met B versleutelen en met A ontsleutelen) - maar beide gebruiken wordt afgeraden: als je een asymmetrische sleutel voor versleuteling gebruikt, en dus diens tegenhanger voor ontsleuteling, en je zou die rollen omkeren, bestaat naar verluidt het risico dat de kraakbaarheid wordt vergroot (ik weet te weinig van hoogdravende cryptografie om uit te kunnen leggen waarom).

Tijdens het opzetten van elke ouderwetse SSL-verbinding verzint de client (bijv. de browser) een random symmetrische sleutel. Zodra de client het certificaat van de server ontvangt (en de geldigheid geverifieerd heeft), versleutelt de browser de zelf gegenereerde symmetrische sleutel met de public key uit het certificaat, om vervolgens het "resultaat" naar de server te sturen (via de nog onversleutelde verbinding).

Omdat, als het goed is, uitsluitend de server over de private key (horend bij de public key in het certificaat) beschikt, kan uitsluitend de server eerdergenoemd "resultaat" ontsleutelen, en daarna beschikken over een kopie van de door de client gegenereerde symmetrische sleutel.

Probleem: iedereen die de private key van de server (horend bij de public key in het certificaat) in handen krijgt en een tap op de verbinding heeft, waar versleuteld netwerkverkeer "voorbijkomt", kan niet alleen al het toekomstige netwerkverkeer ontsleutelen, maar ook eerder opgeslagen versleutelde netwerkpakketjes.

Moderne TLS-verbindingen gebuiken het Diffie-Hellman protocol voor Forward Secrecy. Die nogal verwarrende kreet ("forward secrecy") betekent dat, mocht de private key van een server in verkeerde handen vallen, eerder versleutelde (en opgeslagen) verbindingen niet alsnog kunnen worden ontsleuteld ("backward secrecy" had ik persoonlijk logischer gevonden).

Het door Whitfield Diffie en Martin Hellman bedachte protocol is lastig uit te leggen - maar ik probeer het toch. Nb. het volgende is hoe ik begrepen heb hoe de Diffie-Hellman "key agreement" werkt (ook bekend als DHE waarbij de E voor Exchange -van de symmetrische sleutel- staat). Op details kan ik het fout hebben, dit is hoe het zou kunnen werken.

Tijdens het opzetten van elke TLS-verbinding genereren zowel de server als de client een tijdelijk ("ephemeral") (cryptografisch random) asymmetrisch sleutelpaar. De publieke sleutels sturen ze naar elkaar (via de nog niet versleutelde verbinding).

Beide partijen genereren tevens een (cryptografisch) random getal, een onderdeel van de uiteindelijke symmetrische sleutel, versleutelen dat met de ontvangen tijdelijke public key en sturen het "resultaat" naar de andere partij - die dat met de eigen (tijdelijke) private key ontsleutelt.

Beide partijen gebruiken vervolgens hetzelfde algoritme om beide onderdelen van de symmetrische sleutel "te vermengen" - met als resultaat de symmetrische sleutel.

Beide partijen beschikken nu over:
1) De tijdelijke public key van zichzelf;
2) De tijdelijke public key van "de ander" (mogelijk een AitM);
3) Het symmetrische sleutel-onderdeel van zichzelf;
4) Het symmetrische sleutel-onderdeel van "de ander" (mogelijk een AitM);
5) De zelf berekende symmetrische sleutel (uit 3 en 4).

Daarna berekenen beide partijen een (cryptografische) hash over alle bovenenoemde parameters.

Met de symmetrische sleutel, die beide partijen nu hebben, wordt de verbinding vanaf dat moment versleuteld.

Merk op dat er nog niets met het servercertificaat gedaan is. Sterker, bij TLS v1.3 is de verbinding al versleuteld vóórdat de server haar certificaat naar de client stuurt.

Op dit moment tijdens het opzetten van de TLS-tunnel kan er sprake zijn van een AitM (Attacker of Adversary in the Middle). Er is dan sprake van twee verschillende TLS-tunnels:


Nu pas komen het servercertificaat en de private key in beeld:
• De server stuurt diens certificaat naar de client (bij TLS v1.3 over de versleutelde verbinding, waar een AitM tussen zou kunnen zitten);
• De server versleutelt de berekende hash met diens private key en verstuurt het "resultaat" (*) via de versleutelde verbinding (met mogelijke AitM) naar de client;
• De client ontsleutelt het "resultaat", de hash berekend door de server;
• De client vergelijkt de hash berekend door de server met de zelf berekende hash.

(*) Dit "resultaat" staat bekend als een digitale handtekening. Die wordt "gezet" door een hash (berekend over de te ondertekenen gegevens) met een private key te versleutelen. Elke ontvanger die over de bijpassende public key beschikt, kan de digitale handtekening verifiëren door een zelf berekende hash te vergelijken met de hash die je krijgt als je dat "resultaat" ontsleutelt met de public key. Als de ontvanger zeker weet dat de public key van de bedoelde partij is (authenticatie), en aanneemt dat de bijbehorende private key van de ondertekenaar niet in verkeerde handen gevallen is, weet de ontvanger zeker dat de digitale handtekening door de bedoelde partij is gezet.

Omdat alle 5 gehaste parameters cryptografisch random zijn gegenereerd is de kans verwaarloosbaar klein dat een AitM dezelfde parameters als de server heeft gegenereerd. Oftewel, als de hashes overeenkomen kun je een AitM uitsluiten (als er sprake is van een AitM zullen de hashes niet overeenkomen en hoort de client een foutmelding te geven en de verbinding te verbreken).

• Een certificaat is géén vereiste voor een versleutelde verbinding.

• Bij TLS v1.3 verbindingen wordt het servercertificaat pas verzonden nadat de verbinding is versleuteld (hoeveel bewijs wil je hebben dat je géén certificaat nodig hebt voor een versleutelde "veilige" verbinding).

• Het certificaat was altijd al bedoeld voor authenticatie, en dus het voorkómen van AitM-aanvallen. Alleen in de begintijd van SSL (de voorloper van TLS) werd het sleutelpaar, waarvan de public key is opgenomen in het certificaat, gebruikt voor het veilig verzenden van de symmetrische sleutel. Toen kon je zeggen: "certificaten zorgen voor een versleutelde verbinding tussen website en" browser (niet de bezoeker in de zin van een mens). Certificaten hebben echter al vele jaren (sinds DH wordt gebruikt) niets meer met het versleutelen van verbindingen te maken.

De olifant in de kamer bij DV (Domain Validated) certificaten is wél dat de gebruiker van de browser, gegeven een haar of hem onbekende, niet herkende of niet bekeken websitenaam (domeinnaam van een website), met geen mogelijkheid kan vaststellen of de website van de bedoelde eigenaar is - of alsnog van een AitM.

CRLite is een mooie innovatie. 10MB voor 30 miljoen ingetrokken certificaten. Dat is 80/30=2.33 bits per ingetrokken certificaat. Deze efficiëntie dankzij Bloomfilters. https://ieeexplore.ieee.org/document/7958597

Een Bloomfilter lijdt tot valspositieven.

Sectie III uit de link. Met Cascading Bloom Filters kan je FP rate 0 naderen.

Hm - ik weet niet precies wat je bedoelt met 'kraakbaarheid' - die van een enkel bericht, of een volledige compromise waarbij de private key beschikbaar komt ?

Anyway - bij het RSA _wordt_ het geheel ook omgekeerd gebruikt :

De publieke sleutel is publiek bekend, en wordt gebruikt om iets gecrypt te sturen dat alleen door de eigenaar van de private sleutel gedecodeerd kan worden.

Echter : een bericht _signen_ is precies het omgekeerde : de eigenaar van de pivate key codeert het bericht, en het kan alleen met de bijbehorende publieke sleutel gedecodeerd worden .
Succesvol decoderen met die publieke sleutel bewijst dat (alleen) de bezitter van de private key het gecodeerd kon hebben.

Aangezien de sleutel geacht wordt 'publiek' te zijn is kraakbaarheid van een signed bericht een wat vreemd concept .

DIt is de 'hoog-over' samenvatting . RSA heeft _grote_ risico's als je het 'plain' gebruikt en vooral als je pure data aangeleverd door een tegenstander zou signen . Die kan een bericht construeren (op basis van de public key) waarbij de private key lekt.
Misschien is dat waar je iets van gehoord hebt ?

Praktische implementaties signen dus niet een bericht, maar de hash ervan, vullen korte berichten aan met 'padding' tot een minimale lengte en voorkomen zo dat soort valkuilen.

Maar goed : asymmetrisch slaat op het feit dat er twee sleutels , een publieke en een private zijn (met onderlinge relatie) zijn .
Bij RSA kan het 'gebruik' dus symmetrisch gedaan worden (coderen vs signen)