Comodo verstrekte onterecht ssl-certificaat door ocr-fout
Door een fout in de ocr-software die het gebruikte heeft ssl-uitgever Comodo ten onrechte een ssl-certificaat voor de Oostenrijkse internetprovider A1 uitgegeven, waardoor het mogelijk zou zijn geweest om miljoenen abonnees aan te vallen, zo meldt het Duitse Heise.
Ssl-certificaten spelen een belangrijke rol op internet. Ze helpen bij het identificeren van websites en het versleutelen van verkeer van en naar bezoekers. Voor uitgeven van een ssl-certificaat maakt Comodo gebruik van whois-gegevens, die informatie over de eigenaar van een domein bevatten. Via deze informatie kan het geautoriseerde e-mailadres worden verkregen dat de link voor het aangevraagde ssl-certificaat zal ontvangen. In het geval van .be- en .eu-domeinen wordt deze informatie echter als afbeelding aangeleverd.
Comodo maakte gebruik van ocr-software om het e-mailadres uit de afbeelding te halen. De ocr-software heeft echter een probleem met het onderscheiden van een de letter l van het cijfer 1 en de letter o van het cijfer 0. Twee onderzoekers maakten van dit probleem gebruik om voor de Oostenrijkse internetprovider A1 Telekom een ssl-certificaat aan te vragen, waarbij ze het domein altelekom.at gebruikten. De ocr-software maakte hier a1telekom van, waardoor de onderzoekers de e-mail met de link naar het ssl-certificaat voor het echte domein van A1 Telekom ontvingen.
Na te zijn ingelicht besloot Comodo de ocr-software eind september uit te schakelen. De software was sinds eind juli van dit jaar in gebruik. Volgens Comodo hebben zich geen andere incidenten door de ocr-fout voorgedaan en is het onterechte ssl-certificaat voor A1 Telekom inmiddels ingetrokken. Na publicatie door Heise maakte Comodo ook melding bij Mozilla, wat voor enige kritiek zorgde vanwege het aantal dagen tussen de melding van de onderzoekers en de waarschuwing richting Mozilla.
Volgens Comodo kreeg het op 23 september de melding van de onderzoekers en stopte het op 28 september met de ocr-software. Op vier oktober stuurden de onderzoekers het artikel dat ze naar Heise wilden sturen. Elf dagen later op 15 oktober had Comodo de eerste voorlopige versie van het eigen rapport afgerond. De uiteindelijke versie werd op 19 oktober goedgekeurd en gepubliceerd. De ssl-uitgever maakt echter excuses aan Mozilla voor de traagheid waarmee het rapport verscheen. "Er waren teveel mensen bij betrokken wat voor de vertraging zorgde", aldus Robin Alden van Comodo.
Waarom is dit eigenlijk? Waarom kan er niet een simpel formuliertje op de website van Comodo worden ingevuld met de gevraagde gegevens ipv een formulier invullen, uitprinten en opsturen?
Hoeveel mensen bij een onderzoek betrokken zijn is niet relevant voor het informeren. Wat wel relevant is is wie er verantwoordelijkheid heeft om prioriteiten te stellen en beslissingen te nemen.
De prioriteiten lagen niet bij het informeren van de community. Het werd pas prioriteit om te informeren toen de community via de media moest vernemen dat Comodo weer niet betrouwbaar bleek om als CA. Ik ben benieuwd door wie die beslissing is genomen. Dat is waarschijnlijk dezelfde persoon die al verantwoordelijk was om prioriteiten te stellen en beslissingen te nemen, Robin Alden.
Waarom is dit eigenlijk? Waarom kan er niet een simpel formuliertje op de website van Comodo worden ingevuld met de gevraagde gegevens ipv een formulier invullen, uitprinten en opsturen?
Zo te lezen in het Duitse artikel doe je de aanvraag, en haalt Comodo dan zelf gegevens op via whois.
Dat is vrij logisch en terecht om de (echte) domein eigenaar zelf op te zoeken.
(je wilt niet dat jansen@ziggo.nl certificaten voor ziggo.nl kan aanvragen en de bevestingslink zelf krijgt).
En blijkbaar leveren deze whois'en de gegevens als image - volgens het artikel is dat een anti-spam/anti adres harvest maatregel.
Waarom is dit eigenlijk? Waarom kan er niet een simpel formuliertje op de website van Comodo worden ingevuld met de gevraagde gegevens ipv een formulier invullen, uitprinten en opsturen?
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.
