Mag Kliksafe https verkeer openbreken?

kliksafeVia Twitter kreeg ik de vraag:

Kliksafe heeft tegenwoordig een speciaal filter voor HTTPS, waarin ze het verkeer decrypten. In hoeverre is dat toegestaan?

Kliksafe is een aanbieder van gefilterd internet. Wie deze dienst afneemt, kan voorkomen dat er ongewenste websites en diensten opgeroepen kunnen worden. De dienst kent een blacklist, whitelist en contentfilter – dat alle opgevraagde informatie scant die niet van een whitelisted site afkomstig is. (Geblackliste sites kun je natuurlijk niets van opvragen.)

Een handige internetter kan natuurlijk een encrypted verbinding opzetten en zo een dergelijk filter omzeilen. Er valt weinig te contentfilteren als je de content niet kunt lezen. Vandaar dat Kliksafe een https-filter heeft ontwikkeld. Dit filter werkt als een man-in-the-middle: de browser denkt dat hij met de bank of Youtube verbinding maakt, maar in feite gebeurt dat met het filter. Hierbij wordt een sleutel gebruikt die het filter kent, zodat het filter het verkeer kan openmaken. Vervolgens zet het filter een verbinding met bank of Youtube op, waarbij het zich voordoet als de browser. De site heeft dus geen idee dat er iemand tussen zit. Overigens staan banksites op de witte lijst, dus hun verkeer blijft versleuteld.

Het openbreken van dergelijk verkeer is al langer bekend. Bedrijven gebruiken dit nog wel eens om uitgaand werknemersverkeer te kunnen inspecteren op strijd met het bedrijfsbeleid. Of dat mag vraag ik me zeer af. Echter, omdat het decrypten hier gebeurt op speciaal verzoek van de klant zelf, lijkt me er weinig mis mee. Net zoals een slotenmaker best op mijn verzoek mijn voordeur mag openbreken.

Iets dubieuzer wordt het als het gaat om een verzoek van de klant maar niet om zijn eigen verkeer. De internetverbinding kan binnenshuis worden gedeeld, en zo zouden ouders het encrypted internetverkeer van hun kinderen kunnen lezen. Dat voelt ergens toch een tikje gek, net als een slotenmaker inhuren om de afgesloten kast in de kinderkamer open te maken (of een securitybedrijf om een verborgen camera in die kamer op te hangen). Maar dat lijkt me toch vooral een keuze van die klant, en niet iets waar je Kliksafe op kunt aankijken.

Arnoud

11 reacties

  1. Dit filter werkt als een man-in-the-middle: de browser denkt dat hij met de bank of Youtube verbinding maakt, maar in feite gebeurt dat met het filter.

    Dat zie je toch onmiddellijk aan het gebruikte certificaat dat niet van de bank, maar van de MITM is? De verbinding (met het filter/proxy) is dus wel versleuteld, en misschien ook wel vertrouwd (als de filteraar een vertrouwd certificaat aanbiedt), maar niet met de bedoelde wederpartij.

    1. Als ik het goed begrijp, werken dit soort systemen alleen als je Kliksafe in je browser/besturingssysteem toevoegt als certificaat-authoriteit. Dan kan Kliksafe zijn eigen encryptie-sleutel maken, een certificaat maken dat zegt “deze sleutel hoort bij [willekeurige website]”, en het certificaat zodanig ondertekenen dat het door je browser wordt geloofd.

      Ze beloven blijkbaar dat ze dit niet doen bij bepaalde white-listed sites, zoals banken. Ik zou ze zelf niet zomaar op hun woord geloven: ik zou zoiets als de Certificate Patrol plug-in installeren om te controleren dat belangrijke websites NIET een certificaat krijgen dat is ondertekend door Kliksafe. Maar ik behoor ook niet echt tot hun doelgroep, denk ik.

  2. Ik vind het wel interessant om na te denken over welk probleem je nou precies probeert op te lossen door gebruik te maken van zo’n dienst, en of dit wel de beste oplossing is. De mensen die ik ken die vroeger zo’n gefilterd abonnement hadden, hebben tegenwoordig een ongefilterd abonnement.

    Use case 1: ik vertrouw me zelf niet op het internet Ik kan me voorstellen dat je voor je zelfbeheersing de drempel zo hoog mogelijk wilt maken. De drempel om een ander abonnement te nemen of om met ingewikkelde hacks om de filtering heen te werken is vrij hoog.

    Nadeel: je moet dan wel vertrouwen dat die andere partij de filtering goed uitvoert. Gelukkig is dit een private partij, en kan je indien gewenst overstappen op een concurrent als je niet tevreden bent.

    Alternatieve aanpak: je hebt lokaal wat software/hardware die de filtering uitvoert. Nadeel: het is makkelijker (laagdrempeliger) om de software/hardware (tijdelijk) te omzeilen, dus dit is ergens wel een inferieure aanpak.

    Use case 2: ik vertrouw anderen (bijv. mijn kinderen) niet op het internet Probleem: die anderen zouden er wel eens anders over kunnen denken. Dan maakt het verschil laagdrempelig/hoogdrempelig niet meer uit: het gaat dan om mogelijk/onmogelijk, en over het algemeen blijft het altijd mogelijk om filtering te omzeilen. Ik zou het als kind een mooie uitdaging hebben gevonden om zoiets te omzeilen, en nog steeds trouwens: ik heb er bij een bezoek aan China voor gezorgd dat ik daar ongefilterd internet kon krijgen, ik heb hier in Nederland altijd toegang tot de Pirate Bay gehouden, en ik heb middelen om, indien nodig, de internet-filtering op mijn werk te omzeilen.

      1. Dat hoeft niet. Je kunt best een apparaatje installeren tussen je access point en je andere apparaten, dat alle filtering doet. Maar ik had al beredeneerd dat dit voor deze use case een inferieure aanpak is.

        Aan de andere kant: voor use case 2 is het wellicht wel interessant, zolang je de fysieke toegang tot je filter-apparaatje kunt beperken.

  3. De internetverbinding kan binnenshuis worden gedeeld, en zo zouden ouders het encrypted internetverkeer van hun kinderen kunnen lezen.

    Op welke manier zou dat kunnen dan, er van uitgaande dat het zonder Kliksafe niet kan?

  4. Echter, omdat het decrypten hier gebeurt op speciaal verzoek van de klant zelf, lijkt me er weinig mis mee.

    Daar ben ik het niet mee eens. Vaak is het de verzendende partij die de opdracht geeft om https te gebruiken, en veel rekenkracht inzet om er maar voor te zorgen dat klant kan controleren met wie hij praat en dat een man-in-the-middle het verkeer niet kan aanpassen. Soms wordt client-side gecontroleerd of het juiste certificaat gebruikt wordt, om fraude te kunnen ontdekken. Dit gebeurt bijvoorbeeld bij Chrome, die het certificaat van gmail controleert (hierdoor werd de hack bij Diginotar ontdekt). Kliksafe laat nu mogelijk allerlei alarmbellen onnodig afgaan, wat weer manuren kost om uit te zoeken.

    Ik houd mijn hart vast voor de technische implementatie. Met de fouten laatst in iOS, OS X en OpenSSL waardoor MITM aanvallen mogelijk waren, is het moeilijk te geloven dat een kleine ISP een feilloze implementatie heeft. Daarnaast bieden sommige partijen extra veiligheid bovenop ‘gewoon’ TLS (zoals forward secrecy), wat hiermee verloren gaat. Als klant zou je dit verlies in veiligheid niet moeten willen, en gelet op het verschil in kennis tussen een consument en een ISP, zou Kliksafe hiervoor ook moeten waarschuwen.

    Al heeft dit niet zozeer met HTTPS te maken, Kliksafe verliest door het filteren haar status als passief doorgeefluik. Ik vraag me af wat er gebeurt als ze door bv. stichting Brein aansprakelijk worden gesteld. Als er meerdere gebruikers files delen, kan dat aardig in de papieren lopen.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.