Nokia ontsleutelt SSL-verkeer van gebruikers

| AE 4956 | Beveiliging | 32 reacties

nokia-xpress-browserDe Nokia Xpress browser voor Asha en Lumia-toestellen heeft een proxy-server die vertrouwelijk HTTPS-verkeer middels een eigen certificaat ontsleutelt, zonder dat gebruikers zijn geïnformeerd. Dat schreef Webwereld vrijdag. Met die proxserver versnellen ze het verkeer naar mobiele apparaten, wat op zich handig is, maar dat bij versleuteld verkeer doen is opmerkelijk: alsof de taxichauffeur je koffers even opnieuw inpakt zodat het beter past in de achterbak. Maar is het verboden?

Het doel van de Nokia-proxy is dataverkeer versnellen. Dat doen er wel meer (Opera is er groot mee geworden) maar opmerkelijk bij Nokia is dat ze het ook doen voor beveiligd verkeer. Dat is bepaald niet de bedoeling, want beveiligd (SSL) verkeer is nu juist bedoeld om niet onderschept te kunnen worden. Maar ja, als je de browser controleert dan kun je zo ongeveer alles. Heel kort gezegd komt het erop neer dat Nokia’s proxy zich voordoet als je browser naar de site (van bv. je bank) toe, en naar jou toe zich voordoet als de bank. Daardoor denkt de browser (met dank aan een speciaal Nokiacertificaat) dat alles in orde is, en meent de bank gewoon met jou te communiceren. In securitytermen heet dit een “man in the middle attack”.

Is zo’n aanval strafbaar als je het als browserbakker doet? Ik zou geen wetsartikel weten eigenlijk. We hadden in 2011 een ietwat vergelijkbare discussie in de KPN DPI-affaire, waarbij het telecombedrijf met deep packet inspection-achtige technieken het verkeer van gebruikers analyseerde om onder meer te zien of men WhatsApp gebruikte. Dit leidde tot de netneutraliteitswet want dit moest toch écht niet kunnen.

Diverse partijen, waaronder ikzelf, hadden toen geroepen dat KPN de strafwet overtrad. Artikel 139c lid 1 Strafrecht verbiedt namelijk

opzettelijk en wederrechtelijk met een technisch hulpmiddel gegevens aftappen of opnemen die niet voor hem bestemd zijn en die worden verwerkt of overgedragen door middel van telecommunicatie of door middel van een geautomatiseerd werk.

Dit artikel gaat nadrukkelijk niet alleen om het afluisteren van inhoud maar ook om analyses van de gegevensoverdracht zelf. Daarmee leek me óók DPI een strafbare zaak. Mar

Bovendien is er lid 2 van dit artikel, dat bepaalt:

[Het verbod] is niet van toepassing op het aftappen of opnemen … ten behoeve van de goede werking van een openbaar telecommunicatienetwerk.

en zeker in de Nokia-situatie zie ik dit wel van toepassing zijn. Het enige doel (nemen we dan maar aan) is het netwerkverkeer versnellen, en dat valt toch wel onder “goede werking”. Een verwerking van persoonsgegevens lijkt het me ook niet echt, en voor zover het dat al zou zijn dan valt dit onder “uitvoering van de overeenkomst”. Wel behoort Nokia dan te melden dat ze dit doen, en het is opmerkelijk dat ze dit nergens documenteren. Maar juridisch gezien heet dat “een slordigheidje”, meer niet.

Ondertussen is Nokia zo geschrokken van de ophef dat ze nu gewoon geen SSL-verbindingen meer opzetten. De data wordt nog wel veilig opgehaald bij de beveiligde site, maar vanaf de Nokia-proxy onversleuteld doorgegeven. Eh. Dat is nou juist mínder handig. Update (15/1): Hoewel? Ze tunnelen https verkeer over deze onversleutelde verbinding. Zo komt het verkeer toch veilig aan.

Arnoud

Is Diginotar aansprakelijk voor de schade uit frauduleuze certificaten?

| AE 2683 | Aansprakelijkheid, Beveiliging | 63 reacties

diginotar-subroot-digid.pngAuw. Iraans verkeer naar Gmail kon worden afgetapt dankzij een door Diginotar goedgekeurd certificaat, zo bleek deze week. Alle grote browsers revoceerden meteen het certificaat van Diginotar, hoewel Firefox later een uitzondering maakte voor DigiD. Na enig getreuzel kwam Diginotar-eigenaar Vasco met een verklaring dat men in juli was gehackt, waarna bleek dat in ieder geval de website al jaren kwetsbaar was. En daarna dook nieuws op dat er nog veel meer valse certificaten in omloop waren, waaronder voor anonimiteitsnetwerk Tor. Heeft Diginotar nu een probleem of niet?

Laten we eens doen of de publiciteit niet al genoeg is om het einde van Diginotar als merknaam in te luiden, en de juridische gevolgen bekijken van deze faal. De wet kent namelijk de nodige bepalingen over certificatiedienstverleners, oftewel personen of bedrijven die certificaten afgeven of andere diensten in verband met elektronische handtekeningen verleent, zoals de Telecommunicatiewet ze definieert.

Toen e-commerce een beetje populair begon te worden, ontstond behoefte aan het zetten van digitale handtekeningen. Waarom is mij volstrekt onduidelijk, handtekeningen zijn namelijk zelden tot nooit nodig in het handelsverkeer. Ja, als je een huis wilt kopen, maar dat is nu net een van de weinige dingen die je niet via een internetdienst kunt doen. Maar goed, er moesten digitale, pardon elektronische handtekeningen komen en daar moest dan een hele infrastructuur bij opgezet worden om te kunnen controleren wie die had gezet. Ik ben daar ooit op afgestudeerd maar ondertussen best wel cynisch over het nut van deze hele poppenkast. Waar is de infrastructuur voor analoge handtekeningen?

Afijn, die infrastructuur oftewel PKI is waar Diginotar een rol in speelde. De opzet van deze infrastructuur is hiërarchisch: we vertrouwen een partij met een certificaat omdat de uitgever van dat certificaat zegt dat dat klopt. En we vertrouwen die uitgever omdat ook hij een certificaat heeft waarvan de uitgever zegt dat het klopt. Enzovoorts, enzoverder tot we bij de wortel van deze hiërarchische boom zijn. (Terzijde: informatici tekenen zulke bomen met de wortel aan de bovenkant. Argh.) Diginotar heeft de positie van root CA, wat zo veel wil zeggen als dat wanneer Diginotar het zegt, het klopt. Gewoon, omdat het kanergens ophoudt. (Overigens geldt dit niet voor DigiD, daar is Diginotar ‘slechts’ sub-root onder de Staat der Nederlanden.)

diginotar-certificaat-faal-auw.pngVertrouwen is dus het fundament waar de dienstverlening van een certificatiedienstverleners op stoelt. Immers, een echt certificaat is op geen enkele wijze te onderscheiden van een per abuis of met kwade trouw uitgegeven certificaat. De enige controle is de elektronische handtekening die erbij staat, maar die zegt niets over de inhoud. Het certificaat waar het allemaal mee begon, vermeldde de sites van Google (*.google.com) maar was in gebruik bij een partij die niet Google was. Dat is fataal voor de goede werking van een PKI.

“Gekwalificeerde” certificaten mag je alleen uitgeven als je geregistreerd bent bij de OPTA (wat Diginotar ook keurig is). Een gekwalificeerd certificaat is een certificaat dat uitgegeven is door een geregistreerde partij die zich netjes aan de regels houdt over betrouwbaarheid, en dat aan een persoon gekoppeld is.

Aan een dienstverlener die dergelijke certificaten uitgeeft, worden zware eisen gesteld door de wet en het daarbij behorende besluit. Zo moet je ETSI TS 101 456 naleven en houdt OPTA toezicht. En de wet (art. 6:196b BW) verklaart de dienstverlener aansprakelijk voor alle schade door onjuist uitgegeven certificaten, tenzij zij kan bewijzen dat zij niet onzorgvuldig heeft gehandeld, of als het certificaat ingetrokken was voordat de schade ontstond, of als het certificaat voor een niet in het certificaat vermeld doel werd aangemerkt.

Alleen: de SSL-certificaten waar het om gaat, zijn geen gekwalificeerde certificaten. Daarmee is die bijzonder strenge aansprakelijkheidsregel niet van toepassing. En dan wordt het lastig, want dan is Diginotar juridisch gezien gewoon een club die iets zegt met een digitale handtekening eronder, en tsja, afgaan op wat mensen zeggen is geen reden om ze aansprakelijk te stellen als ze het fout hadden. Anders heb ik nog wel een leuke claim tegen Astro-TV. Voor aansprakelijkheid is meer nodig: je moet een wettelijke norm geschonden hebben (die in direct verband staat met de schade) of je moet maatschappelijk onzorgvuldig hebben gehandeld, oftewel “dit staat niet in de wet maar vinden we toch dusdanig onfatsoenlijk dat je alsnog schade moet vergoeden”.

Bij die onzorgvuldigheidsnorm wegen altijd de exacte omstandigheden van het geval zwaar. Zo zal bijvoorbeeld meewegen wat de oorzaak van de hack is waarmee deze certificaten gegenereerd konden worden. Was men nalatig in het sleutelbeheer? Of was dit een buitengewoon geavanceerde zero-day hack (à la de RSA phish) die niemand had kunnen opmerken? Heeft Diginotar na het ontdekken van de hack alles gedaan om de gevolgen tegen te gaan, of heeft ze juist zitten treuzelen?

Als blijkt dat ze te weinig hebben gedaan, dan kunnen getroffen Gmailende Iraniërs ze aansprakelijk stellen voor hun schade – alleen zal die lastig aan te tonen zijn. Maar ook andere partijen die getroffen zijn door de onjuist uitgegeven certificaten kunnen dit proberen. Zo zou een webwinkel die zijn SSL-certificaat ongeldig ziet worden omdat Mozilla of Microsoft Diginotar niet meer erkent, omzet kunnen mislopen omdat mensen niet meer durven te bestellen door de foutmeldingen die ze dan krijgen. Gemiste omzet is natuurlijk wel lastig om te onderbouwen, maar zoals uit een zaak tussen TROS Radar en een hondenfokker bleek, kan een deskundige worden opgeroepen die de boeken onderzoekt en inschat wat de omzet of winst zou zijn geweest. In de Radar-zaak werd die op een half miljoen euro geschat.

Arnoud

MD5-beveiligingsmechanisme achter vertrouwde websites gekraakt

| AE 1391 | Beveiliging, Webwinkels | 8 reacties

Nou, mooi is dat. Ben ik net uit bed na een erg leuke oudejaarsavond, blijken een stel beveiligingsonderzoekers e-commerce gekraakt te hebben. Of nou ja, de beveiligingstechniek achter een hoop e-commerce sites. Dit omdat het MD5-algoritme, een klein maar cruciaal deel van de gebruikte beveiligingstechniek al drie -pardon, vier, het is 2009- jaar bijzonder zwak blijkt te zijn. Dankzij deze zwakte kan een aanvaller een nepsite voorzien van volstrekt authentiek uitziende certificaten, zodat niemand meer kan detecteren dat het een nepsite is.

Beveiligde websites, veel gebruikt bij e-commerce sites, maken gebruik van certificaten waarmee een browser kan vaststellen of hij met de echte site communiceert. Die certificaten worden uitgegeven door onafhankelijke instanties zoals CACert of Thawte, en zijn voorzien van hun digitale handtekening zodat er niet mee te knoeien valt.

De fout zit in het MD5-algoritme, dat gebruikt wordt bij het genereren van die digitale handtekening. MD5 genereert een hash, een korte code die uniek is voor het te signeren certificaat, en vervolgens wordt de handtekening geplaatst over die hash. Dit is veel sneller dan het hele certificaat zelf signeren. Het blijkt namelijk veel eenvoudiger dan gedacht om een tweede certificaat te genereren met inhoud naar keuze dat dezelfde hash heeft als het certificaat van zo’n instantie. En daarmee zal iedere browser dat nepcertificaat accepteren als authentiek.

Al in 2005 was bekend dat het MD5-algoritme deze zwakheid had, maar tot nu toe werd dit door veel mensen als een puur theoretische mogelijkheid afgedaan. Met deze publicatie wordt duidelijk dat dit een reële dreiging is. Gelukkig hebben zowel Microsoft als Mozilla maatregelen aangekondigd.

Klikken jullie trouwens ook al die irritante waarschuwingen over certificaten weg zonder ze te lezen? Ik zou het liever niet doen, maar soms heb je weinig keus als je een bepaalde website wilt gebruiken.

Arnoud