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. 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: 27.035 •

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)

Uitgifte van ssl-certificaten had m.i. nooit bij commerciŽle partijen mogen liggen. Dat terugdraaien en anders deze bedrijven wel degelijk aansprakelijk maken bij uitgifte van ondeugdelijke certificaten en ook indien ze gehackt zijn en daar schade uit voortvloeit.
CAcert, iemand?

Anyway, ik zag laatst een goed certificaat-alternatief: gewoon in de DNS stoppen. 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.

(Vraagje waar ik direct aan dacht: maar wat nou als je wil verbinden zonder dat er DNS-info beschikbaar is? Antwoord: da's natuurlijk zeer onwaarschijnlijk, want SSL-certificaten zijn alleen te vinden bij domeinen. In de DNS stoppen heeft dus geen nadelen, behalve dat de uitrol van DNSSEC nog even duurt)

[Edit]
Bingo! De naam is DANE (DNS-based Authentication of Named Entities) en is in te zien als RFC 6698

[Reactie gewijzigd door TvdW op 30 december 2012 00:03]

Kip en ei verhaal bij DNSsec omdat dat ook op basis van digitale certificaten werkt. Je wilt een zwakheid in een systeem beveiligen met min of meer hetzelfde systeem?
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)
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]

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 geŽncrypt 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.
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...
"Kunnen de aansprakelijkheid niet aan".

Hoe moet dit anders? Bedrijf geeft certificaat uit, wordt gehackt en EU is aansprakelijk? Of EU geeft certificaat uit? Makkelijk roepen maar het lijkt me logisch dat de verantwoordelijkheid bij het bedrijf ligt. Falen = balen en in geval van veel pech failliet. Lijkt me genoeg reden om er voor te zorgen dat je als bedijf je zaakjes op orde hebt.

Edit: Het bij de overheid neerlegen van uitgifte van dergelijke certificaten werkt censuur in de hand, om nog maar niet te spreken over mogelijke backdoors. Daarnaast hebben we al hele positieve ervaring met ICT projecten vanuit de overheid :P.

[Reactie gewijzigd door kjast op 29 december 2012 15:21]

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.
Waarom moet ik een kvk inschrijving hebben om een certificaat te verkrijgen?

Ik wil als particulier gewoon een ssl certificaat kunnen laten maken.
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 :/
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.
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.
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.
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.
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.
een 4096 bits lange sleutel is in hexadecimalen 512 tekens
Nee, 1024.
Overtikken? Heb je een slag van de digitale molen gehad? :-)
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.
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 is allemaal geneuzel om niks. Militair gesproken stellen certificaten geen hoofdletter K voor. Ze zijn gebaseerd op 2048 bits RSA en dat kraak je militair gesproken gewoon.

Dat lukt al met een jaren 90 algoritme en wat zelfgebouwde cpu's speciaal om te kraken.

Dus welk bedrijf het ook uitgeeft, Iran, bekend om sterke wiskundigen, kraakt dit altijd.

Waarom dus al die kosten maken en gewoon niet je eigen certificaat uitgeven?
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]

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

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

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneAsus

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

Beste nieuwssite en prijsvergelijker van het jaar 2013