Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 48, views: 26.967 •

Een onderzoeker van het Instituut voor Informatierecht zet vraagtekens bij nieuwe Europese regelgeving die de ssl-markt moet reguleren. Volgens de onderzoeker komt te veel aansprakelijkheid bij certificaat-autoriteiten te liggen.

De Europese eSignature-regulering gaat het haperende ssl-systeem niet repareren. Dat zei onderzoeker Axel Arnbak van het Instituut voor Informatierecht van de Universiteit van Amsterdam tijdens de CCC-beveiligingsconferentie in Hamburg, waar Tweakers aanwezig is. De regulering is onder meer bedoeld om het ssl-systeem aan strengere regels te onderwerpen; op dit moment is daar geen toezicht op, terwijl ssl van cruciaal belang is voor vertrouwelijke communicatie.

Volgens Arnbak gaat de aandacht in de regulering vooral uit naar certificaat-autoriteiten. Certificaat-autoriteiten zijn verantwoordelijk voor het uitgeven van ssl-certificaten, die onder meer worden gebruikt voor https-verkeer. Die bedrijven kunnen als gevolg van de richtlijn aansprakelijk worden gesteld voor de schade die wordt veroorzaakt als ze bijvoorbeeld worden gehackt. Een bedrijf als het Beverwijkse DigiNotar, dat vorig jaar werd gehackt en daardoor frauduleuze certificaten uitgaf voor onder meer Google, Microsoft en Skype, zou dus aansprakelijk kunnen worden gesteld voor de schade die die bedrijven leden.

De onderzoeker denkt dat die aansprakelijkheid de markt voor ssl-certificaten 'kapot kan maken'. "Zelfs de grote certificaat-autoriteiten kunnen die aansprakelijkheid misschien niet aan", zegt Arnbak tegen Tweakers. Hij vreest echter dat het zeker voor kleinere certificaat-autoriteiten moeilijk gaat worden. DigiNotar had een omzet van nog geen vijf miljoen per jaar en had de schade van de grote bedrijven nooit kunnen vergoeden, denkt hij. Bovendien is er nog het probleem van jurisdictie: veel grote certificaatautoriteiten, zoals VeriSign en Comodo, zijn gevestigd buiten de Europese Unie.

Wat Arnbak betreft zou regelgeving voor het ssl-systeem ook aandacht moeten hebben voor andere actoren, zoals de rol van browsers en individuele websites bij de implementatie van ssl. Ook zou er aandacht moeten zijn voor de fundamentele problemen met het ssl. "Op dit moment is elke certificaat-autoriteit een single point of failure", zegt Arnbak. Elke certificaat-autoriteit kan een certificaat uitgeven voor elk mogelijk domein, waardoor de hack van één provider het volledige systeem onbetrouwbaar maakt.

Daarnaast is er volgens de onderzoeker vooral aandacht voor de economische kant van het verhaal. Ssl is van belang voor de e-commerce-markt, maar de regulering gaat volgens Arnbak voorbij aan het feit dat ssl ook belangrijk is voor vertrouwelijke communicatie tussen burgers. Ook zouden er in regelgeving duidelijke normen opgenomen moeten worden voor het melden van beveiligingsproblemen. DigiNotar wachtte enkele maanden totdat het de autoriteiten inlichtte dat het bedrijf was gehackt; in die tussentijd zijn met ontvreemde certificaten van het Beverwijkse bedrijf waarschijnlijk vele duizenden Iraniërs afgeluisterd.

Reacties (48)

Het DNS-systeem is sowieso al centraal. Er is een domeinroot, dan heb je TLDs en daaronder weer domeinen, subdomeinen, etc. DNSSEC is echter veilig, omdat alleen de root de TLDs mag signen, alleen de TLDs de domeinen mogen signen, etc. Omdat de registratie van DNSSEC tegelijk met de registratie van normale domeinen gaat, zijn er geen twee partijen die samen moeten komen, en is het een veilig systeem.

Het huidige certificatensysteem is onveilig omdat een certificaat authoriteit voor alle domeinen een certificaat uit mag geven, en daardoor worden het allemaal SPOFs. Bij DNSSEC is dat niet het geval.
Er is helemaal geen kip en ei probleem. De zwakheid van HTTPS zit hem helemaal niet in de certificaten; Er is geen probleem met X.509.

Het probleem zit hem erin hoe browsers omgaan met deze certificaten. Nu vertrouwen browsers certificaten uitgegeven door "vertrouwde" CA's voor ieder willekeurig domein.

Als je bijvoorbeeld CertPatrol onder firefox installeerd of certificate pinning gebruikt in chrome heb je dit hele probleem al opgelost.

Echter zijn bovenstaande oplossingen niet ideaal; Ze vereisen handmatig werk. Daarom is DNS de plek om aan te geven welk certificaat gebruikt mag worden voor een domein. In je DNS client kan je van te voren gewoon hard in stellen met welke key die boel weer gesigned moet zijn.
Anyway, ik zag laatst een goed certificaat-alternatief: gewoon in de DNS stoppen.
Dat lost niets op. Het probleem van SSL-certificaten is niet het verspreiden ervan, maar de uitgifte ervan, en dan met name het enorme vertrouwen dat we allemaal in de Certificate Authorities moeten hebben in het huidige systeem.

Het zou misschien een beter systeem zijn om certificaatuitgifte bij domain registrars te leggen in plaats van bij losse CAs, zodat elk domein automatisch met een certificaat geleverd wordt. (Misschien bedoelde je dat ook? Al is dat natuurlijk wat anders dan het "in DNS stoppen")

Maar ik betwijfel of dit veel gaat helpen. Fraude voorkomen is iets makkelijker, maar je blijft het probleem houden dat alle registrars certificaten kunnen uitgeven voor elk domein, wat (zowel per ongeluk als expres) voor zal blijven komen...
Aangezien DNSSEC ervoor zorgt dat de DNS-informatie klopt, hoef je alleen maar je public certificate in de DNS te stoppen en het hele probleem is opgelost. Weg gecentraliseerd systeem, en zolang je DNS beveiligd is met DNSSEC is het gewoon veilig.
Je hebt helemaal niks aan DNSSEC hiervoor. DNSSEC is beveiligd met certificaten, dus DNSSEC gebruiken om certificaten te verspreiden geeft een mooie catch-22. Bovendien is - zoals ik boven al beschreef - het verspreiden van de certificaten niet het probleem, maar de uitgifte ervan.

(DNSSEC is overigens een hopeloos ontworpen standaard die niks nuttigs toevoegt, maar dat terzijde. Lang verhaal kort: een domein dat beveiligd is met certificaten heeft niks te vrezen van DNS-spoofing, en een onbeveiligd domein kun je sowieso man-in-the-middlen, DNSSEC of niet)
Sorry, maar wat je zegt klopt van geen kant. Je koppelt allerlei dingen aan elkaar die niks met elkaar te maken hebben. Key-pairing in DNS? Wat bedoel je daarmee?!?

Hoe het nu (globaal) werkt:
- Ik type in mijn browser https://voorbeeld.com
- OS doet een DNS request naar het IP van voorbeeld.com
- Browser maakt verbinding met dat IP
- De webserver op dat IP stuurt zijn certificaat
- Mijn OS/browser checked of het cert is uitgegeven door een vertrouwde CA, of de naam klopt en diverse andere checks.
- Indien akkoord wordt de SSL sessie geaccepteerd, en kan ik veilig browsen.

Veilig in zoverre, dat de gegevens onderweg gencrypt zijn, en dat ik praat met de echte voorbeeld.com server. Dit is er dan wel op gebaseerd dat ik de CA kan vertrouwen. En dat is de zwakte in het systeem waar deze nieuwspost over gaat. Als de CA niet te vertrouwen is (vanwege fraude of incapabel zijn), dan is het hele systeem lek.

Door het certificaat in DNS op te slaan los je helemaal niks op. Hoe zou dat technisch werken dan? En welk probleem los je dan op? En Hoe?

- Ik type in mijn browser https://voorbeeld.com
- OS doet een DNS request naar het IP van voorbeeld.com
- Tevens wordt bij de DNS server het cert van voorbeeld.com opgevraagd?!?
- En dan?
- Als de voorbeeld.com server het cert niet k heeft kunnen we niet veilig communiceren. Stuk.
- Als de voorbeeld.com server wel het certificaat heeft, wat is dan de toegevoegde waarde van dit in DNS zetten?

i-chat, TvdW? Wie kan dit uitleggen?
DNSSEC bevestigt dat de DNS-records kloppen. Dit kan doordat DNSSEC niet last heeft van de problemen met certificaten waar SSL op dit moment wel last van heeft (certificate authorities zijn er niet echt met DNSSEC).

Zodra je weet dat de DNS-records kloppen en dat je het goede certificaat hebt, weet je toch genoeg?

Dit heet overigens DANE (https://tools.ietf.org/html/rfc6698)
Als de voorbeeld.com server wel het certificaat heeft, wat is dan de toegevoegde waarde van dit in DNS zetten?
Je hoeft niet eens het hele certificaat te doen. Je kan bijvoorbeeld ook enkel de MD5 finger print van het certificaat af geven. Overigens worden certificaten in DNS beschreven in RFC 4398.

De toegevoegde waarde is dat je weet dat dit certificaat (en enkel dit certificaat) gebruikt mag worden om dit domein te beveiligen. En dat het niet een certificaat is wat uitgegeven is door bijvoorbeeld een gehackte CA. Dat is wat bij DigiNotar gebeurde. Firefox en IE gebruikers werden gepakt door een man in the middle attack op gmail.com in Iran maar Chrome gaf een foutmelding omdat deze hardcoded de fingerprint van het enige certificaat had wat voor gmail.com gebruikt mocht worden.
HTTPS SSL/TLS encryptie is zo sterk als de zwaktste schakel.

Browsers zoals IE6, IE8 en menige anderen, ondersteunen encryptie ciphers en methodieken die dateren uit het begin van deze eeuw. Deze beveiligde connecties kunnen al gekraakt worden d.m.v bijv. een Beast SSL of SSL downgrade aanval.

Daarnaast ondersteunt het leeuwendeel van de https servers (ter voorbeeld www.ben.nl, www.pine.nl en www.fox-it.com) alleen maar de zwakke SSL protocolen.

En dat is nog niet alles, het is zelfs nog mogelijk om een nieuwe EV SSL certificaat te verkijgen, dat geleverd wordt met een 1024 bit RSA certificaat en die op zijn beurt weer beveiligt mag worden door een connectie gebaseerd op SSL3.0, RC4 based encryptie zonder enige forward secrecy.

Wat ik hiermee wil zeggen is dat de CA deels verantwoordelijk kan worden gehouden, maar dat het grootste beveiligingsrisico toch echt bij de afnemers en gebruikers ligt. Zij weigeren vaak hun software te upgraden en kloppen daarna aan bij de CA als er iets fout gaat. Eigenlijk is het hetzelfde als een verzekeraar verplichten om een auto te verzekeren die niet door de APK is gekomen.

En ja, er gaat een hoop mis bij het uitgeven van certificaten en het beveiligen van de servers van de CA. Maar hier geld het zelfde als bij de banken: U vraagt en wij leveren, bijna ongeacht de risico's die hier aan vastzitten.


Via Twitter hebben we ten eerste contact gehad met de CTO van Globalsign over de zwakheden van OSCP en CRL en deze man is het eens met het bovenstaande. Er moet verbetering komen, maar dan van drie kanten.

[Reactie gewijzigd door Palatinux op 29 december 2012 16:29]

Allemaal leuk en aardig maar de zwakheden die je noemt (Beast SSL met SSL downgrade) zijn beide serverside en hebben niks met de CA te maken, je kan moeilijk de CA's verantwoordelijk stellen voor zwakheden die worden veroorzaakt door fout geconfigureerde server software.

Je hebt het over pine.nl en fox-it.com maar die servers hebben netjes degelijk SSL encryptie met beide een 2048bit certificaat en ik zie nu even niet in wat ze nog meer zouden moeten doen en wat dat met de CA's te maken heeft.

Je kan nou natuurlijk het argument gaan maken dat de laatste revisies van de standaard hogere sleutel lengtes ondersteund en daar zou je gelijk in hebben maar het probleem daarbij is dat die langere sleutel lengtes niet zijn bedacht op bulk verkeer en ten tweede maar sinds kort in het leven zijn en dus onbeproeft en ook nog niet aanwezig is (volgens mij is OpenSSL de enige met een degelijke implementatie).

Ze moeten dan maar heel snel upgraden naar die standaard... Ja maar wat als nu blijkt dat die nieuwe onbeproefde standaard ook nog eens gaten bevat? Gaan we dan ook zeuren over onze beveiliging?

Je zet de CA's nu wel heel makkelijk in een hoekje weg. We gaan CA's verantwoordelijk stellen voor eventuele gaten in hun beveiliging, er zijn betere onbeproefde mogelijkheden aanwezig dus moeten ze die maar gaan gebruiken maar als er gaten zitten in die onbeproefde mogelijkheden dan gaan we ze ook verantwoordelijk stellen...

Tja!

En wat dacht je van processing power? Langere sleutel lengtes zijn leuk en aardig maar er moet eerst wel flink aan gerekend worden. Dat betekent meer en zwaardere servers, meer rackspace, meer energie consumptie, etc. Wie gaat dat allemaal betalen? Niet te spreken over mvr. Jansen die klaagt dat haar computer even vastzit elke keer als ze naar de site van haar bank gaat. Niet beseffende dat ze die 20 jaar oude rammelbak nou eindelijk eens weg moet gooien.

Ik ben het eens dat er nou eens eindelijk kritische gekeken mag worden naar de CA's maar wat je nu allemaal op noemt is pure kolder. Ten eerste heeft het niks met de CA's te maken en ten tweede is het in de praktijk niet zo makkelijk gerealiseerd als dat jij het hier opschrijft.

[Reactie gewijzigd door SizzLorr op 29 december 2012 21:41]

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Luchtvaart Crash Smartphones Laptops Google Apple Games Politiek en recht Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013