Onderzoeker demonstreert probleem met EV SSL-certificaten
Extended Validation (EV) SSL-certificaten moeten gebruikers meer zekerheid geven over de identiteit van de website die ze bezoeken, aangezien de eigenaar extra is gecontroleerd, maar onderzoeker Ian Carroll heeft een probleem met dergelijke certificaten aangetoond.
Bij EV SSL-certificaten wordt de naam van de entiteit die het certificaat aanvroeg in de adresbalk van de browser weergegeven. Voordat het certificaat wordt uitgegeven vindt er een uitgebreidere controle plaats dan bij normale SSL-certificaten het geval is. EV SSL-certificaten zijn dan ook duurder dan normale SSL-certificaten en worden anders door de browser weergegeven. Ondanks de uitgebreidere controle wist Carroll een EV SSL-certificaat voor "Stripe, Inc" te bemachtigen. Stripe is een Amerikaanse online betalingsverwerker die in 25 landen actief is, waaronder Nederland. Stripe Inc is geregistreerd in Delaware. Carroll registreerde een juridische entiteit met de naam Stripe Inc in Kentucky en wist voor dit "bedrijf" een EV SSL-certificaat aan te vragen.
Normale SSL-certificaten zijn binnen de browser via een groen slot-icoon te herkennen. Bij EV SSL-certificaten hangt dit deels af van de browser, maar is in ieder geval de naam van de entiteit in kwestie te zien. Safari laat bij de website van Carroll alleen de naam "Stripe Inc" zien, zonder de domeinnaam te tonen. Zowel Chrome als Firefox tonen naast de naam ook het land van de entiteit, alsmede het domein. Via twee muisklikken kunnen Firefox-gebruikers daarnaast de stad en staat van de entiteit zien. Als gebruikers dit al controleren is het nog steeds zinloos, aangezien gebruikers in dit geval moeten weten waar het bedrijf in kwestie zijn hoofdkantoor heeft gevestigd, merkt Carroll op.
De onderzoeker stelt dat het voor een aanvaller zeer praktisch kan zijn om een EV SSL-certificaat registreren. Carroll was in totaal minder dan een uur en 177 dollar kwijt. Honderd dollar voor het registreren van zijn bedrijf en 77 dollar voor het certificaat. Voorstanders van EV SSL-certificaten stellen dat de aanvraag een groot papierspoor achterlaat, maar dat blijkt in de praktijk erg tegen te vallen, aldus Carroll. Zo vindt er nauwelijks identiteitsverificatie plaats. Een kwaadwillende zou zich zo als een bepaald bedrijf of andere entiteit kunnen voordoen en een EV SSL-certificaat kunnen bemachtigen, om dat vervolgens bij phishingaanvallen in te zetten.
Daarin is voor haar geen mogelijkheid voor preventie.
Tja, $bedrijf doet z'n controles, ziet dat het bedrijf in kwestie "bestaat" en geeft een certificaat uit. Dat de naam toevallig veel lijkt op een ander bedrijf? Het zij zo...
Dit is natuurlijk zeker een zwak punt, maar deze is niet beperkt tot EV-SSL. Als hij -volledig legaal- reclame met deze naam aan een winkelpand hangt, geloven mensen het ook.
Het enige wat je hier tegen kunt doen is alle variaties van je eigen bedrijfsnaam/merk/whatever vooraf vastleggen. Maar zelfs dan blijven er wel achterdeurtjes over (even een staat/land/natie verderop kijken, bijvoorbeeld).
Maar is het wel een probleem? Als een ander zich voor jou uitgeeft met een EV-certificaat dan heb je te maken met een boef die zijn identiteit heeft laten controleren. Die moet een stuk makkelijker op te sporen zijn dan gewoonlijk.
Wat ik het grootste probleem vind is dat mensen kennelijk niet bij te brengen is dat de domeinnamen zelf ertoe doen. Firefox laat op deze pagina de URL in grijs zien, behalve "security.nl", dat is zwart. Chromium maakt "www.security.nl" zwart. Het mag er van mij nog een stuk sterker uitspringen, maar is het nou echt zo vreselijk moeilijk om aan te leren dat bij website waarop je aanlogt of gegevens invult dat onderdeeltje moet kloppen? Is het echt te moeilijk om door te krijgen dat "stripe.ian.sh" niet hetzelfde is als "stripe.com"? Is het echt te moeilijk om even na te kijken welke domeinnaam je bank gebruikt voor je ergens intuint?
Ik weet dat er ontzettend veel mensen zijn die niet verder kijken dan hun neus lang is, maar ik vind dat de hele softwareindustrie daar al decennia massaal verkeerd op reageert door dat te faciliteren en actief tot norm te verheffen. Ik pleit er niet voor om dingen overdreven moeilijk te maken, maar een moeilijkheidsniveau vergelijkbaar met even links en rechts kijken voor je de weg oversteekt of zelf je kont afvegen als je naar de wc bent geweest is niet overdreven.
Zoek eens op "SSL decryption virtual wire" en je komt op artikelen van Palo Alto die teruggaan tot 2010
https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-and-Test-SSL-Decryption/ta-p/59719
Op zich wel juist door EV SSL makkelijker te herkennen, omdat je een substituut SSL certificaat aan de eindgebruiker doorgeeft. Moet die enduser wel weten waar hij moet kijken :D
https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-and-Test-SSL-Decryption/ta-p/59719
Op zich wel juist door EV SSL makkelijker te herkennen, omdat je een substituut SSL certificaat aan de eindgebruiker doorgeeft. Moet die enduser wel weten waar hij moet kijken :D
Als je bedoelt dat de problemen hoofdzakelijk zijn dat je PKI (lees: certificaatverstrekkers) onvoldoende kunt vertrouwen (er hoeft maar 1 rotte appel tussen te zitten om het hele systeem te ondermijnen) en dat we geen systeem voor unieke identificatie van organisaties en personen gebruiken (dat borgt dat doorsnee gebruikers niet eenvoudig voor de gek worden gehouden), dan ben ik het met je eens.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
