De zwakste schakel van https

Http(s)

De structuur van het web mag vandaag de dag in de basis nog steeds hetzelfde zijn als toen Tim Berners-Lee het http-protocol ontwikkelde, de manier waarop het wordt gebruikt, is sterk veranderd. Http staat niet voor niets voor hypertext transfer protocol: het protocol was aanvankelijk enkel bedoeld om pagina's op te vragen, niets meer en niets minder. Internetbankieren en webmail waren in 1991 niets meer dan fictie.

Vertrouwelijke communicatie is dan ook nooit ingebouwd in het protocol. Omdat het onderliggende tcp/ip-protocol eveneens niet is ontworpen voor vertrouwelijke communicatie, is dat een risico: als op één punt in de verbinding het netwerkverkeer kan worden afgeluisterd, kan de communicatie worden onderschept, ook wel een 'man in the middle'-aanval genoemd.

Een man in the middle-aanval. Afbeelding: OWASP.

Onder meer gebruikers van wifi-hotspots lopen risico slachtoffer te worden van dergelijke aanvallen, maar ook een gehackte router bij een internetprovider kan een gevaar zijn. Dat dit geen fictie is, bewijst de recente aanval op KPN, waarbij hackers hebben ingebroken op een core-router.

Veilig...

Om vertrouwelijke communicatie via het web over een niet gegarandeerd veilige verbinding mogelijk te maken, is er https, simpel gezegd http met een ssl/tls-encryptielaag. Https zorgt er onder meer voor dat gegevens worden versleuteld, zodat iemand die de data onderschept, er niets mee kan, mits de versleuteling sterk genoeg is.

Versleuteling op zich is echter niet genoeg: het is ook belangrijk om te weten met wie er wordt gecommuniceerd. Anders zou een aanvaller zichzelf kunnen voordoen als een legitieme server, waarbij al het verkeer onderweg netjes wordt versleuteld, maar de aanvaller de informatie als ontvanger kan lezen. Daarvoor bestaat vandaag de dag een systeem van certificaat-autoriteiten.

Iedereen kan voor zichzelf een ssl-certificaat, gekoppeld aan een domeinnaam, aanmaken, maar die selfsigned-certificaten worden niet standaard door browsers vertrouwd. Om door een browser vertrouwd te worden, moet een certificaat worden ondertekend met een root-key van een certificaat-autoriteit.

Het idee achter dit systeem, vastgelegd in de X.509-specificatie, is dat de certificaat-autoriteiten bepalen of iemand een bepaald certificaat wel mag uitgeven. Is dat zo, dan wordt het certificaat ondertekend met de privésleutel van de certificaat-autoriteit.

X.509 wordt overigens niet alleen gebruikt voor https: ook de veilige equivalenten van onder meer de e-mailprotocollen imap en pop leunen op dit principe. Het is een van de steunpilaren voor veilige communicatie. Is dat terecht?

Browsermakers - en ontwikkelaars van e-mailsoftware, bijvoorbeeld - leveren de publieke sleutels van vertrouwde certificaat-autoriteiten mee. Als een certificaat van een webserver is ondertekend door een certificaat-autoriteit wier publieke sleutel is ingebouwd in de software, dan wordt het certificaat vertrouwd.

...of niet?

Nog los van meerdere exploits waarbij onderzoekers valse X.509-certificaten konden genereren, bijvoorbeeld doordat het inmiddels achterhaalde md5-hashing-algoritme werd ondersteund, heeft het certificatensysteem een achilleshiel. Of, beter gezegd: ongeveer 650 achilleshielen.

650 achilleshielen

In 1995 werd VeriSign opgericht; het was de eerste certificaat-autoriteit. Inmiddels zijn er heel wat meer: een stuk of 650 organisaties wereldwijd hebben het recht om vertrouwde certificaten uit te geven.

Onder hen zijn commerciële partijen zoals VeriSign en Comodo, maar bijvoorbeeld ook overheden. Zo kan de Nederlandse overheid certificaten uitgeven, maar ook die van de Verenigde Staten, Rusland en China.

Een probleem daarbij is dat elke certificaat-autoriteit een certificaat voor elke domeinnaam mag aanmaken.

Dat betekent dat als een enkele 'ca' valse certificaten uitgeeft, het complete systeem van certificaat-autoriteiten in één klap onbetrouwbaar is gemaakt. Elke certificaat-autoriteit is een single point of failure.

Dat is niet automatisch schadelijk, zo lang elke autoriteit elke certificaat-aanvraag voor uitgifte goed controleert. Helaas is dat echter niet zo. De Beverwijkse certificaat-autoriteit DigiNotar, die onder meer DigiD beveiligde, werd deze herfst wereldberoemd toen bleek dat het na een hack honderden valse ssl-certificaten had uitgegegeven. Een vals certificaat zou in Iran zijn gebruikt om Google-gebruikers te bespioneren.

Hetzelfde overkwam het veel grotere Comodo, dat via een reseller valse domeinnamen uitgaf voor onder meer Google, Yahoo, Mozilla en Microsoft. Ook VeriSign werd onlangs gehackt, al zouden daarbij geen certificaten zijn gegenereerd.

Een certificaat-autoriteit hoeft echter niet te worden gehackt om valse certificaten uit te geven. Zo bleek uit onderzoek van de EFF dat er vele duizenden valse ssl-certificaten in omloop zijn voor niet-unieke hosts, bijvoorbeeld voor op een intern netwerk. Zo zijn er circa vijfduizend certificaten voor 'localhost' uitgegeven. Er zijn zelfs certificaat-autoriteiten die meerdere klanten een ssl-certificaat voor hetzelfde lokale domein gaven, wat niet mag. Dat duidt er op dat ze niet goed controleren of een certificaat wel mag worden uitgeven. Meerdere beveiligingsonderzoekers hebben bovendien in de afgelopen jaren bij certificaat-autoriteiten valse ssl-certificaten kunnen aanvragen.

Blacklisting

Een ssl-certificaat terugtrekken, bijvoorbeeld omdat deze vals blijkt, is mogelijk via blacklisting. De manier waarop dat is gebeurd, is de afgelopen tijd verbeterd: vroeger gebeurde dat via lijsten met teruggetrokken certificaten, maar dat kan nu realtime via het online certificate status protocol. Browsers kunnen daardoor snel controleren of een certificaat nog geldig is.

Een probleem is echter dat alle browsers het 'soft fail'-principe hanteren. Als een ocsp-controle faalt door netwerkproblemen, wordt het certificaat toch geaccepteerd, terwijl de authenticiteit niet vaststaat. Het alternatief - een certificaat weigeren als het niet kan worden gecontroleerd - , betekent dat netwerkproblemen bij een certificaatautoriteit ervoor zorgen dat websites met certificaten van die autoriteit niet meer kunnen worden bezocht. Dat is dan ook de reden dat veel browsers 'soft fail' hanteren.

Google heeft aangekondigd dat het in Chrome stopt met de ondersteuning van ocsp. In plaats daarvan gaat het zelf een lijst met teruggetrokken certificaten bijhouden. Of dat beter werkt, moet de toekomst uitwijzen: Symantec is in ieder geval sceptisch.

O Certificates, Where Art Thou?

Voor het kunnen terugtrekken van certificaten is het daarnaast nodig dat de certificaatautoriteit goed bijhoudt welke certificaten geldig zijn en welke niet meer. Dat gebeurt niet altijd, zoals onder meer blijkt uit de DigiNotar-hack. Het bedrijf hield de hack geheim en trok geen certificaten terug, waardoor deze nog anderhalve maand misbruikt konden worden.

Bovendien wist DigiNotar van een groot deel van de valse certificaten zelf niet eens dat deze überhaupt bestonden en had het deze met de beste wil van de wereld niet terug kunnen trekken: daarvoor is namelijk een serial nodig, waarover het bedrijf niet beschikte.

Daarnaast is er geen gestandaardiseerde manier om root-sleutels van certificaat-autoriteiten in te trekken. Daarvoor moet de sleutel handmatig door de gebruiker worden uitgeschakeld of moet de browser- of os-maker een update verspreiden waarin de root-sleutel op 'niet vertrouwd' wordt gezet. Dat gebeurde bij diezelfde DigiNotar-hack.

Untrusted trust

Sommige vertrouwde certificaat-autoriteiten bieden tegen betaling rootcertificaten aan, waarmee een ssl-certificaat voor elk gewenst domein kan worden aangemaakt. Dit is nodig voor sommige beveiligingssoftware die ook https-verkeer onderschept, maar maakt het ook mogelijk voor kwaadwillenden om valse certificaten te genereren.

Het bedrijf Trustwave stopte na ophef onlangs met het aanbieden van rootcertificaten, maar bijvoorbeeld VeriSign-dochter GeoTrust biedt tegen betaling van 40.000 dollar per jaar de mogelijkheid om een root-certificaat aan te vragen. "Je kunt dan valse certificaten aanmaken voor elke mogelijke website, zolang je GeoTrust maar belooft dat je dat niet doet", vertelde beveiligingsexpert Moxie Marlinspike onlangs op de RSA Conference, een beveiligingsconferentie in San Francisco.

Een potentieel gevaar is ook dat overheden van landen met een minder goede track record op het gebied van mensenrechten, zoals China, certificaten kunnen aanmaken. De Chinese organisatie CNNIC, onderdeel van het Chinese Ministerie van Informatie, wordt door onder meer Firefox, Internet Explorer en Google Chrome vertrouwd, hoewel deze organisatie in het verleden zelfs malware heeft geproduceerd.

Je browser vertrouwt standaard de Chinese overheid.

Dnssec en certificate pinning

Het probleem met het systeem van certificaatautoriteiten is dat het alomtegenwoordig is, en dat de overstap naar een ander systeem daardoor veel tijd en energie gaat kosten. Dat wil niet zeggen dat er geen alternatieven zijn.

Minder certificaat-autoriteiten

Er zijn circa 650 certificaat-autoriteiten en het risico dat ten minste één daarvan een zwakke schakel is, is erg groot. Een oplossing zou het verminderen van het aantal autoriteiten kunnen zijn, en alleen de meest betrouwbare autoriteiten voort laten bestaan. De vraag is echter of dat het probleem echt oplost: toen er nog maar één certificaat-autoriteit was, was de kritiek niet minder, omdat die autoriteit - VeriSign - alles kon doen en laten wat ze wilde.

Als het aantal certificaat-autoriteiten afneemt, krijgen de overgebleven autoriteiten bovendien veel meer verantwoordelijkheid, omdat ze onvermijdelijk veel meer certificaten in hun bezit zullen krijgen. Dat maakt ze ook een stuk interessanter voor hackers.

Dnssec

Op het eerste gezicht zou dnssec een alternatief voor het systeem kunnen zijn. Dnssec is een aanvulling op het dns-protocol waarmee de authenticiteit van dns-records kan worden geverifieerd. Het certificaat wordt als dns-record opgeslagen. Daarmee wordt bijvoorbeeld dns cache poisoning tegengegaan en zou een internetgebruiker zekerheid hebben of hij de juiste website bezoekt.

Onderzoeker Moxie Marlinspike heeft daar echter zijn bedenkingen bij. Zo worden hostingproviders daarmee min of meer verantwoordelijk voor het verstrekken van certificaten. "Hostingproviders zijn nog meer sketchy dan certificaat-autoriteiten", aldus Marlinspike. Zeker is in ieder geval dat hun aantal groter is dan het aantal certificaat-autoriteiten.

Ook krijgen de beheerders van de tld's - in het geval van .com is dat VeriSign - een grote vinger in de pap bij dnssec, evenals het ICANN, dat de root-zone beheert. De vraag is of dat gewenst is: het ICANN valt onder de Amerikaanse overheid. "We moeten ons afvragen of we alle vertrouwelijke communicatie bij deze organisatie willen neerleggen", zegt beveiligingsonderzoeker Marlinspike. Bovendien kunnen certificaten bij dnssec niet handmatig worden uitgeschakeld.

Certificate pinning

Een ander alternatief is certificate pinning, functionaliteit waarover op dit moment enkel Google Chrome beschikt. Bij certificate pinning wordt aangegeven welke certificaat-autoriteiten certificaten voor een bepaald domein uitgeven. Dit was ook de manier waarop de DigiNotar-hack werd ontdekt: een Iraanse Gmail-gebruiker kreeg een waarschuwing van Chrome, omdat een website die zichzelf als Gmail presenteerde een DigiNotar-certificaat meestuurde om dat te 'bewijzen'. DigiNotar mocht van Chrome echter helemaal geen certificaten voor Gmail uitgeven.

Op dit moment werkt certificate pinning enkel nog met Google-websites. Of de functionaliteit kan uitgroeien tot een algemeen inzetbare veiligheidsmaatregel, is onzeker. Op dit moment zijn de certificate pins hardcoded, dus elke nieuwe 'pin' moet aan de code worden toegevoegd. Dat is niet erg schaalbaar en maakt een overstap op een andere certificaat-autoriteit omslachtig. Het blijft bovendien een lapmiddel.

Perspectives en Convergence

Een ingrijpender aanpak is voorgesteld door onderzoekers van de Carnegie Mellon-universiteit in de Verenigde Staten: Perspectives. Dit systeem introduceert het principe multi-path probing: een ssl-certificaat wordt via verschillende ip-routes geverifieerd.

In de praktijk werkt dat zo: bij het bezoeken van een beveiligde website wordt aan een speciale server, een notary, gevraagd of deze hetzelfde certificaat krijgt bij het laden van de site. Als dat zo is, is het een legitiem certificaat en vindt er geen man in the middle-aanval plaats, is het idee. De authenticiteit van een server met een selfsigned-certificaat kan daardoor worden gecontroleerd.

Perspectives kan worden gedownload als Firefox-add-on, maar deze werkt niet perfect: het werkt alleen voor de initiële https-request en niet voor aanvullende verzoeken, bijvoorbeeld scripts.

Beveiligingsonderzoeker Marlinspike ziet ook hier een aantal beren op de weg. Zo is de privacy in Perspectives niet gewaarborgd: wanneer een gebruiker een notary vraagt om het certificaat te vergelijken, weet die welke website wordt bezocht. Bovendien is het systeem traag, omdat een andere server telkens om bevestiging moet worden gevraagd. Ook belangrijk: dit systeem is niet bedoeld om certificaat-autoriteiten te vervangen, maar als extra verificatie.

Convergence

Marlinspike heeft zelf een project opgezet dat voortborduurt op het Perspectives-systeem: Convergence. In tegenstelling tot Perspectives is Convergence bedoeld om het systeem van certificaat-autoriteiten compleet buitenspel te zetten: wie Convergence inschakelt, maakt geen gebruik meer van het stelsel van autoriteiten.

Ook Convergence gebruikt multi-path probing, maar dankzij de aanwezigheid van caching is Convergence aanmerkelijk sneller. Ook Convergence kan als Firefox-add-on worden gebruikt.

ING.nl: Links zonder Convergence, rechts met.

Ook is de privacy beter gewaarborgd, dankzij notary bouncing. Een notary wordt daarvoor gevraagd om een verzoek door te sturen naar een andere server. De eerste server weet alleen wie het verzoek doet, de tweede weet enkel voor welke server een certificaat moet worden geverifieerd. Geen van beide weet dus wie welke website bezoekt. Voor de controle van certificaten worden meerdere notaries gebruikt: standaard zijn dat er drie. Er is dus geen single point of failure meer.

Convergence is - net als Perspectives - gebaseerd op het ideaal van trust agility: een gebruiker bepaalt zelf welke notaries hij vertrouwt. Het niet vertrouwen van een notary heeft bovendien geen gevolgen: dan kan een andere notary worden gebruikt om certificaten te controleren. Dat is een fundamenteel verschil ten opzichte van het certificatensysteem. Als iemand besluit VeriSign of Comodo niet langer te vertrouwen, kunnen veel websites niet meer worden bezocht.

Volgens Marlinspike is een switch van het certificatensysteem naar Convergence eenvoudig: als iedereen de add-on installeert, kunnen bedrijven als VeriSign en Comodo opdoeken, redeneert hij. Daarbij laat hij wel één belangrijk aspect achterwege: het beheer van de notary-servers.

Handvol notaries

Op dit moment zijn er een handvol notaries, beheerd door Marlinspike zelf en ict-beveiligingsbedrijf Qualys. Het lijdt geen twijfel dat die het verkeer onmogelijk aankunnen als elke internetgebruiker opeens overstapt op Convergence. Dan zullen er dus meer notaries moeten komen, maar wie wil die taak op zich nemen?

Dat is ook een reden van Adam Langley, beveiligingsonderzoeker van Google, om Convergence niet in Chrome in te bouwen. Hij spreekt zijn waardering uit voor het werk van Marlinspike, maar stelt ook dat aangezien de standaard-notaries nooit de traffic van alle Chrome-gebruikers aan zouden kunnen, Google zelf voor notary zou moeten spelen.

"Het komt er op neer dat Chrome naar huis belt voor het verifiëren van certificaten", schrijft Langley. Dat heeft volgens hem gevolgen voor de privacy en legt een zware last op Google. Over trust agility zegt hij dat een mooi idee is, maar dat 99,99% van de Chrome-gebruikers de standaard-instellingen nooit zal wijzigen.

Zowel Convergence als Perspectives kampen daarnaast met een probleem: captive portals en andere lokale hosts, zoals intranetten. Captive portals zijn de landingspages waar je bijvoorbeeld bij wifi-hotspots in hotels en op vliegvelden op terecht komt. Als die met een ssl-certificaat zijn beveiligd, kunnen die niet via Convergence of Perspectives worden gecontroleerd, omdat ze de host simpelweg niet via een andere route kunnen bereiken. Hetzelfde geldt voor intranetten die enkel vanaf het lokale netwerk te benaderen zijn.

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)

[itlee]

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

[totaalgeenhard]

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.

[dukejan]

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.

[Hmmbob]

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.

[humbug]

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.

[Rob Coops]

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.

[mjtdevries]

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.

[Don Corleone]

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.

[dukejan]

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.

[Iblies]

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.

[RazorBlade72nd]

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.

[martijnsch]

Hier zijn spotjes van op tv geweest.

[Infant]

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.*}

[CAPSLOCK2000]

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?

[Durandal]

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.

[cdwave]

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.

[Garma]

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

[Masterlans]

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

[mhkool]

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.

[BeosBeing]

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.

[Verwijderd]

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.

[LuckY]

Éé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.

[Verwijderd]

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.

[LuckY]

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 25 juli 2024 15:00]

[osorkon!]

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?

[Joindry]

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.

[ppaulv]

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 !

[Buggle]

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.

[sjongenelen]

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

[eddie4nl]

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.

[Woy]

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

[Buggle]

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 25 juli 2024 15:00]

[nickko]

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

[LuckY]

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.

[morrowyn]

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

[LuckY]

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

[mhkool]

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.

[thegve]

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.

[Keypunchie]

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.

[thegve]

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