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.971 •

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)

Als domein eigenaar moet je op kunnen geven welke CA's certificaten voor je (sub)domein uit mogen geven. Koppel daar een paar geregistreerde personen aan die hun fiat kunnen geven voor uitgifte en je zit redelijk veilig.
Ontsluit die info via een publiek (gedistribueerd) systeem (DNS / SPF record-a-like ofzo). Browsers en OS'en kunnen die info opvragen en als je dan een certificaat van google tegen komt uit een niet geregistreerde CA -> ERROR!!!!!
Voeg eventueel nog een mogeljikheid toe om in die zelfde centrale database per domein op te kunnen vragen welke certificaten er uit staan en je hebt als domein eigenaar ook meteen een mooi naslagwerk.
En dan zijn er nog vele sites die er helemaal verkeerd mee om gaan.
Banken die maar wat aanrommelen https://rabobank.nl/ (certificaat staat op www.rabobank.nl)
Beveiligde en niet beveiligde items door elkaar.
Ook kom ik nog steeds sites tegen die eerst om je wachtwoord vragen en dan pas over gaan op https.

Dan heb je nog het fenomen, dat vele gebruikers het zelfde wachtwoord overal gebruiken.
Ook voor de webwinkel die helemaal geen https heeft.
Tegen deze domheid is geen certificaat bestand.

[Reactie gewijzigd door erikmeuk3 op 30 december 2012 15:58]

in die tussentijd zijn met ontvreemde certificaten van het Beverwijkse bedrijf waarschijnlijk vele duizenden Iraniërs afgeluisterd.

Dit is echt een veel te stellige bewering. Zeker als je niet eens kunt aantonen dat er zelfs maar éen Iraniër door is afgeluisterd.
Google had aan Chrome een controle toegevoegd voor hun eigen diensten. Waardoor voor gmail alleen certificaten geaccepteerd worden van uitgevers waar Google mee werkt.
Geen algemeen bruikbare oplossing. Maar wel wat er voor zorgde dat we weten dat er in Iran misbruik werd gemaakt van valse via Diginotar gegenereerde certificaten voor diensten van Google.

http://productforums.goog...#!topic/gmail/3J3r2JqFNTw
http://googleonlinesecuri...empted-man-in-middle.html

[Reactie gewijzigd door R-J_W op 30 december 2012 00:06]

Certificaten, meer certificaten om certificaten te beveiligen, 1024 bits sleutels om sleutels te beveiligen om weer certificaten te beveiligen.....

Wordt het geen tijd om dat hele beveiligingssysteem eens van tafel te vegen en met de kennis van nu iets beters/totaal anders te ontwikkelen? En als er toch wat aansprakelijkheid moet worden neer gelegd, waarom niet bij je browser giganten. Zij veranderen steeds met hun protocollen waardoor een verouderd certificaatsysteem steeds weer en meer achterop raakt. Mij lijkt dat de browser giganten zich moeten conformeren aan het nieuwe beveiligingsprotocol en niet andersom.
Wat zielig weer, dat bedrijven die ergens (bakken met) geld aan verdienen nu ook aansprakelijk zijn voor bepaalde risico die daarmee samen hangen.

Dat moet je nooit doen natuurlijk! Het beste is als de belastingbetaler garant staat voor alles.

/Einde sarcasme

Het lijkt me overigens wel verstandig om heel X.509 op de schop te gooien en te vervangen met een web of trust systeem. Dat zal overigens potentieel nog veel funester zijn voor kleine CAs.
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]

Van de CA mag onderhand wel verwacht worden dat zij meer eisen gaan stellen aan de server voordat ze een certificaat vrijgeven. Dit zou niet alleen moeten afhangen van een een 1.0 admin die zo graag Debian Squeezy gebruikt en waarbij alleen SSLv3 en TLSv1.0 wordt ondersteund. Geen TLSv1.2 ? Geen hoogwaardig EV certificaat.

Allemaal kolder? Het lijkt erop dat je teveel tijd besteed aan het modden en je status bij tweakers. Zie hier:

https://community.qualys....g-the-beast-attack-on-tls

"TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent."


https://www.ssllabs.com/ssltest/analyze.html?d=www.pine.nl
https://www.ssllabs.com/s...yze.html?d=www.fox-it.com

"This server is vulnerable to the BEAST attack"
"TLS 1.2 No"
"TLS 1.1 No"
"Session resumption No (IDs assigned but not accepted)"

Indien jouw server of client geen 4096K RSA aankan, wordt het tijd om te upgraden. Onze servers verwerken vele bezoekers en ssl overbelastingsaanvallen per minuut. En toch kunnen wij een https pagina binnen 1 seconde tonen bij de meeste browsers.

[Reactie gewijzigd door Palatinux op 30 december 2012 00:59]

lol, waar haal jij die BS vandaan? Een 1024bit sleutel licht vandaag net niet binnen bereik maar zou misschien mogelijk zijn over een jaar of 10. Ja er bestaan theoretische modellen die de benodigde tijd sterk naar beneden kunnen halen, maar het aantal mensen in de wereld die deze theoretische modellen kunnen uitwerken kan je op je vingers tellen.
Alleen maar roepen dat het kan is natuurlijk geen bewijs.

[edit] De link van OMX2000 hierboven geeft een helder overzicht.

[Reactie gewijzigd door f.v.b op 29 december 2012 16:25]

Voor kleine bedrijven zal het weinig uitmaken of ze failliet gaan door de schade vergoeding of door imago schade. Als de dikke salarissen zijn uitbetaald is de buit toch al binnen.
Daarna kan je een nieuwe bv starten, de oude boedel opkopen en opnieuw beginnen.
Het moet juist bij, al dan niet aansprakelijke, commerciële partijen liggen.
Laat je het aan een overheid over dan ban ik in ieder geval alle vertrouwen kwijt.
Nu waren het de Iraniërs die getapt werden, maar als dit door de EU geregeld gaat worden zijn we
nog verder van huis...
Eigenlijk heeft een beveiligingsmethode waarbij je bepaalde mensen in vertrouwen moet nemen per definitie al een lek.
En derhalve is het gehele internet lek, want het gehele internet is gebouwd op vertrouwen.

Als we er simpelweg vanuit gaan dat niemand te vertrouwen is, is er niets aan de hand.
Wat ik bedoel is niet het vertrouwen in de andere partij waarmee je wil communiceren, maar in de achterliggende club/organisatie/groep die daarbij wordt betrokken om de veiligheid te garanderen.
Zoiets lijkt mooi maar is veiligheidstechnisch gezien alleen maar een extra risico en dat is hier goed te zien:
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.
Dat certificeringssysteem vertoont een fundamtele fout en verhoogt tot nu toe dus alleen de schijnveiligheid.
Er is een eenvoudige oplossing certificaten worden niet online verstrekt maar door een notaris waarbij de aanvrager, id kaart en gegevens van KvK laat zien om aan te tonen dat hij een legitieme partij is.

Kosten gaan natuurlijk wel omhoog maar veiligheid is nu eenmaal niet gratis.
Notarissen hebben meestal geen verstand van computer beveiliging, maar het is wel een goed idee om de identiteit fysiek te controleren.
Vroeger ging het in Frankrijk ook zo bij het uitgeven van domeinen. Je moest met de nodige papieren persoonlijk verschijnen om een domein aan te aanvragen.

Daarnaast moet je alles offline halen. Als er een digitale verbinding is kan het gehackt worden en ook USB is niet veilig.
De notaris hoeft geen verstand te hebben van computer beveilig, hij moet verstand hebben van het veilig uitgeven van certificaten.

Het certificaat kan verstrekt worden op papier, een 4096 bits lange sleutel is in hexadecimalen 512 tekens, dat is maar een paar regels op een A4 en dus zo over te typen.
Overtikken? Heb je een slag van de digitale molen gehad? :-)
een 4096 bits lange sleutel is in hexadecimalen 512 tekens
Nee, 1024.
Dan blijft het probleem dat iedere CA een SPOF is.
Wanneer het systeem voor de uitgifte van certificaten offline staat is het alleen bereikbaar voor hackers die fysiek toegang hebben. Fysieke toegang is eenvoudiger af te schermen dan dat jan en alleman de servers van de CA kan bereiken via internet.
Leuk in theorie, totale faal in praktijk. Zie Diginotar. Het fundamentele probleem wordt niet opgelost zo.
Het probleem van Diginotar was nou juist dat ze hun belangrijkste certificaat gegevens online hadden staan.
Waarom moet ik een kvk inschrijving hebben om een certificaat te verkrijgen?

Ik wil als particulier gewoon een ssl certificaat kunnen laten maken.
Wil je als particulier een certificaat dan maak je een self signed certificaat.

Voor een veilig systeem is het beter dat kleine sjacheraars geen toegang hebben tot certificaten.
Wil je als particulier een certificaat dan maak je een self signed certificaat.
Voor willekeurige bezoekers van mijn site is een self-signed certificaat erger dan simpelweg geen SSL.

Omdat je bij een self-signed certificaat geen mogelijkheid hebt te controleren of het certificaat klopt voegt het geen beveiliging toe. Mensen die denken dat dat wel zo is denken dus veiliger te zijn zonder dat ze echt veiliger zijn, en mensen die niet weten wat certificaten zijn worden weggejaagd door de melding van de browser dat het certificaat niet gevalideerd kon worden.

Self-signed certificaten zijn echt geen oplossing, en de motivatie voor waarom dat voor particulieren goed genoeg zou zijn ontgaat mij volkomen.
Voor een veilig systeem is het beter dat kleine sjacheraars geen toegang hebben tot certificaten.
Ahja, dus iedereen met een KvK-inschrijving is legitiem, en alle anderen zijn sjacheraars? Dat is natuurlijk onzin.

Bovendien helpt dit allemaal niks tegen het feit dat Certificate Authorities voor elk willekeurig domein een certificaat uit kunnen geven, en fouten kunnen maken (en zullen maken). Bij het Diginotar-verhaal was bijvoorbeeld sprake van een inbraak bij Diginotar. Een KvK-inschrijving als eis had daar niet tegen beschermd.
> Omdat je bij een self-signed certificaat geen mogelijkheid hebt te controleren of het certificaat klopt voegt het geen beveiliging toe.

Het voegt toe dat MITM lastiger wordt en eavesdropping zonder interference onmogelijk wordt. Dat lijkt mij toch een enorme verbetering. Je weet niet met wie je praat, dat klopt. Je weet echter wel dat je (aangenomen dat die target veilig is) dat je alleen met die target praat, en dat je de volgende keer weer met dezelfde target praat. Daar is op zich al heel veel aan - als een self-signed cert wordt vervangen of iemand een MITM doet krijgt elke gebruiker een nieuwe query. Elke websiteeigenaar zal dan kijken wat daar de oorzaak van is.
Self-signed certificaten zijn waardeloos voor andere dingen dan testdoeleinden. Jij zegt dus dat een particulier de communicatie naar zijn/haar website niet meer mag beveiligen?
Volgens mij klopt dat niet: een self signed ssl certificaat encrypt wel degelijk alle communicatie tussen client en server. Dus is het een prima oplossing om bijvoorbeeld via die encrypted tunnel op een hotspot te internetten (mail uitlezen met name). Het verschil met officiele certificaten is dat die CA's in de browser zijn opgenomen en dat je dus vrij zeker bent dat je met de juiste server communiceert (dat je weet dat je met de officiele gmail server bent verbonden).

Maar self signed certificaten encrypten wel degelijk de communicatie !
Het enige, maar meteen het grootste probleem is de betrouwbaarheid.
Inderdaad ja.

Sterker nog, waarom zou een buitenlandse site dan een KvK inschrijving moeten hebben? Immers, buitenlandse overheden gaan we natuurlijk niet vertrouwen hierin. Indien we dat dan wel zouden doen, gaat iedereen certificaten halen in het land waar ze het gemakkelijkst verkrijgbaar zijn (lees: een bananenrepubliek).

Certificaten via KvK/notaris is gewoon kansloos.
Bij een nl domein voor bedrijven kun je het nog wel via de KvK laten doen. Maar voor particulieren... ehm tja :/

Op dit item kan niet meer gereageerd worden.



Populair: Nokia Lumia 930 Nokia Lumia Smartphones Google Laptops Sony Apple Games Politiek en recht

© 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