Internetrecht door Arnoud Engelfriet

De Autoriteit Persoonsgegevens heeft een boete van 12.000 euro uitgedeeld aan een orthodontistenpraktijk omdat die op een aanmeldformulier geen ssl-verbinding gebruikte. Dat meldde Tweakers vorige week. Door het ontbrekende ‘slotje’ liepen patiënten de kans dat gevoelige gegevens, zoals hun BSN, in verkeerde handen zouden terechtkomen. Opmerkelijk dat die basale beveiligingsmaatregel er niet was, maar minstens zo opmerkelijk dat de AP er voor in actie kwam gezien de beperkte scope. Maar goed, ik ben dus fan van kleine boetes voor kleine overtredingen.

De betreffende website bood klanten van de orthodontist gelegenheid afspraken te maken voor een behandeling. Op zich logischerwijs vroeg men om onder meer NAW-gegevens, geboortedatum, BSN, telefoonnummers van de patiënt en de ouders, gegevens over de school, huisarts, tandarts en de verzekeringsmaatschappij.” Dat formulier werd zonder beveiliging (dus SSL-, TLS-certificaat oftewel “slotje”) opgestuurd, wat inderdaad een beveiligings-dingetje is.

Is het heel erg? Mwa. Technisch betekent het dat iedereen die in het netwerk tussen de klant en de orthodontist zit, de data kan onderscheppen. Het klassieke voorbeeld is het internetcafé of bibliotheek, waar je met de juiste software alles kunt zien dat anderen in diezelfde ruimte opsturen naar websites. Door https te gebruiken, is dit niet langer inzichtelijk – de communicatie naar de site is versleuteld en daarmee niet meer te lezen.

Het aantal scenario’s waarin dit een reëel risico is, is dus beperkt. Vanuit huis is dit bijvoorbeeld geen issue, de buren die ook bij Ziggo zitten kunnen sowieso niet meelezen. Huisgenoten mogelijk wel. Werk je met mobiel internet, dan is dit ook geen serieus risico. Maar natuurlijk is er een niet te verwaarlozen groep mensen die alleen via publieke terminals (zoals de bieb) kan werken, en ook die moet gewoon veilig internet op kunnen.

Daar komt bij: al sinds jaar en dag weet iedereen dat zo’n slotje weinig moeite is, zeker sinds initiatieven als Let’s Encrypt die je gratis certificaten geven om het slotje te realiseren. Dus het voelt als “oké beperkt risico maar het is zo gedaan, doe het dus gewoon” voor mij. Ik blogde er ooit in 2013 over en concludeerde dat het eigenlijk onvermijdelijk is, behalve wellicht bij triviale formulieren zoals de plek hieronder waarin u het hartgrondig met mij oneens gaat zijn.

In het boetebesluit kan de AP het nog simpeler houden: het gaat hier om persoonsgegevens in de zorg, daarbij is NEN 7510-2 leidend en daaruit volgt het gebruik van TLS. Punt, klaar, next. En dan gaat het om zeer gevoelige gegevens, ook nog eens (vooral) van kinderen en dan mag dat al helemaal niet gebeuren. Normaal kom je dan op een boete van een ton, maar omdat deze orthodontist dat absoluut niet kan betalen wordt deze gematigd naar 12.000 euro.

En dan gooi ik met dit citaat even de knuppel in het hoenderhok:

[Betrokkene] heeft erkend dat de oude website geen gebruik maakte van een versleutelde verbinding. De ontwikkelaar van de oude website heeft haar nooit gewezen op die mogelijkheid. Anders had zij daar zeker gebruik van gemaakt, aldus [betrokkene].

Oftewel, die orthodontist mag de webbouwer op grond van schending zorgplicht aansprakelijk houden voor die 12.000 euro wat mij betreft.

Arnoud

Een abonnee van Xs4all is erin geslaagd om een ssl-certificaat voor Xs4all.nl aan te maken, las ik bij Tweakers. Met behulp van het e-mailadres administrator@xs4all.nl, dat hij als alias voor zijn privéadres aanmaakte, wist de gebruiker bij certificaatautoriteit Comodo een ssl-certificaat voor Xs4all.nl te genereren. Comodo dacht kennelijk dat ze met een administrator van XS4All te maken had. Maar is dat nu legaal, met nepgegevens een certificaat aanmaken?

De wet kent geen specifieke regels over het aanvragen van een SSL-certificaat op andermans naam. De enige regel die volgens mij in de buurt komt, is die van valsheid in geschrifte (art. 225 Strafrecht). Oftewel:

Hij die een geschrift dat bestemd is om tot bewijs van enig feit te dienen, valselijk opmaakt of vervalst, met het oogmerk om het als echt en onvervalst te gebruiken of door anderen te doen gebruiken

Een certificaat kun je zien als een elektronisch geschrift (vergelijk art. 6:227a BW en 156a Rechtsvordering), dus aan dat element is wel voldaan. Het certificaat is bestemd om te bewijzen dat je een verbinding hebt met de website van in dit geval XS4All, en dat kun je “enig feit” noemen.

Het certificaat is weliswaar echt, en dus niet nagemaakt/vervalst, maar het opmaken is gebeurd door misleiding en dat is een vorm van “valselijk opmaken”. Dus ook aan dat element is voldaan.

Alleen bij het oogmerk struikel ik. Althans in dit geval: de gebruiker heeft het certificaat meteen ingetrokken en heeft het nergens werkelijk gebruikt. Dan kun je dus niet spreken van een oogmerk om het als echt en onvervalst te gebruiken of te laten gebruiken.

Zou het geen valsheid in geschrifte zijn, dan kun je een vervalst certificaat alleen aanpakken als het wordt gebruikt om daadwerkelijk illegale zaken te doen. Het is dan een middel voor bijvoorbeeld het aftappen van vertrouwelijke communicatie (een man-in-the-middle aanval) of computervredebreuk (valse authenticatie). Ook phishing door een valse webwinkel op te zetten met dat certificaat zou natuurlijk strafbaar zijn (oplichting). Maar daarvan is hier geen sprake.

Daarbij komt dat de opzet van deze actie zodanig is dat het voor mij een evidente journalistieke truc is: een misstand aan de kaak stellen door te laten zien dat het echt mis is.

Dus nee, bij deze specifieke stunt weet ik geen reden waarom het niet zou mogen. Maar het betekent natuurlijk niet dat iedereen nu ‘dus’ ook nepcertificaten mag maken, zeker niet als je daar daadwerkelijk diensten mee gaat leveren. Je moet wel een punt hebben om te maken.

Arnoud

Een lezer vroeg me:

Onlangs is de OV-Chipkaart app uitgekomen. Uit analyse blijkt dat de app per request een specifieke signature meestuurt, en zonder die signature komt er geen reactie vanuit de server van Trans Link Systems. De methode waarop de signature gemaakt wordt is te achterhalen met decompileren en daarna eenvoudig na te maken. Het is erg moeilijk te achterhalen door puur naar het verkeer te kijken. Mijn vraag is: als iemand API calls doet op basis van die kennis, is er dan sprake van computervredebreuk?

Als ik het goed begrijp, dan doet die app dus aanroepen op de server van TLS. Om te bewijzen dat de app echt de app is, wordt daarbij een signature/code gemaakt op basis van een sleutel die in de app aanwezig zit. Heb je de sleutel, dan kun je dus de code namaken en je eigen aanroepen als echt presenteren.

Van computervredebreuk is sprake als je binnendringt in andermans computer. Een ov-chipkaart is een computer, en die heb je te leen van TLS. Binnendringen daarin is dus mogelijk. Maar een app op je eigen telefoon, daar kun je niet in binnendringen. De app is geen ‘geautomatiseerd werk’, de telefoon wel maar die is van jezelf.

Binnendringen in de server van TLS is mogelijk en dat kan wel computervredebreuk zijn. Alleen, er moet dan sprake zijn van binnendringen zonder recht, wederrechtelijk dus. Je zegt dan, je mag inloggen met de app maar handmatig/eigen app inloggen mag niet. Ik twijfel of dat werkt. Als ik zeg “hier is de sleutel” en jij maakt een sleutel erbij, dan pleeg je geen huisvredebreuk als je met die extra sleutel binnengaat. Het gaat om de plek waar je mag zijn, niet het middel waarmee je daar komt. Een undocumented feature aanroepen door de API-URL te manipuleren (misschien doet &debug=1 iets leuks?) zou ik wel computervredebreuk noemen.

Auteursrechtelijk is het spannender. Je decompileert en achterhaalt de werking van de app. Als het doel dan is een kloon van de app te maken, dan botst dat met het auteursrecht op de app. Maar ‘kloon’ is een beperkt begrijp. En een nieuwe app die alleen dezelfde API calls doet, zou ik niet snel een ‘kloon’ noemen. De wet hanteert “computerprogramma, dat niet als een nieuw, oorspronkelijk werk kan worden aangemerkt” als criterium. Dus echt pure nabouw, dezelfde functionaliteit en layout.

Je kunt je ook afvragen of je wel de ‘werking’ van de app aan het achterhalen bent. Je wilt in feite alleen het algoritme voor het maken van de code achterhalen, en natuurlijk het element zelf dat daarvoor nodig is. Hoe de rest van de app werkt, is minder van belang.

Arnoud

De 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… Lees verder

Auw. 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… Lees verder

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… Lees verder