Mag een spamfilterdienst de beveiliging van e-mail afslopen?

spam-verboden.pngEen lezer vroeg me:

Sommige bedrijven bieden een service om alle uitgaande email transparant te scannen op spam/virussen via een soort SMTP netwerk proxy. Als onderdeel van dat proces schakelen ze de TLS encryptie uit, waardoor alle email plain-text wordt afgeleverd naar het internet. Is dat juridisch wel toegestaan?

Er is geen wettelijke regel die expliciet zegt dat e-mail te allen tijde versleuteld moet worden getransporteerd. Je bent als bedrijf dus vrij om te kiezen of en welke beveiliging je hanteert.

Maar wacht. Per 1 januari krijgen we een aanscherping van de privacywet (Wet bescherming persoonsgegevens), die stelt dat persoonsgegevens te allen tijde “adequaat” moeten zijn beveiligd tegen misbruik en ongeautoriseerde toegang. Die norm bestaat al jaren, de aanscherping komt erop neer dat je in theorie acht ton boete kunt krijgen vanaf januari als je hem schendt.

Wat is nu “adequaat” bij e-mail? Helaas zijn daar geen harde regels voor. Het hangt er namelijk vanaf wat voor gegevens er in die e-mail staan. Gaat het alleen om afzender en ontvanger (relatief weinig gevoelig) of worden er in de bijlage medische dossiers verstuurd (nogal gevoelig)? Dat bepaalt voor een groot deel de vereiste beveiligingsmaatregelen om “adequaat” te mogen heten.

E-mail over SSL/TLS transporteren is een simpele maatregel die eigenlijk altijd wel kan. Dus de factor is dat wel het minimum, net zoals SSL op een bestelformulier van een webwinkel de facto vereist is. Als je dat weglaat, dan heb je dus wat uit te leggen.

De logica achter dit proces begrijp ik niet helemaal. Natuurlijk, je kunt geen mails scannen als ze door een beveiligde verbinding lopen, maar waarom zet je dan niet een beveiligde verbinding op naar de virusscannersite?

Arnoud

9 reacties

  1. Er zijn (ruwweg) twee manieren om het bericht te beveiligen. Allereerst is er de beveiliging van het bericht op zichzelf. Dit kun je bewerkstelligen met een techniek als PGP (Pretty Good Privacy) of S/MIME (Secure/Multipurpose Internet Mail Extensions). Het maakt dan niet uit op welke manier het bericht verstuurd of behandeld wordt, men kan geen inhoudelijke scan uitvoeren zonder de juiste sleutel.

    De tweede beveiliging, waar men het hier over lijkt te hebben, is de beveiliging van de verbindingen. Hier heb je, nadat het bericht het bedrijfsnetwerk heeft verlaten, weinig meer over te zeggen. Het is helaas niet mogelijk om af te dwingen dat een bericht alleen mag worden afgeleverd via beveiligde verbindingen. Dat maakt het voor organisaties ook weer iets eenvoudiger om te zeggen dat men adequate maatregelen heeft getroffen, aangezien je nu eenmaal weinig te zeggen hebt over de routering van je berichten.

    Voor de volledigheid wil ik nog even opmerken dat de gehele wereld de term SSL al wel kent, maar dat TLS (al wordt die hier ook eenmaal genoemd) nog weinig bekend is. Er is op dit moment geen veilige implementatie van SSL meer! Wanneer er beveiliging wordt toegepast op verbindingen dan dient deze plaats te hebben met TLS (waarbij TLS 1.0 ook alweer discutabel is qua veiligheid, dus 1.1+ is aan te bevelen).

      1. In de context van mail-op-het-internet zonder afspraken vooraf gaat het om de STARTTLS extensie van het SMTP-protocol: nadat een (onbeveiligde) verbinding op poort 25 is gemaakt, komen de client en server overeen om een apart, via TLS versleuteld kanaal op te zetten.

        Er is een verouderd protocol om “smtp over SSL” te doen (over poort 465). Dit heeft redelijk brede adoptie gekend, maar uitsluitend “op afspraak” (waarbij beide kanten van tevoren weten dat verkeer over die poort moet) of voor geauthenticeerde verbindingen, zoals de uitgaande mailserver van je eigen ISP.

        Het samenstel van protocollen dat zorgt voor het afleveren van mail aan willekeurige partijen op internet ondersteunt op dit moment alleen STARTTLS over SMTP (poort 25). DANE brengt hier wellicht verandering in maar is nog niet wijd verspreid.

        Als verzendende mailserver kan je wel degelijk besluiten alleen mail af te leveren als er een STARTTLS verbinding kan worden gemaakt, of zelfs de andere kant geauthenticeerd kan worden; zie bijvoorbeeld: http://www.postfix.org/TLSREADME.html#clienttls_policy . Met zo’n beleid heb je wel een oplettende postmaster nodig die zorgt dat uitzonderingen worden gemaakt voor de vele mailservers die STARTTLS nog niet of niet goed ondersteunen.

  2. TLS of SSL, het stelt in het geval van e-mail weinig voor want er wordt meestal niet gecheckt of het certificaat van de partijen wel klopt (want: klopt waarmee?). Dus het is meer tegen ‘per ongeluk terwijl de tekst in transit is meekijken’ dan iets anders. En uiteraard staat de mail staat altijd weer ongecrypt op de mailserver. Wil je dat niet, dan moet je zoals boven al gezegd aan de GPG of de S/MIME.

  3. Dit soort spanfilters zijn in het algemeen bedoeld om spam af te vangen die “direct-to-mx” wordt verstuurd – bijvoorbeeld door malware op breedbandaansluitingen. Voordat (met name) STARTTLS gemeengoed werd op inkomende mailservers, deed men dat door een transparante proxy op poort 25 te zetten, en daar de berichten door een spamfilter te halen. Als de ontvangende zijde STARTTLS toestaat, kan malware dit simpel omzeilen door daar gebruik van te maken.

    Omdat mail ontvangst altijd op poort 25 leeft, kan je wanneer zo’n transparante proxy er staat niet zomaar zelf een veilige verbinding maken.

    Vanaf een breedband-aansluiting je eigen mailserver draaien, en daarmee direct en versleuteld mail afleveren aan de rest van het internet is daarmee lastiger geworden, en daar gaat ’t hier waarschijnlijk om. Een veilige verbinding maken kan dan (via) de mailserver van je ISP, die het weer veilig bij de ontvanger kan afleveren. Of je maakt afspraken met je ISP dat ze dergelijke beveiliging niet toepassen voor jouw verbinding.

  4. “afzender en ontvanger (relatief weinig gevoelig)”

    Arnoud, volgens mij moet jij je nog eens verdiepen in metadata en wat je daar allemaal mee kan. Met enkel metadata en zonder enkele van content, kun je iemands leven volledig en uitermate nauwkeurig beschrijven. En met genoeg van deze metadata kun je zelfs zeer accurate voorspellingen doen over het gedrag en acties van de persoon in kwestie in de toekomst. En vervolgens met gerichte acties dit gedrag bijsturen of veranderen, zonder dat de persoon in kwestie dit door heeft. Dit is precies wat het gedrag van van de NSA, GCHQ en onze ministers van Justitie en Defensie zo eng maakt, maar ook waarom je zo kritisch moet zijn op bedrijven als Google en Facebook. Met genoeg metadata heb je helemaal geen content meer nodig, sterker nog, met genoeg metadata kun je de content zelf invullen.

    Dit soort gegevens zijn niet “relatief weinig gevoelig” maar juist uitermate gevoelig en zouden bovenaan het lijstje met privacy gevoelige informatie behoren te staan.

    1. Over welke metadata heb je het eigenlijk? Het gaat hier om email, wat een vrij oud protocol gebruikt waar ikzelf vrij goed bekend mee ben. Een email bestaat uit twee delen. De header, die je als een soort envelop kunt beschouwen en de body, ofwel de inhoud van de email. De body kan weer uit meerdere onderdelen bestaan, zoals bijlages en het bericht zelf met en zonder opmaak. Hier is de encryptie dus van verdwenen dus iedereen kan dan de inhoud van de email lezen en dat is niet de bedoeling bij encryptie.

      Encryptie is iets dat gebeurt tussen jouw systeem en je email provider. Jij hebt een public key voor je provider waarmee je de encryptie toepast en de provider kan met de private key het bericht weer ontsleutelen. Vervolgens wordt het bericht naar de provider van de ontvanger verstuurt en indien die TSL ondersteunt dan verstuurt de provider de email dus via de encryptie van die andere provider. Zoniet, dan wordt de email als plain-text verstuurd, aangezien de ontvanger geen beveiliging aan heeft staan, maar wel het bericht moet ontvangen. (<a href=”https://www.google.com/support/enterprise/static/postini/docs/admin/en/admineecu/ibtlsoverview.html>Volledige uitleg hier.)Encryptie is dus lang niet altijd even effectief!

      Waar het om gaat zijn drie verbindingen: 1) Van afzender naar provider A. 2) Van provider A naar provider B. 3) Van provider B naar ontvanger b. Verbinding 1 gaat bij deze spamfilters dus via een SMTP-proxy zonder beveiliging. En zo gaat de email zonder encryptie over alle verbindingen. Maar normaal zou het kunnen dat provider B geen beveiliging ondersteunt en dus zou verbinding 2 ook al onveilig kunnen zijn. Dan is 2/3e deel onbeveiligd. Pas als de ontvanger ook encryptie gebruikt zal deze over alle verbindingen toegepast worden. En dan nog wordt de email bij beide providers gewoon ontsleuteld omdat ze opnieuw versleuteld moeten worden via een andere public key. Dat betekent dat beide providers sowieso een onversleutelde versie van het bericht gewoon kunnen inkijken. Op zich zou het geen moeite moeten zijn voor deze spamfilters om TSL te ondersteunen maar de technische kennis om dit goed in te bouwen ontbreekt vaak en vereist de registratie van een speciaal certificaat. Dat zijn extra studiekosten, ontwikkelkosten en extra onderhoudskosten. En de vraag blijft uiteindelijk hoe nuttig deze encryptie uiteindelijk is. Mensen die sowieso beveiligde communicatie willen toepassen doen er beter aan om geen email te gebruiken. Er zijn veiligere alternatieven.

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.