Dat is lood om oud ijzer. In plaats dat we nu allemaal "vertrouwen" op Comodo, moeten we ook nog eens gaan vertrouwen op Google.

Een betere oplossing kan alleen door fysieke beveiliging worden gedaan. De certificaten signen en de root certificaten van Comodo en de zijnen moeten in een geisoleerde omgeving komen te staan. Er mag beslist geen mogelijkheden bestaan om via het Internet bij deze twee onderdelen te komen. Alleen geauthoriseerde mensen kunnen met een medium (papieren formulier, cd, usb stick, etc) een csr inleveren.

Hierdoor beperk je het risico dat miljarden mensen via het Internet toegang verschaffen tot je systeem. Slechts een aantal gescreende personen kunnen een csr signen.

Het gevolg is dat er ongetwijfeld lange verwerkingstijden zullen ontstaan voor het aanvragen van certificaten. Dat is de prijs die je betaald voor security.

Sorry SL600, maar het model wat je nu juist beschrijft is juist het model wat gebroken is en eigenlijk al jaren stuk is. Het probleem van X.509 is gewoon een design fout, een grove design fout zelfs. De tijd van X.509 in zijn huidige vorm is over. De rek is eruit. Het is dood, maar niemand beseft het nog echt. Dit trucje wordt door sommige overheden al jaren gebruikt en iedereen valt over Comodo, maar Verisign is nog veel erger door hier bewust aan mee te werken.

Het lapmiddelen van oa een black/whitelist in DNS is gewoon niet schaalbaar. Elke DNSBL-beheerder weet dat al jaren en is eigenlijk gewoon ook gewoon een deadend. Het DANE voorstel is een uitbreiding op bestaande records in DNS die niemand nog gebruikt helaas, maar veel zinvoller en veel beter te schalen. Zeker omdat het dan ook redelijk decentraal is, maar m.b.v. DNSSEC wel goed te beveiligen is.

Je zou hiermee zelfs selfsigned certificaten helemaal veilig kunnen maken en zonder geneuzel kunnen laten werken. Hier zie je ineens ook het probleem. De geldmachine voor CAs is dan verdwenen. Iedereen kan kosteloos zijn verbindingen beveiligen en veilig houden. Hier zit wel een klein puntje zeg maar. Een kleintje maar.

Ik ben het niet helemaal eens dat het een design fout is. SSL is niet alleen encryptie wat jij voornamelijk aanwijst. SSL is ook authenticiteit. Als je een ssl verbinding met een bank maakt, dan wil je kunnen aannemen dat het ook de bank is aan de andere kant van de verbinding. De authenticiteit (echtheid) kan alleen afgegeven worden door, in dit geval de bank zelf. Maar omdat een bank alleen bezig is met geld verdienen, besteedt deze de echtheidafgifte uit aan bijv. comodo. Dus het is een echtheid afgegeven door een derde partij. Dat neemt niet weg dat het niet correct is.

Dus het feit dat Comodo of Verisign niet goed de zaak heeft beveiligd heeft dus alleen betrekking op hun implementatie/uitwerking van de signing process en niet zo zeer met de design fout in SSL.

Wat ik slechts voorstel, is dat de uitgegeven certificaten, root certificaten, etc niet op een locatie gezet wordt die on-line te benaderen valt.

@SL600: Sorry, maar er zitten een aantal flaws in je stukje.

Ik wijs nergens SSL aan, maar X.509 en dat is totaal iets anders. SSL beslaat voornamelijk de transport en encryptie laag. X.509 beschrijft laag waarin je beschrijft van wie de public key is, welke fingerprint deze heeft en welke partij garant staat dat die public key en fingerprint bij die persoon/organisatie horen. En hier komt ook de flaw in het design. X.509 is zo opgezet dat elke gek dat kan doen en ook wordt gedaan. De vraag is alleen wie je kan overtuigen om jou root-key te distribueren, zoals in oa elk OS en browser, zodat mensen niet zelf hoeven te controleren of een certificaat correct is.

Hier komt ook het probleem. Verisign heeft het oa wel goed beveiligd, maar leent gewoon zijn root-keys uit aan oa de Amerikaanse overheid. Hier kan geen netwerkscheiding tegen op hoor. Of hoeveel installaties accepteren nog client certificaten met een MD2 hash? Te veel en een image replay is hiervoor is redelijk goed te doen met de huidige stand van de techniek. MD5 is een kwestie van enkele jaren hoor.

Maar hoe wil je deze certificaten intrekken? Niet, want ze zijn geldig tot hun expiredatum en voor sommige is dat nog 20+ jaar in de toekomst en CRL en OCSP werken gewoon niet omdat het blacklists zijn en niet whitelists. En dat is als mensen deze al gebruiken. Het idee van Google is leuk, maar schaalt gewoon niet. Ze het aan in Chrome, Firefox en IE en je krijgt een hoeveelheid DNS queries naar een "centrale" infra waar de hoeveelheid queries van oa Spamhaus, SORBS en UCEPROTECT nog kleintjes bij zijn. Los van het feit of het software technisch kan.

Kijk je naar alternatieven dan komt ineens bv het SSHFP record in beeld. RFC 4255 voor geïnteresseerden. En hier kan in een zone worden aangegeven welke SSH Host Fingerprints er bij een bepaalde host horen. Onderteken dit met DNSSEC en zorg dat de chain vanaf de root-zone correct is en je hoeft alleen de keys van de root-zone te vertrouwen. Deze records zijn er ook al lang voor bv OpenPGP-keys of de bekende en geplaagde X.509 certificaten. Hier speelt oa DANE op in.

De vraag is dan wat voor meerwaarde een CA gaat leveren. Die is eigenlijk nul, zero, nada. Bij de standaard certificaten op internet moet je plechtig beloven dat jij jij bent via een telefoon en e-mail en zonder verdere checks. Maar wel de mogelijkheid dat andere certificaten op jou naam kunnen aanvragen. Deze loophole moet eruit worden gehaald. De meerdere root-keys die er nu zijn voor certificaten zijn gewoon het probleem. Ze doen niet meer dan wat je zelf ook kan met de juiste entries in DNS eigenlijk. Nu nog client support en daar gaat een paar jaar overheen helaas.

Dit is ook de grap aan DNSSEC. Jij beheert je eigen keys en de registry zegt dat de keys bij een zone en nameserverset horen te correct zijn. De root-keys kunnen totaal geen invloed uitoefenen op jou data of men moet een gehele zone bij je weghalen, maar daarvoor zijn wel jou keys nodig en mogelijk ook een key-rollover in sommige gevallen. Geheel vlekkeloos zal dit niet gaan. Hier komen nieuwe uitdagingen, maar de scope daarvan is beperkter en heeft minder impact als wat de gevaren nu zijn.

En voor jou informatie. Het signen van certificaten gebeurt ook niet online. Als dat wel zo is komt men niet door de auditprocedure heen die elke leverancier die ze gaat meeleveren eist. Als je dit proces in het publiek wilt bekijken dan geeft CAcert daar voldoende informatie over. En over banken en certificaten. Elke bank heeft deze infra hoor en gebruikt die ook, maar het is goedkoper om een certificaat voor extern gebruik te laten tekenen door een grote partij dan door jezelf te laten opnemen in elke OSjes op deze aarde. Het risico van klantverlies door een certificaat waarschuwing te gewoon te groot.

Maar nogmaals, het is niet een fout in SSL, maar in X.509. Het was een mooi idee, maar niet over nagedacht over hoe de toekomst zou ontwikkelen. Aan de andere kant identity management op internet staat nog in de kinderschoenen, maar dat is een ander verhaal en probleem. We staan pas aan de vooravond van veel veranderingen en elke oplossing die centraal georganiseerd is zal breken na enkele jaren. Meestal na de eerste grote storing. Ik wacht ook met smart en angst en beven op de dag dat bv Google er gewoon niet is op die dag. Maar nogmaals dit is een ander verhaal.