De zwakste schakel van https

Tot slot

Het moge duidelijk zijn: het systeem van certificaat-autoriteiten biedt minder bescherming dan gewenst. Certificaat-autoriteiten worden gehackt, geven per ongeluk valse certificaten uit, of verstrekken tegen betaling root-certificaten - en dat terwijl elke afzonderlijke certificaat-autoriteit een single point of failure is.

Of dat voor de doorsnee internetgebruiker gevaar oplevert, is moeilijk te zeggen. De valse DigiNotar-certificaten zijn gebruikt om Iraanse internetters te bespioneren, mogelijk in opdracht van de Iraanse overheid. In Nederland en België is dat minder waarschijnlijk, hoewel ook cybercriminelen soms valse ssl-certificaten inzetten. Hoe vaak dat gebeurt, is echter onduidelijk.

Ideaal is de huidige situatie in ieder geval niet. Een overstap naar een alternatief gaat echter veel tijd en energie kosten, omdat het stelsel van certificaat-autoriteiten zo is 'ingeburgerd'. Voorlopig lijkt er dus nog geen verandering in te komen - tenzij een groot aantal bedrijven en organisaties zich vrijwillig opwerpt als Convergence-notary en alle internetgebruikers op dat systeem overstappen.

Reacties (68)

allereerst mijn complimenten voor het artikel, zo zou ik graag meer van lezen! (naast het dagelijkse portie news en andere nice to have articles.

Dat er geld wordt verdiend aan certificates is een commercieel aspect van wat veilig zou moeten zijn. Kijk in de basis is https ook veilig, je verkeer is versleuteld met de server in kwestie waarmee je wil communiceren.

Dus ik vind het wat te kort door de bocht dat het allemaal keihard onveliig is. wel ben ik van mening dat er maar een handje vol partijen moet zijn die de Root CA uithangen, en niet 650 clubjes die allemaal kunnen/mogen uitgeven. (en zeker niet tegen een bedrag van 40.000 euro maar alles mag doen wat op internet verboden is.(is op hetzelfde nivo als dat de kluizenmaker maker van de rabobank de codes en sleutels namaakt op bestelling tegen een nader te bepalen bedrag.

Ik zie wel een toegevoegde waarde in ontwikkeling tussen meerdere CA's die geaudit worden en 100% betrouwbaar zijn i.c.m. DNS.

Soort gelijk aan DKIM/SPF wat je voor email gebruikt, je neemt records op in je dns die je echtheid van je mailservers bepalen en daardoor vrijwel zeker bent dat jij de afzender bent. Als je dit combineert met een secure sessie, dan moet het wel heel gek lopen dat je op een verkeerde server uitkomt.

conclusie, https of combinaties hiervan is niet slecht, ik denk dat grote bedrijven is moeten stoppen met al die regeltjes, processen, k*d managers die geen keuzes durven te maken en politieke redenen maar gewoon moeten zorgen dat servers, routers, switches, firewalls geupdate moeten worden met een gezonde password policy en goed beheer. (lees opvoeding/cursussen aan je techneuten en investeren in goede apparatuur icm goede software. (en managers aannemen die snappen waar het (technisch) over gaat, en niet alleen maar proces of business georiënteerd werken)

Daarnaast is het zo dat onbekend maakt onbemind en dat door dit soort artikelen mensen met minder kennis dit ook snappen en er op manager nivo bellen moeten rinkelen om goed naar hun eigen infrastructuur te kijken en daardoor ook maatregelen durven te nemen. (ook in de huidige security omgevingen (met of zonder beperkingen van allerlei en/en/en scenario's)

en dan heb ik het nog niet eens gehad over verschillende landen met verschillende culturen en politieke standpunten, want een techneut kan nog zulke mooie dingen bedenken maar van de politiek wint niemand. (kijk naar aziatische landen en midden oosten en hun internetpolicy en het afschermen ervan), we zijn er nog lang niet waar we zijn willen en de vraag is of we er ooit komen....

wel ben ik van mening dat er maar een handje vol partijen moet zijn die de Root CA uithangen

Als het aan de Amerikanen ligt is het er maar één waarover de Amerikaanse overheid controle heeft en in het kader van Patriot Act mag handelen zoals het ze uitkomt. (wat ze nu ook al doen.)

Minder Root CA maakt het systeem er niet beter of veiliger op, het PKI is in theorie een leuk idee maar praktisch onuitvoerbaar omdat je altijd met mensen te maken hebt.

Ook al geef je financiële garanties (wat veel Root CA doen) is het kennelijk geen motivatie om zaakjes op orde te hebben en te houden.

Uiteindelijk dien je naar een situatie toe te gaan waarbij point2point communicatie veilig is zonder dat daarvoor perse een Root CA voor nodig is.

Wij zijn binnen onze organisatie ook steeds meer aan het kijken naar encryptie en beveiligde verbindingen. ( uiteraard is dit altijd al zo geweest, maar zitten we er nu meer achteraan )

Als organisatie gebruiken wij een SSL VPN oplossing, een Remote Desktop oplossing en verschillende webservers en e-mail servers die we aan de buitenkant hebben hangen. Voor de SSL VPN, Remote Desktop en webservers is het belangrijk dat deze niet af te luisteren zijn door andere personen, waarbij de SSL VPN en RDP wel gemakkelijk gebruikt moeten worden.

Dit alles is lastig, en vooral als je dan hoort dat de certificaten eigenlijk niet te vertrouwen zijn maakt dit het onmogelijk. Beveiliging is nooit 100% dicht, maar je doet toch altijd je best. Je hoopt te kunnen vertrouwen op instanties die claimen jou te beveiligen, maar op de achtergrond bieden ze om wat te verdienen omwegen aan de "vijand", of omdat de klant dit "nodig heeft" en dit "makkelijker" is. Er mag niet zoiets zijn als "gemakkelijker, dus doe maar" in de beveiligings-scene.

Dit is voor ons een noodzaak om te kijken naar een andere methode, waarschijnlijk een die intern ontwikkeld wordt. Dit zal een lastig te implementeren project worden, maar dan hebben we wel zelf de touwtjes in handen.

Jammer dat dit gebeurd, maar dit bewijst maar weer hoe kapitalisme in elkaar steekt.

Heb je gekeken naar de mogelijkheid om zelf certificaten aan te maken?

Voor SSL VPN en RDP zou je die prima kunnen gebruiken, zolang je je (trusted?) clients maar de juiste sleutels mee kan geven. (Ergo: er is geen must om certificaten verstrekt door CA's te gebruiken voor deze doeleinden). Voor je webserver is dit een ander verhaal natuurlijk.

Tsja maar voor je webserver een eigen "techniek" gebruiken is ook vrij zinloos. Voor je webserver moet je dus maar vertrouwen op certificaten.

Ik zie hier ook weer gelijk mensen te ver door schieten. Ja, certificaten hebben problemen, maar de meeste websites zijn ook weer niet zo heel interessant voor een ingewikkelde man in the middle attack. In mijn ogen moet je de wetenschap dat er een risico bestaat, afwegen tegen de mate waarin jou website belangrijke gegevens herbergt. En misschien er voor kiezen eens wat minder informatie op te slaan zodat je klanten bij een eventueel probleem geen essentiële data verliezen.

Als bedrijf waar we op dit moment zo'n half miljoen mensen verblijden met bezigheidstherapie klinkt het probleem erg bekent in de oren. Maar zelf een oplossing in elkaar beunhazen is simpel weg niet een oplossing als je ziet dat grote groepen veiligheidsonderzoekers en universiteiten over de gehele wereld geen sluitende oplossing voor het probleem kunnen vinden waag ik te betwijfelen of een bedrijfje dat wel even lukt...
De beste oplossing is om gebruik te maken van de beschikbare oplossingen en deze zo veilig mogelijk op te zetten, door bijvoorbeeld het aantal CA's dat je vertrouwd te verkleinen. Een van de dingen die wij bijvoorbeeld gedaan hebben is dat wij eigen certificaten genereren op basis van ons root certificaat. Deze certificaten zijn op alle mogelijke wijze beveiligd en kunnen niet zo maar geexporteerd worden. (kan natuurlijk altijd uiteindelijk maar het is niet makkelijk). Op die manier kunnen veel mensen relatief veilig gebruikmaken van de VPN verbindingen RDP is hoe dan ook uit den boze omdat het een hopeloos onveilige oplossing is maar goed dat is een ander verhaal. Ook hebben we een flink netwerk van intrusion protection systemen draaien en worden alle systemen zo wel lokaal als op afstand gescanned op virussen en andere verdachte bestanden. Zelfs een tracking cookie wordt extern herkend en hoeft niet te wachten op de virus scanner om verwijderd te worden.

De gevaren hebben overigens niets met het kapitalisme te maken het is simpel weg de menselijke natuur om altijd meer te willen en groter te worden en dat hoeft lang niet altijd op een manier te gebeuren die door andere als eerlijk beschouwd wordt. Het is simpel weg de manier om meer geld te verzamelen en dat is in de huidige samenleving een manier om status en macht te verzamelen, iets dat mensen al vele eeuwen lang bezighoud.
Kijkend naar de rest van de wereld en de andere systemen zo als het communisme waar men uiteindelijk niets anders deed (macht en geld verzamelen bij de elite) of de koninkrijken van weleer waar precies het zelfde gebeurde en in geen van deze of welke andere voorbeelden dan ook is dat ten alle tijden geheel op algemeen geaccepteerde manier gebeurt. Dus om het kapitalisme hier de schuld van te geven vind ik toch een beetje krom. Ik zou eerder zeggen het is simpel weg zo dat als je 100 mensen geheel willekeurig van de straat plukt er altijd wel een is die bereid is je op de een of andere niet algemeen geaccepteerde manier een paar euro lichter te maken. Ongeacht welke sociale hype een samenleving aanhangt mensen die zich om welke reden dan ook minder aantrekken van het algemene sentiment met betrekking tot wat goed en slecht is hebben altijd en zullen altijd blijven bestaan.

Een eigen methode intern ontwikkelen is waarschijnlijk een stuk minder veilig...

Maar je kan heel makkelijk de boel veiliger maken voor je eigen machines. Beperk gewoon het aantal root CAs dat je vertrouwt.
Waarschijnlijk heb je al geen 625 rootCAs in je trusted lijst staan, en waarschijnlijk merkt er niemand wat van als je het aantal beperkt tot de grote betrouwbare CAs.

En voor je SSL VPN oplossing kun je natuurlijk gebruik maken van een eigen interne CA die alleen vertrouwd word door jouw machines.

Mooi geschreven stuk.
Ik denk dat de doorsnee internet gebruiker geen enkel idee heeft welk gevaar hij/zij loopt. Deze maken zich vaak al nauwelijks druk over virussen. Wellicht moet de overheid hierover nog eens een campagne beginnen. Mensen bewust maken van de gevaren.

Gebruikers willen niet bewust gemaakt worden, gebruikers willen hun ding kunnen doen. Gewoon gemakkelijk internet bankieren, gemakkelijk een spelletje spelen. Zij vertrouwen hierbij op derden partijen, zoals virusscanners, systeembeheerders en dus ook de uitgever van beveiligings- certificaten ( uiteraard onbewust )

Dergelijke systemen moeten dus robuust zijn, en dus ook echt te vertrouwen zijn. Dat dit in veel gevallen niet zo is, is sterk te betreuren. De regering mag eerder deze bedrijven er bewust op maken dat ze verkeerd bezig zijn, en hier sancties op leggen. De gebruikers valt niets te verwijten, ga er maar vanuit dat deze hier niets en nooit iets om zullen geven.

Naar mijn weten leveren alle bedrijven de software op as-is basis. Zelfs de grote partijen kunnen niet aansprakelijke worden gesteld voor software dat potentieel onveilig is.

Een aantal handelingen zijn binnen de gemeenschap altijd een issue geweest. Vrouwenhandel, drugshandel, wapenhandel en geldhandel. Het is niet meer dan logisch dat deze steeds meer hun roots beginnen te krijgen op het net maar met een groot verschil,
het publiek is vele malen groter, het is veel makkelijker te bereiken en last but not least, en de stakes zijn veel hoger.

Zo is het illegaal om in veel landen vb een jointje op te roken,
maar met de post stuur je naar alle landen van een europa zomaar 5 sigaretten. Voor de porto hoef je het niet te doen en de controle is vrijwel nihil.
Ebay maakt het veel makkelijker om kleine handel te drijven. De bedragen zijn in principe te klein om door te geven, maar je kunt zo makkelijk enkele duizenden euro's bij te verdienen. Normaliter geef je het op als inkomsten uit overige werkzaamheden en is het een stuk moeilijker om aan klandizie te komen etc etc.

Gebruikers kunnen natuurlijk uitgaan van virusscanners, systeembeheerders, etc. Het feit is echter dat iedereen op zijn zolderkamer software kan maken. Software maken is niet voorbehouden aan grote bedrijven die zich verantwoordelijk dienen te gedragen. Je kan dus wel willen dat systemen robust moeten zijn en dus echt te vertrouwen, maar daarmee beweer je dus feitelijk dat iedereen op deze aarde te vertrouwen moet zijn. Een PC is een open platform, en de enige die kan controleren welke software op deze PC geinstalleerd wordt is de gebruiker zelf. De uiteindelijke verantwoordelijkheid zal dus ten alle tijde bij de gebruiker liggen. De gebruiker zal dat niet willen, en de gebruiker zal dat niet begrijpen, of zelfs uberhaupt in de gaten hebben dat hij zelf die verantwoordelijkheid heeft, maar dat geeft hem geen recht om met vingertjes te wijzen als het fout gaat.

Hier zijn spotjes van op tv geweest.

En die bevestigen precies aan wat pfranze zegt, quote uit filmpje:
"Check de s achter http."

Met verderop: "Een veilige betaalomgeving herken je aan het hangslotje en een webadres dat begint met https, waarbij de ‘s’ staat voor ‘secure’."

Een s-je toevoegen maakt je verbinding dus niet veilig.

_{*Wilt nog een analogie trekken tussen sex, condooms, koffiefilters en https maar vind de inspiratie niet.*}

Dat https niet 100% veilig is, is nog geen reden om het niet te gebruiken.
Gewoon http is 100% onveilig. Een https-site met een self-signed certificaat is misschien wel veilig, misschien niet. Een site zonder ssl is zeker onveilig.

Ik ben een beetje bang dat het publiek dit gaat uitleggen als 'https is onzin, dus hoef je het ook niet te gebruiken'.

Ik zal je vergelijking wel even overnemen: condooms geven ook geen 100% bescherming. Een kwaadwillende winkelier met een punaise kan ze zeer eenvoudig saboteren. In theorie moet je voor gebruik controleren of je condoom wel goed is, maar in praktijk wordt dat nog wel eens overgeslagen. Moeten we daarom stoppen met condooms te gebruiken of moeten we de mensen uitleggen hoe ze met condooms om moeten gaan?

Je moet dus stoppen met condooms te gebruiken en tegelijkertijd dus ook niet meer vrijen.

Je kan er niet vanuitgaan dat je met condoom veilig bent, maar je kan er wel vanuit gaan dat je zonder onveilig bent. Just die zekerheid is er een die je kan kiezen.
Het komt er dus op neer je bankzaken niet meer online te doen of goed te kijken of je bank alle te leiden schade zal vergoeden.

Een site met een self-signed certificate is veilig als en alleen als je een andere (betrouwbare) weg hebt om het certificaat te controleren op echtheid. De beste methode is om de public key op een stick te zetten en deze te installeren als "trusted" voor je naar de server connect. Een eenvoudige alternatieve mogelijkheid is om de eigenaar gewoon op te bellen, dat werkt vooral goed als je bedrijfs e-mail server ineens een nieuw certificaat lijkt te hebben. Als het gaat om je self-signed servertje thuis, schrijf je de thumbprint op een briefje en neem je die mee, of je controleert 'm met je mobieltje, die al eerder een betrouwbare verbinding heeft gehad toen je thuis was. Als er een man in the middle is (die niet bij je thuis de private key gestolen heeft), dan klopt de thumbprint niet en zal je mobieltje al klagen, of hij klopt niet met je briefje, of de eigenaar zegt dat het certificaat helemaal niet vernieuwd is de afgelopen maand.

Een self-signed certificate is potentieel zelfs veiliger dan een certificaat van verisign - mits je ZELF de verificatie doet. De verificatie van verisign en consorten houdt meestal niet meer in dan een credit-card check.

laten we eerlijk zijn, hoe vaak gaat het nou helemaal mis. nee, https is niet 100% veilig. Dat is met de trein gaan ook niet. Waarom zou je stennis schoppen om niets. Ja, je wilt inderdaad dat internet bankieren veilig gaat, maar moet je daarvoor consumenten informeren? Je kunt er toch niets aan doen

Ook http is niet 100% onveilig. Niet elke website met een login gebruikt https en dat is ook niet nodig. Het is een voortdurende kosten baten analyse

Juist voor de "leken" zijn dit soort dingen wat ongrijpbaar denk ik. Dat is ook de reden dat op de inlogpagina van o.a. deze bank expliciet een kopje staat met "hoe controleer ik de veiligheid van mijn verbinding?"

De achterliggende techniek weten maakt voor hen relatief weinig uit, als ze er maar naar handelen. Dat is hetgeen hier aangemoedigd wordt door je opdrachten te controleren e.d

Een campagne helpt niets. 99% van de surfers snappen er niets van en dat is niet zo vreemd. Je kunt het begrip van certificaat-autoriteit nog wel proberen uit te leggen, maar bij een man-in-the-middle haakt 98% af. De rest haakt af als je het over DNS en privacy-problematiek hebt.

Nee, de enige juiste oplossing is een veiliger alternatief. Ik zie dat niet heel snel gebeuren omdat er vandaag de dag nog geen werkbaar veiliger alternatief is.

Wat je op korte termijn kan doen is de certificate-authorities strenger auditen. Want wat bij diginotar gebeurde was allerstomst en had met een goede audit voorkomen kunnen worden.

Nee, de enige juiste oplossing is een veiliger alternatief. Ik zie dat niet heel snel gebeuren omdat er vandaag de dag nog geen werkbaar veiliger alternatief is.

Het lijkt mij vrij simpel: Iedere website mag slechts één certificaat hebben (is nu al).
Controleren of een certificaat geldig is gaat nu door het certificaat te ondertekenen met de signature van een certificaat-uitgever. Als de browser die certificaat-uitgever niet kent zoekt hij op of diens certificaat bij een hogere certificaat-uitgever vandaan komt, net zolang tot er een gekende uitgever staat en er dus een chain of trust is.

De nieuwe methode is nu door die verificatie niet te doen bij één hogere certificaat-uitgever maar bij meerdere, dat kunnen er twee zijn of drie of nog meer. Op die manieren zijn er meerdere paden mogelijk naar een vertrouwde uitgever. Vervolgens kun je eisen dat er meerdere chain-of-trusts zijn naarmate men een grotere zekerheid vereist. In principe kun je ook nog een weging geven aan een certificaat-autoriteit om diens niveau in de hiërarchie vast te leggen en zo te het via meerdere paden goedkeuren van schakel door één hogere instantie tegen te gaan. Dat is echter slechts zinvol als de hoogste autoriteiten niet bereikbaar zijn en er dus geen complete chain mogelijk is..

Wat je op korte termijn kan doen is de certificate-authorities strenger auditen. Want wat bij diginotar gebeurde was allerstomst en had met een goede audit voorkomen kunnen worden.

Auditen is een goed iets. Je checkt ermee of mensen zich houden aan de vastgelegde procedures en of de procedures voldoen aan de gestelde eisen. Wat je er niet mee kunt verhinderen is dat een systeem in die chain gehackt wordt en dus valse certificaten uit gaat geven. In het ideale geval is er wel een procedure waarmee wordt gecontroleerd of de integriteit van het systeem nog staat, waarmee een hack dus sneller gedetecteerd wordt.

In het systeem dat ik hierboven schets is één gehackt systeem geen probleem omdat een site altijd door meerdere hogere instanties vertrouwd moet zijn en je een site dus blijft vertrouwen als er genoeg overige instanties die deze site goedkeuren. De gehackte zal echter door meerdere CA's geblacklist worden en ook dat is effectief.

Misschien een domme vraag, maar hoe beschermt een notary tegen een "man-in-the-middle" attack?

Als er zich een tussenpersoon bevindt tussen de gebruiker en de doelserver, kan die toch ook gewoon elke oproep naar de notary onderscheppen, en een vervalst antwoord terugsturen, vb: het bericht dat het certificaat geldig is, ook al is het in werkelijkheid niet zo.

Één notary beschermt je niet, meerdere notary's wel
Als negen servers zeggen dat jou certificaat klopt, dan is het vrij betrouwbaar.

100% zekerheid heb je nooit, immers hoe weet je dat de private key veilig is op de server (er zijn genoeg mensen die de privatekey in een opendir hebben (zie bijvoorbeeld bij PGP

Maar meerdere notary's helpen wel bij landen als China/Iran/Syrie waar actief gemitmed wordt.


Ik vraag me meer af wat de impact op notary's is met Geografsiche loadbalancers en verschillende certificaten zoals bij google/facebook.

Een man in the middle kan perfect alle negen verbindingen onderscheppen, dus dat is geen oplossing. Je kan het systeem misschien uitbreiden met een digitale handtekening, maar dan moeten de public keys van deze notary servers ook weer in de browser opgenomen worden, en zo blijf je bezig ...

Zelf ben ik nog altijd voorstander van gewoon dat een ssl certificaat door meerdere CA's worden ondertekend. De publieke sleutels van deze CA's zitten toch al in de browser....

Als een certificaat door bijvoorbeeld 5 CA's getekend is, is de kans toch wel heel groot dat je pc met de juiste server is verbonden.

Tja, de server kan ook geroot worden en het certificaat kan gestolen worden. Het bied een extra laag veiligheid. Maar als je bij convergence gaat kijken en we nemen het voorbeeld van 8 notary servers en een standaard webserver bij een grotere ISP (meerdere peers)

De enige echte manier om daar een MITM op uit te voeren is dat je of in het AS zelf zit, of je op de borders van het AS zit. Daar om heen zitten meerdere peers en niet iedereen komt met het zelfde AS PATH binnen als men vanuit 9 verschillende landen komt.

Voor zover ik weet is de onderlinge communicatie tussen de verschillende notarys veilig maar dat zou je zelf moeten analyseren (http://www.convergence.io/details.html) Want https://github.com/moxie0/Convergence/wiki/Running-a-Notary geeft aan dat je een eigen keypair moet genereren waarmee de requests/responses gesigned worden. zie ook de SNT Notary En die publickeys zitten niet in de browser maar in de extension/addon welke het hele proces afhandelt.

5 CA's laten ondertekenen zegt imho niks immers diginotars had ook al 3 CA's als zijnde en de chinese overheid heeft er wel meer dan 5

Het probleem is juist dat je teveel publieke sleutels in je browser hebt

[Reactie gewijzigd door LuckY op 13 maart 2012 14:33]

Eigenlijk is de conclusie dat we nu veel geld betalen voor een systeem dat niet veilig genoeg werkt, en de kans dat we overstappen naar een beter systeem bijna onbestaand is?
Er moet toch een oplossing zijn hiervoor?

Wel neen, ik vind dat we kunnen besluiten dat we veel geld hebben gestoken en nog steeds steken in een systeem dat minder veilig is dan we eerst wilden dat het was.
"Onveilig" is zeer relatief. Het is en blijft een verbetering op geldtransporten en bewaren van gevoelige/waardevolle papieren in een kluis, volgens mij.

Het is in ieder geval wel goed dat er eens aandacht naar gaat. Enkel jammer dat een artikel als dit enkel te lezen is voor een niche als "de tweakers" zelf, die volgens mij toch iets bewuster zijn van de beperkingen en risico's van ssl's en https.
Plaats dit stuk eens in de algemene media of maak er een reportage van. (zonder der een hetse rond te maken dan wel) en dan kunnen we misschien nog iets doen rond de sensibilisering van het volk.

Dit blijft natuurlijk een zeer technisch verhaal voorde gemiddelde wereldburger. Dus moeilijk publiceerbaar in een minder technische omgeving. En dus blijft de groep die bereikt wordt nogal beprekt.
De doorsnee niet-tewaker begrijpt hier niets van, is totaal niet geïnteresseert en wil hier geen seconde tijd aan besteden. Denk dat ik dat veilig kan zeggen op basis van de mensen om mij heen. Om het voor die mensen (99% van de internetters) veiliger te maken moet dat automatisch en onder de motorkap gebeuren. Als ze er zelf aktie voor moeten ondernemen gaat het niet gebeuren.
Neemt niet weg dat dit een erg helder en goed stuk is!
Kudo's !

De mensen die dit lezen zijn echter wel het aanspreekpunt voor de rest van de bevolking: als je een vraag over computers hebt, ga je naar het handige neefje of buurjongen om de hoek.
Het mooie van dit artikel is dat het bestaande kennis opfrist en nogmaals in perspectief stelt. Ik had bijvoorbeeld van perspectives en convergence al wel eens gehoord, maar het is altijd een beetje klok/klepel bij mij geweest.
Nu ik preciezer weet wat het is en voornamelijk wat het probeert op te lossen, ben ik ook beter in staat om andere mensen te informeren die geen technische achtergrond hebben.

Overigens heeft de gemiddelde computergebruiker niet zoveel aan deze kennis. Als ik wil internetbankieren, dan moet ik internetbankieren. Dat certificaat is van VeriSign, meer kan ik daar niet over uitvinden. Er is geen mogelijkheid om uit te vinden of die website daadwerkelijk is wie hij is; er is altijd een restrisico dat het certificaat vervalst is.
Wat ik dan ook niet begrijp, is dat de websites die afhankelijk zijn van die certificaten de gebruikers niet informeren over welke CA ze gebruiken. Als jij bijvoorbeeld van de Rabobank post krijgt dat hun certificaten ondertekend zijn door VeriSign, en je komt ineens DigiNotar tegen als CA op hun website, dan weet je dat er wat aan de hand is.
Het is sowieso van de pot gerukt dat iedere CA voor ieder domein een certificaat uit kan geven. Dat lijkt me nog wel de meest graverende zwakte van het systeem.

Ik zie hier ook een mooie VPRO rapportage over uitkomen inderdaad.

Ik heb de laatste pagina's niet helemaal gelezen, maar ik mis eigenlijk de verwarrende situatie waarin niet álle content op een pagina veilig is.
In Chrome wordt 'het slotje' dan oranje, maar hoe weet ik nu of het veilig is? Ik persoonlijk haak dan af

Wat ik me afvraag waarom we het niet zo maken dat sites twee cert's aan moeten leveren van twee CA's. Nog steeds niet perfect en zal aanpassingen vereisen aan TLS. Maar dan zijn we af van singel point of failure.

Tja dan zal iemand 2 TTP's moeten hacken, dat maakt het iets veiliger, maar het daadwerkelijke probleem blijft bestaan.

Dat hangt natuurlijk maar helemaal af van je definitie van veilig.
Als de kans een Notar te hacken 10% is (of anders gezegd, de kans dat een Notar te hacken valt), dan is de kans twee Notars te hacken tien keer zo klein (namelijk 0,1^2=0,01%). Dat noem ik niet iets veiliger. Als je een probleem hebt dat je onmogelijk kunt oplossen omdat alle oplossingen graverende nadelen hebben, dan moet je kijken naar de dingen die je kunt doen om die problemen zo klein mogelijk te maken.

Wat dat betreft is triangulation zoals eddie dat voorstelt natuurlijk de eerste en meest effectieve risicovermindering.
Een tweede is het verwijderen van de mogelijkheid voor iedere CA om overal een certificaat voor uit te geven. Websites dienen aan te geven welke notar ze gebruiken, bijvoorbeeld. Dat kun je ook decentraliseren om het veiliger te maken. Sowieso is het toch onwaarschijnlijk dat Gmail een certificaat gebruikt van de chinese overheid? Ik denk dat je daar ook nog wel wat stochastische algoritmes op los kunt laten.

[Reactie gewijzigd door Buggle op 13 maart 2012 13:09]

Interessant stuk.

Is het officieel niet zo dat een ROOT CA na het uitdelen van het 'hoofd' certificaat uit gezet dient te worden? Dit om tevens te voorkomen dat zoiets gehacked wordt?

Aangezien de onderliggende CA's (die het certificaat erna weer verder verspreiden) als 'kind' fungeren. en zelf dus niets genereren.

Lijkt mij dus meer een fout van bedrijven die deze dingen dus niet volgens de 'juiste' manier structureren, waardoor ze dus vatbaar(der) worden voor dit soort zaken.

Kan zijn dat ik er naast zit maar hoor het graag

Standaard zet je de Root- CA's uit en ga je verder met het distribueren via Intermediate CA's, deze hebben echter de volmacht om CSR te signen (waardoor er een certificaat ontstaat).

Deze Intermediate dozen kunnen echter ook gepwned worden, waardoor certificaten gesigneerd kunnen worden.

In hoeverre kan je een notary server vertrouwen? Stel nou dat je gehackte browser in ene andere notary servers instelt of is dit onmogelijk?

Je kan het zo paranoide mogelijk instellen =) als jij van 10 verschillende notary's 10 gelijke certificaten krijgt, lijkt het me moeilijk ge-mitm'ed. Kijk vooral eens de talk van Moxie marlinspike op BH USA 2011
https://www.youtube.com/watch?v=Z7Wl2FW2TcA
Waarin hij het probleem ook omschrijft en mitigate

Er kunnen nog wat lapmiddelen de ring in gegooid worden: browsers moeten de certificaten eeuwig bewaren en bij iedere nieuwe https-verbinding het huidige met het oude certificaat vergelijken. Zo ontdek je een man-in-the-middle omdat die een ander certificaat gebruikt.

Je kunt ook 'verdachte' sites aanmerken. bv als de DNS respons voor www.abnamro.nl verwijst naar een IP-adres buiten Nederland kan het vlaggetje rood worden. Voor .com is dat niet te doen, maar laten de Amerikaanse banken dan maar .us gaan gebruiken.

De certificates kunnen uitgebreid worden met een 'domain-authority' field. bv. diginotar kan alleen .nl domains tekenen en het nieuwe domain-authority field van het root-certificate van Verisign laat zien dat het alleen .com en .net mag tekenen.

Ik heb in een andere reactie al gezegd dat strenger audits bij certificate authorities nodig zijn om akkefietjes zoals van diginotar te voorkomen.

Knappere koppen kunnen vast nog wel een paar andere lapmiddelen bedenken.

Er kunnen nog wat lapmiddelen de ring in gegooid worden: browsers moeten de certificaten eeuwig bewaren en bij iedere nieuwe https-verbinding het huidige met het oude certificaat vergelijken. Zo ontdek je een man-in-the-middle omdat die een ander certificaat gebruikt.

Een certificaat heeft een beperkte geldigheid, dus dat gaat niet werken.

Je kunt ook 'verdachte' sites aanmerken. bv als de DNS respons voor www.abnamro.nl verwijst naar een IP-adres buiten Nederland kan het vlaggetje rood worden. Voor .com is dat niet te doen, maar laten de Amerikaanse banken dan maar .us gaan gebruiken.

Hosting word steeds meer een wereldwijd verhaal. Als ik gmail bezoek, word dit afgehandeld door een server die wat tijd overheeft. Andere sites gebruiken mogelijk content distribution networks die proxy'en. Dit zal vaak niet over SSL gaan, maar soms ook wel. Om TLD's aan ip-ranges te koppelen is niet practisch.

De certificates kunnen uitgebreid worden met een 'domain-authority' field. bv. diginotar kan alleen .nl domains tekenen en het nieuwe domain-authority field van het root-certificate van Verisign laat zien dat het alleen .com en .net mag tekenen.

Dit zou nog kunnen, maar zie het ook niet echt practisch. Dat zou betekenen dat je automatisch met verschillende partijen zaken moet doen voor al je certificaten, als je een grotere site hebt en alle varianten op je domeinnaam wilt registreren (mijn werkgever heeft bijvoorbeeld alle varianten op onze domeinnaam geregistreerd, op 1 na, die een concurrent heeft geclaimed).

Ik heb in een andere reactie al gezegd dat strenger audits bij certificate authorities nodig zijn om akkefietjes zoals van diginotar te voorkomen.

Helemaal voorkomen kan je dat toch niet, er zijn 650 CA's die over de hele wereld staan, in landen die stuk voor stuk hun eigen wetgeving hebben, en die niet allemaal gaan luisteren naar de "wet" van het internet, of van browser makers for that matter.

Mooi dat er allemaal methodes worden bedacht om het certificaten-systeem veiliger te maken.

Toch maak ik me zorgen om de allerzwakste schakel: de eindgebruiker.

Zelf heb ik best veel technische achtergrond, met zelfs goeie kennis van het certicatensysteem.

Maar wat denk je dat ik in 90% van de gevallen doe, als ik een certificaat-fout tegenkom? Juist: "Klik, klik, make exception".

Voor het beschermen van burgers tegen afluisteren en beveiligen van internetbankieren zijn certificaten gewoon onvoldoende. Certificaten zijn vooral geschikt voor professionele instanties die op een secure manier met elkaar willen communiceren over internet.

En dan kunnen die misschien beter nog een extra laag encryptie over hun data heengooien, dan alleen te vertrouwen op https.

Maar wat denk je dat ik in 90% van de gevallen doe, als ik een certificaat-fout tegenkom? Juist: "Klik, klik, make exception".

Dat doe ik wel voor allerlei wiki's en fora die foute certificaten gebruiken, maar ik beschouw deze verbinding dan wel als onveilig. Als de ABN-AMRO mij een certificaat fout gaat presenteren, dan ga ik echt niet verder en beschouw tot nader order mijn internetlijn, PC, router, en desnoods mijn UTP kabel als onveilig...