Het systeem mag dan aan alle kanten rammelen een beter alternatief is er niet. Dus zolang de rotte appels er snel uitgehaald worden blijft het systeem zelf nog redelijk betrouwbaar.

Ik zie toch duidelijk wel verbeterpunten aan het systeem, dus heb ik helaas moeten stemmen op "tijd voor een nieuw systeem". de rotte appels er uithalen lijkt me een redelijk lastige klus en zal weinig verbeteren aan het vertrouwen. Diginotar gaf zelf ook al aan als trusted party dat er slechts enkele certificaten vervalst waren en dat alles inmiddels onder controle is.

Vertrouwen is goed, controleren is beter. er moeten veel meer controle mogelijkheden in het systeem komen. eenvoudige (ahum lol) rekensommetjes die bepalen of een certificaat wel echt is ondertekend door een ander certificaat zegt dus uiteindelijk niet veel meer. revocation lists, wat wil je revoken als je niet eens weet dat je het hebt uitgegeven? dus ik pleit ook voor een check bij de CA of deze het uitgegeven certificaat wel kent.

Tot slot zou het uiteindelijk de keuze van de gebruiker moeten zijn (eigenlijk is dit ook al wel zo) of hij/zij akkoord gaat met het feit dat het certificaat 'momenteel' niet kan worden gecontroleerd. en niet in de ingebakken lijst met rootCA's kijken of het rekenkundig allemaal wel klopt(by default).

Gezien dit bericht:
http://www.security.nl/artikel/38372/1/Iraanse_student_hackte_DigiNotar.html

Weet je dus niet wie of wat er nog te vertrouwen is.

De grote hamvraag blijft dan, hoe zou dat nieuwe systeem er uit moeten zien?

Ik was in de veronderstelling dat ik een en ander aan verbeterpuntjes reeds in mijn vorige post had benoemd, kennelijk niet duidelijk genoeg beschreven :-).

Ik ben van mening dat het certificatensysteem een goed systeem is, maar er zijn nu een paar duidelijke tekortkomingen pijnlijk naar boven gekomen welke eigenlijk dicteren dat het "vertrouwen" toch misplaatst blijkt.

De eerste en voornaamste tekortkoming is dat een certificaat geldig is omdat het certificaat dat zegt, en omdat het certificaat een stempeltje heeft van een vertrouwde CA word dus maar aangenomen dat alles in kannen en kruiken is. Maar als de vertrouwde CA niet eens weet dat zij dit certificaat hebben ondertekend blijft het certificaat gewoon geldig omdat het certificaat dat zegt.

Mijns inziens dient het certificatensysteem te worden uitgebreid met real time checks.

- kent de uitgever het certificaat? -> Ja/Nee
- is het certificaat nog geldig? (CRL) -> Ja/Nee
- ...

Domeinbeheerders zouden beschikking moeten krijgen over querytools welke ze in staat stelt eenvoudig af te vragen of een CA certificaten host onder zijn/haar domeinnaam ->Ja/Nee

Er zijn er meer, uiteindelijk blijft het een zaak van vertrouwen dus is het van belang dat het vertrouwen gecontroleerd kan worden. hierin zie ik ook een rol van de domeinbeheerders zelf, de domeinbeheerder wil mij uiteindelijk overtuigen dat ik met de juiste server communiceer dus zullen zij hun kennis van de eigen infrastructuur ook moeten gebruiken om regelmatig te controleren of er geen valse identiteiten in omloop zijn.

En uiteindelijk wringt daar de schoen en is jouw systeem niet veel beter dan wat we nu al hebben. Ook bij jouw oplossing is het mogelijk dat een rogue (of gekraakte) root CA wordt vertrouwd. Daar verandert die ene extra controle niets aan (CRL's kunnen nu ook al gebruikt worden).

In die veronderstelling kun je dus niks vertrouwen, en dat is toch wel de basis van het certificaten systeem.

CRL's zijn statische lijsten met ingetrokken certificaten, als de gecompromitteerde CA het bestaan van de rogue certificaten niet kent kan de CA deze certificaten ook moeilijk intrekken toch? dus blijft er een geldig certificaat over. Door de check "Ken jij dit certificaat?" kun je dit probleem dus ondervangen.

Zoals je zelf al aangeeft, een beter alternatief is er niet op dit moment. Maar daarom hoef je niet achterover te gaan zitten en de ontdekte problemen/fouten van het systeem maar te laten voor wat ze zijn.

Nee, want er staat een rogue CA niets in de weg om te zeggen dat ze dat certificaat kennen.

Het probleem is niet valse certificaten, die kun je immers terugtrekken. Iets wat nu ook al kan. Het probleem is het vertrouwen dat je moet hebben in die root CA's. In het verleden, en ook nu weer, is gebleken dat dat vertrouwen wel eens onterecht kan zijn.

Dan is er nu toch weinig aan de hand en kan Diginotar gewoon de foute certificaten intrekken?

Dat hebben ze in eerste instantie ook gedaan. Maar door aanhoudende problemen bij Diginotar is het vertrouwen in dat bedrijf in z'n geheel opgezegd.

DNSSEC lijkt mij een prima alternatief voor één van de toepassingen van certificaten: zekerheid of er gecommuniceerd wordt met de juiste host. Met deze zekerheid kan eenvoudig een encryptie-methode worden gekozen voor de beveiliging van de data die uitgewisseld wordt tussen beide systemen.

Niet echt. Het enige wat je dan redelijk zeker weet is dat het IP adres klopt. Het doet niets met de communicatie tussen jouw IP adres en dat van de server.


En hoe wilde je dat doen? Met certificaten ofzo? Ow, wacht...

@SirDice Toch kan DNSSEC wel helpen, want je kunt namelijk een fingerprint van het certificate in DNS zetten, waarvan je via DNSSEC kunt controleren dat het ook geldige data is.

Als de fingerprint (gesigned) in DNS staat dan kan de browser dus alle andere CA's, etc. negeren die beweren dat ze geldig zijn voor het betreffende domein.

Er zijn een aantal voorstellen om een fingerprint in DNS te zetten en te signen met DNSSEC, meest waarschijnlijke die het haalt is DANE.

Wat ook een nuttige toevoeging is: http://convergence.io/ zie ook de video van de maker: http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Simpele vraag, wie zet die fingerprint in DNSSEC?

de beheerder van de desbetreffende DNS zone.

Ja, de TLD kan je domein redirecten, en dat is een potentieel probleem, maar daar heb je nu ook al geen echte bescherming tegen.

Dat is leuk als je je eigen zone beheert maar voor het gros gaat dat niet werken.