Zullen wel de gratis certificaten zijn zoals startssl

Sorry, maar dit is nu het zoveelste teken aan de wand dat X.509 failliet is. CRL werkte eerst niet en OCSP zou dat moeten oplossen, maar ook niet. En nu gaan we blacklists bijhouden in een browser? Sorry, we leven in 2011 en niet meer ergens in de jaren '90 ofzo.

De tijd is echt gekomen om dit naar DNSSEC te verhuizen samen met nog veel meer issues. Iedereen kan dan zijn eigen certificaten gaan publiceren die te vertrouwen zijn zonder dat het veel kost. Veel voorzieningen zijn er al gelukkig, maar wie maakt de eerste stap.

Huh? Ligt dit aan X509 of aan hoe de verschillende partijen ermee omgaan?
Je kunt wel zeggen dat we het blijkbaar heel erg moeilijk vinden om het goed te doen.
En je zult zien: slordig toepassen van elk alternatief is mogelijk, ook DNSSEC. En er zullen dus altijd types zijn die het op die manier voor de rest verpesten.

En waarom zou ik jouw certificaten vertrouwen? Welke procedures heb je daarvoor ingericht? Je blijft, ook in jouw opzet, afhankelijk van OCSP/ CRL, of heb jij betrouwbare certificaten waar nooit wat mee aan de hand is? Hoe communiceer je anders de updates? Kortom, leg eens uit hoe je jouw architectuur voor je ziet?

Ik heb het vermoeden dat het certificaten van Usertrust zijn (reseller van Comodo). Niks tegen StartSSL / Startcom, de eigenaar (Eddy Nigg) heeft zelf ook nog een foutje van de concurrent Comodo gerapporteerd: https://bugzilla.mozilla.org/show_bug.cgi?id=470897

Mozilla heeft ook een paar certificaten blacklisted. De bug is private, maar de veranderingen zijn duidelijk zichtbaar in de code repository.

Er zijn 9 certificaten blacklisted, en het lijkt erop dat elke vendor zijn eigen test certs heeft.

Veranderingen in Chromium (testcert: 07 7a 59 bc d5 34 59 60 1c a6 90 72 67 a6 dd 1c):
http://src.chromium.org/viewvc/chrome/branches/648/src/net/base/x509_certificate.cc?r1=78752&r2=72321&sortby=date
Dezelfde certificaten in Mozilla (testcert: 72 03 21 05 c5 0c 08 57 3d 8e a5 30 4e fe e8 b0):
http://hg.mozilla.org/releases/mozilla-2.0/rev/afbc0b4fd618

De overige certificaten:
04 7e cb e9 fc a5 5f 7b d0 9e ae 36 e1 0c ae 1e
39 2a 43 4f 0e 07 df 1f 8a a3 05 de 34 e0 c2 29
3e 75 ce d4 6b 69 30 21 21 88 30 ae 86 a8 2a 71
92 39 d5 34 8f 40 d1 69 5a 74 54 70 e1 f2 3f 43
b0 b7 13 3e d0 96 f9 b5 6f ae 91 c8 74 bd 3a c0
d7 55 8f da f5 f1 10 5b b2 13 28 2b 70 77 29 a3
d8 f3 5f 4e b7 87 2b 2d ab 06 92 e3 15 38 2f b0
e9 02 8b 95 78 e4 15 dc 1a 71 0a 2b 88 15 44 47
f5 c8 6a f3 61 62 f1 3a 64 f5 4f 6d c9 58 7c 06

opmerking: dit is mijn eigen onderzoek en interpretatie van de veranderingen

Naar aanleiding van nog meer incidenten zal ik misschien uit de doeken doen waar ik op doel en het heeft niets met self-signed certificaten te maken.

Je kan nu al oa fingerprints van X.509 certificaten in DNS opnemen waardoor je kan verifiëren of een certificaat bij bv een A of CNAME hoort. Door dit te verhuizen naar DNSSEC kan je op basis van het vertrouwen van de root-key voor DNSSEC uit eindelijk bepalen of de informatie uit DNS te vertrouwen is. Hiermee kan je dus ook heel gericht controleren of certificaten kloppen ipv de partij op te bellen en vragen of de fingerprint klopt. Hiermee is oa CRL direct buiten spel gezet, want veel clients als ze het al vragen, doen dit maar een keer per dag. Een update in DNS kan heel snel en direct en zet dus oude cq foutieve certificaten heel snel buiten spel.

Hiermee zijn de problemen met X.509 nog niet over. Er zijn nog voldoende servers die MD2 hashing accepteren en hier zijn voldoende problemen mee om deze certificaten buiten spel te zetten door hun belachelijke expiretimes. Oude Verisign certificaten leveren al voldoende problemen op net zoals root-certificaten die geen duidelijke eigenaar hebben, maar wel elke keer worden verscheept.

Daarbij heb je ook nog het probleem van meerdere roots, want wie moet je vertrouwen? Daarbij wie vertelt dat er niet stiekem een root-certificaat wordt uitgeleend aan bv overheden? De mogelijkheden worden dan ineens ongekend, want zeker als je client-certificaten gebruikt om authenticatie te doen. Iets waarbij een image replay ook een leuke aanvalvector is en waarbij MD2 al een bruikbare .

Kortom er zijn voldoende alternatieven, maar de belangrijkste is vertrouwen hebben in de oplossing. Eigenlijk is DNSSEC al zeker drie a vier jaar te laat, want het is beter om maar een enkele centrale key te vertrouwen en te onderhouden. Maar X.509 in zijn huidige vorm gaat in ieder geval tot een einde komen. De vraag is alleen maar hoe.