Mag een bedrijf met DPI ons netwerkverkeer inspecteren?

Een lezer vroeg me:

Vraag: Ons bedrijf beheert voor klanten grote hoeveelheden gevoelige data, waaronder persoonsgegevens. Nu is recent een nieuwe firewall geïnstalleerd met DPI, die ook ssl-verkeer kan decrypten en inspecteren. Dit zou zijn om datalekken te voorkomen. Maar nu wordt al mijn beveiligde internetverkeer bekeken! Mag dat zomaar?

Vanwege de Wet meldplicht datalekken van januari vorig jaar, en de aankomende Algemene Verordening Gegevensbescherming in mei 2018 zie je steeds meer bedrijven hard aan de weg timmeren ten aanzien van datalekken en informatiebeveiliging.

Inspectie van in- en vooral uitgaand netwerkverkeer is daarbij een relevant aandachtspunt. Immers, een hoop datalekken of security breaches gebeuren per ongeluk: een bestand naar de verkeerde persoon gemaild, een stukje malware dat iets naar buiten wil smokkelen of een gevolg van social engineering. (Om niet te spreken van mensen die willens en wetens data stelen.)

Diverse moderne firewalls zijn in staat om uitgaand SSL-verkeer open te breken. Logisch vanuit een security-gedachte: het is wel erg eenvoudig om de beveiliging te omzeilen anders. Je moet eigenlijk wel even kijken in die beveiligde verbindingen.

Maar het raakt ook allerlei legitiem verkeer van de werknemer in kwestie, zoals privemailtjes (een SSL-verbinding met Gmail of een privé Outlook adres), bankzaken of communicatie met een verzekeraar. En dan wordt het juridisch ingewikkeld, want je moet óók rekening houden met de privacy van je werknemer.

Hier moet de werkgever dus een balans in vinden. Een belangrijke voor mij is daarbij hoe geautomatiseerd dit proces gaat. Wordt er door een automatisch proces gecheckt op een serie keywords of fingerprints van de te beschermen data, dan is dat privacytechnisch héél wat minder ernstig dan een steekproefsgewijze controle door een persoon.

Ook zou belangrijk zijn dat de data niet wordt gelogd (tenzij de automatische scan natuurlijk aangeeft dat er iets mis is) en dat inspectie bij afgaande alarmbellen onder strikte geheimhouding gebeurt. Dergelijke waarborgen moeten in een reglement zijn uitgeschreven, zodat je als werknemer weet waar je aan toe bent. Maar als het zorgvuldig wordt uitgewerkt en ingevoerd, dan denk ik dat het wel kan.

Arnoud

28 reacties

  1. Huh? Ik volg het niet, deep packet inspection is echt iets anders dan het daadwerkelijk decrypten. Met een normale ssl verbinding zal je toch echt de sleutels in handen moeten hebben en daar kan een firewall niet zomaar bijkomen. Meet deep packet analyseer je de data en ik zou me kunnen voorstellen dat je wel iets kan zeggen over het type data maar niet de exacte inhoud. Als dat zo zou zijn dan zou al het ssl verkeer per definitie onveilig zijn.

      1. De firewall stelt zich hier op als man-in-the-middle en zal waarschijnlijk zijn eigen certificaat presenteren aan de gebruiker. Dit certificaat zal per sessie worden gemaakt op basis van de bezochte URL. De Certificate Authority die het certificaat heeft gesigned, zal dan door de werkplek moeten worden vertrouwd middels een certificaat in de certificate store.

        edit: MathFox is me voor, zie ik na klikken op ‘send’.

    1. De truc is dat de firewall/proxy een “man in the middle” attack uitvoert waarbij het verkeer in de firewall ontsleuteld wordt, dan geinspecteerd en daarna weer versleuteld wordt doorgestuurd naar de server. Om te voorkomen dat de webbrowser gaat klagen over onbetrouwbare verbindingen moet de firewall een certificaat voor de website kunnen aanmaken, maar dat is makkelijk als die firewall als “Certificate Authority” is erkend door alle PC’s in het bedrijf.

  2. Diverse moderne firewalls zijn in staat om uitgaand SSL-verkeer open te breken.

    Hoe gaat dat precies in z’n werk? Moet je daarvoor niet eerst een aanpassing doen op het besturingssysteem van de gebruiker?

    1. Alle bedrijfs-pc’s hebben het certificaat van de proxy/firewall in hun Windows-certificaatstore gepusht gekregen, zodat Internet Explorer en Chrome, die hun certificaten daaruit halen, de firewall als betrouwbaar SSL-endpoint zien. Firefox heeft zijn eigen certificaatopslag en geeft daarom een melding over een onbetrouwbaar certificaat als je via de firewall naar “buiten” probeert te gaan.

  3. SSL/TLS is a protocol providing an end-to-end encrypted communication between two parties each having one of the keys in private/public key pair. Typically a browser and a web server.

    In normal circumstances any device between the two endpoints cannot decrypt the communication. That includes firewalls.

    It is however possible (and used in organizations) to use a proxy server that decrypts and re-encrypts communication thus allowing interception and decryption (for example for monitoring and filtering). It does however require adding an additional certificate to a trusted certificate store on a client machine (either automatically through a software management system or manually by users).

    Bron: https://security.stackexchange.com/questions/121749/can-firewalls-decrypt-ssl-packets

    1. En dit verhaal werkt dus niet als er public key pinning word toegepast. Een van de redenen waarom het eigenlijk zeer onwenselijk is dat deze praktijk word toegepast. Er zijn andere manieren om data stromen te beheersen ie het niet vereisen dat je ‘alles’ kunt zien.

      Voor de gevorderde data-lekker is dit overigens geen belemmering. je encrypt gewoon de data voor je m verstuurd. nu kan de Firewall ineens niets meer lezen. ook niet met de TLS MiTM. Het hele DPI is dus 1 hele grote wassen nees en meer’ security theater’ dan echt ‘security practise’.

        1. welke initiële key? HPKP werkt doordat de publieke sleutel van een certificaat word gepinned aan de verbinding (bij websites d.m.v. een header) dit zou betekenen dat de Firewall deze header afvangt, echter als er ook maar 1x verbinding word gemaakt via een andere weg dan is deze header dus wel gezet en weet de browser dat de sleutels niet kloppen en word de pagina dus ook niet geladen. mogenlijk ben je in de war met HTTP Strict Transport Security (HSTS) een techniek om een TLS verbinding te vereisen, dit werkt inderdaad gewoon. HPKP echter is een stuk hardnekkiger en kan dit soort misbruik gewoon voorkomen mits goed toegepast.

          1. Als MITM kan de firewall haar eigen publieke sleutel in de html header schrijven. Je zult een manier moeten hebben om een vertrouwde sleutel buiten de firewall om naar binnen te krijgen.

            Wanneer een bedrijf echt serieus is met haar databeveiliging zal dat niet zo makkelijk zijn. (USB sticks zijn verboden, geen eigen software installeren, etc.) Je zult dan ook als werknemer een cursus databeveiliging gehad hebben waarin wat zaken uitgelegd zijn.

            1. moet jouw firewall dit wel doen (kunnen ze echt nog niet allemaal), moet je site nooit bezocht worden via een andere weg (4G,wifi-hotspot,thuisnetwerk,etc.) en moet de website met HPKP niet op de preload lijst staan (wat weer betekent dat de browser al weet wat de gepinnde key is voor dat jij ooit bij de site bent geweest) en moet er geen pinning in je applicatie zit.

      1. Die encrypte data is dan een vlag en zal dan afhankelijk van de policies in het bedrijf geblokt worden zodat er niet gelekt wordt. Daar waar bedrijfsprocessen dat nodig hebben kan het gewhitelist worden.

  4. Ik heb naar aanleiding van dit verhaal een vraag; de firewall of proxy die een TLS verbinding onderschept moet daarvoor een TLS certificaat op naam van de website waarnaar de verbinding opgezet wordt presenteren. In hoeverre geldt het aanmaken en gebruik maken van zo’n certificaat als valsheid in geschrifte of is het anderszins strafbaar als gebruik maken van valse sleutel, aannemen van een valse identiteit of iets dergelijks?

      1. Voor een bedrijf denk ik dat het wel mag, mits de medewerkers ingelicht zijn. Maar mag een ISP het ook doen zonder haar klanten in te lichten? Mag een bedrijf zoiets stilletjes invoeren?

    1. Dat is wel een interessante insteek. De definitie van valsheid in geschrifte is (art. 225 lid 1 Strafrecht):

      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, wordt als schuldig aan valsheid in geschrift gestraft, met gevangenisstraf van ten hoogste zes jaren of geldboete van de vijfde categorie.

      Een elektronisch geschrift wordt in beginsel gelijkgesteld met een papieren geschrift. Aan dat element is dus voldaan bij het genereren van een certificaat. Het certificaat is een elektronisch geschrift. Doel van het certificaat is de identiteit van de webserver en/of haar aanbieder te bewijzen, dus het geschrift heeft een bewijsfunctie.

      Het zal denk ik neerkomen op de vraag of sprake is van ‘valselijk’ opmaken. Enerzijds: je maakt het certificaat niet met het doel mensen te misleiden, mensen te doen denken dat ze echt veilig met hun bank zaken doen zodat je daar misbruik van kunt maken. Je wilt vanuit een legitiem securitybelang in mensen hun netwerkverkeer kijken. Anderzijds: mensen dénken dat de verbinding veilig is, dat het certificaat echt is.

      Het is vaste jurisprudentie dat artikel 225 van het Wetboek van Strafrecht ziet op geschriften waaraan in het maatschappelijk verkeer betekenis voor het bewijs van enig feit pleegt te worden toegekend. Kun je dat zeggen voor certificaten? Zien wij die als bewijs dat je echt met bedrijf X werkt, of als technisch detail waar niemand ooit echt naar kijkt?

      Of misschien nog algemener: is het niet zo dat iedereen eenvoudig kan zien dat het certificaat nep is? Er staat wel om technische redenen de naam van het eindpunt in (bank X, Google, etc) maar de issuer is anders. Of zou het certificaat zo te maken zijn dat het duidelijker is dat je met een firewall praat in plaats van echt met bank X?

      PS krijg jij een notificatie van deze reactie in de mail?

      1. Of misschien nog algemener: is het niet zo dat iedereen eenvoudig kan zien dat het certificaat nep is? Er staat wel om technische redenen de naam van het eindpunt in (bank X, Google, etc) maar de issuer is anders.

        Ik denk dat je de gemiddelde internetgebruiker te hoog inschat. Mocht die al weten hoe certificaatinformatie op te vragen is in de browser, zal het wezenlijke verschil tussen “192.169.10.3” (vals) en “COMODO LTD” (echt) voor een leek niet duidelijk zijn.

        1. Goed, maar dat ondersteunt de conclusie dat het niet zo is dat “in het maatschappelijk verkeer betekenis voor het bewijs van enig feit pleegt te worden toegekend.” Als niemand naar het certificaat kijkt om te zien met wie hij webcommuniceert, dan heeft het certificaat de facto geen bewijsfunctie. En valsheid in geschrift is alleen strafbaar bij documenten met wél zo’n functie.

          1. Maar we kijken wel naar het certificaat. Of eigenlijk: naar het slotje dat tevoorschijn komt bij een verbinding met een geldig certificaat. En dat zien we niet als bewijs van de identiteit van de tegenpartij, maar van het bestaan van een onafluisterbare verbinding. Daar zijn de certificaten ook niet voor bedoeld. Het certificaat van blog.iusmentis.com zegt bijvoorbeeld helemaal niets over met wíe we hier te maken hebben.

              1. Als ik in mijn pauze een bankoverboeking uitvoer op de website van mijn bank met een slotje, verwacht ik niet dat mijn werkgever plots in het bezit is van mijn wachtwoorden en TAN-codes. Sterker nog, dat zou wezenlijk onveiliger dan bankieren op een onbeveiligd terras-WLAN zijn.

                SSL dient net zo goed ter bestrijding van spionage door partijen die we niet meteen als “de vijand” beschouwen: ISPs, werkgevers, beheerders van internetrouters, etc., die allemaal menen dat zij goede redenen hebben voor DPI.

          2. De banken roepen al jaren “let op het groene slotje” en de gemiddeld ervaren Internetgebruiker weet dat een TLS-certificaat zekerheid biedt dat je op de juiste website uitkomt. (De experts kennen de betrouwbaarheid van de gemiddelde CA en weten van de gaten in website-software en configuratie.)

            In de meeste gevallen laten de gebruikers de controle op het certificaat over aan de browser en dan leidt misleiding van de browser tot misleiding van de gebruiker. Aan de andere kant, als de proxy-functie op de firewall goed is ingesteld, communiceert de browser, ondanks het valse certificaat, wel met de door de gebruiker gezochte website.

      2. Laten we eens alle stappen in het proces van het maken van een normaal certificaat op een rij zetten:

        1. 1. De (beheerder van) de website maakt een private+publiek sleutelpaar aan

        2. 2. De website plaatst publieke sleutel plus identiteitsgegevens in een concept-certificaat

        3. 3. Het concept-certificaat wordt door een “CA” geverifieerd en na acceptatie (cryptografisch) ondertekend

        4. 4. Het ondertekende certificaat en de private sleutel worden op de webserver geplaatst

        5. 5. Bij het opvragen van een webpagina “bewijst” kennis van de private sleutel dat het certificaat bij de website hoort.

        Laten we de vergelijkbare stappen voor de MITM firewall doorlopen en juridisch commentaar leveren:

        1. 1. Er wordt een sleutelpaar aangemaakt: Dat mag iedereen doen.
        2. 1a. De beheerder van de firewall creëert een CA en laat alle browsers binnen de organisatie deze CA vertrouwen. Niet netjes, een onderdeel van het netwerk van verdichtsels.

        3. 2. Er worden bewust onjuiste identiteitsgegevens in het concept-certificaat geplaatst: Riekt naar valsheid in geschrifte.

        4. 3. De firewall neemt de hoedanigheid van de in 1a gecreëerde CA aan en ondertekent het certificaat: Opmaken van een valse akte?

        5. 4. De sleutel en certificaten staan al op de firewall, maar zijn een essentieel deel van het schimmenspel.

        6. 5. Bij het opvragen van een webpagina neemt de firewall, met behulp van het valse certificaat, de identiteit van de webserver aan. Daarmee worden de webbrowser en haar gebruiker misleid (mits de door de firewall gebruikte CA door de webbrowser erkend wordt.)

        Ik denk dat uiteindelijk de intentie “met het oogmerk om het als echt en onvervalst te gebruiken” de doorslag zal geven. De misleiding van de webbrowser is vrijwel perfect; de gebruiker moet (een paar clicks) moeite doen om te bepalen welke CA ondertekend heeft. Naar mijn mening zal een organisatie die deze techniek wil toepassen daar zeer gegronde redenen voor moeten hebben en naar haar werknemers open moeten zijn over het gebruik van deze methode. Als werknemers het gebruik van valse certificaten niet beseffen, dan kan een rechter besluiten dat aan het strafrechtelijke oogmerk-criterium voldaan is.

        P. S. ik zag niets in mijn mailbox, maar notificaties staan uit.

  5. Mijn werkgever doet dit ook. Heb zelf het bedrijfseigen certificaat in Firefox geïnstalleerd (omdat dat mijn favoriete browser is, en ik als ITer gelukkig wel kan installeren), en krijg als ik op het groene slotje klik op deze site te zien: “blog.iusmentis.com secure connection verified by “. Kijk je op naar de certificaatdetails, dan staat er “issued by” met een intern IP adres. Lijkt me dus zeer zeker geen geval van valsheid in geschrifte: als je even de moeite neemt hiernaar te kijken is duidelijk wat er hier gebeurt.

    1. Valsheid in geschrifte vereist niet dat het geschrift gelijk is aan een origineel geschrift, alleen de bedoeling om het als “echt” te laten herkennen is genoeg. Het lijkt me niet dat de expert hier de meetlat is maar een representatieve gebruiker. Het correct informeren van het personeel is daarbij belangrijk ook vanuit de wet bescherming van persoonsgegevens en goed werkgeverschap.

      Aan de andere kant lijkt valsheid in geschrifte niet bedoeld voor dit soort zaken (maar geschreven toen dpi nog niet bestond).

  6. een gevalletje “je hebt de melk wel horen klotsen maar je weet niet waar de tepel hangt”. DPI is noodzakelijk, juist om kritieke gegevens te beschermen, zonder deze techniek zouden encrypted files zonder pardon met kwalijke lading in en uit het network kunnen komen. DPI zorgt voor extra veiligheid, en omdat er alleen gekeken wordt naar de structuur en niets gedaan wordt met de werkelijke inhoud ( lees : bv je NAW gegevens) raakt dit kant noch wal vwb WBP.

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.