Cookies op Tweakers

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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 48 reacties, 27.258 views •

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)

Reactiefilter:-148047+139+28+30
Moderatie-faq Wijzig weergave
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.
Het probleem van Diginotar was nou juist dat ze hun belangrijkste certificaat gegevens online hadden staan.
Als er geen alternatieven beschikbaar zijn, dan wordt het wel heel erg lastig om nog certificaten te krijgen als een van je certificaten ongeldig wordt door een hack...
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 316234 op 30 december 2012 00:59]

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.
een 4096 bits lange sleutel is in hexadecimalen 512 tekens
Nee, 1024.
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.
Eigenlijk heeft een beveiligingsmethode waarbij je bepaalde mensen in vertrouwen moet nemen per definitie al een lek.
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]

Het enige, maar meteen het grootste probleem is de betrouwbaarheid.
Bij een nl domein voor bedrijven kun je het nog wel via de KvK laten doen. Maar voor particulieren... ehm tja :/
Leuk in theorie, totale faal in praktijk. Zie Diginotar. Het fundamentele probleem wordt niet opgelost zo.
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.
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.
een onbeveiligd domain... wat bedoel je daar precies mee...

ik denk dat je je vergist met ssl versus non-ssl... en daar ga je dan direct al fout... dns beschermt je in principe tegen dns-vervuiling...

met andere woorden, ALS je erop kunt vertrouwen dat de gevens in de dns juist zijn, DAN weet je dus ook dat de beheerder van het domein de juiste public key heeft toegevoegd,

je weet in feite dus zeker dat de ssl sessie die je start, gaat tussen jouw en de computer van de domain-eigenaar.

die gaat goed, zolang je de authoritieve dns server voor het domain kunt vertrouwen... en daar sluit ik aan op je verhaal, dat het misschien beter zou zijn de registrars aan te spreken in plaats van 3rd party. al leg je feitelijk de spof slechts bij een andere partij.....

desalniettemin klopte zijn verhaal dus wel, het IN dns verwerken van key-pairing zou de markt mogelijk een stuk overzichtelijker maken

[Reactie gewijzigd door i-chat op 29 december 2012 20:19]

> 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.
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.
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 !

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True