Versleuteld e-mailverkeer vaak toch niet veilig

Het uitwisselen van informatie is tegenwoordig net zo gewoon als water uit de kraan. Veel organisaties richten hier separate voorzieningen voor in, of besteden dit zelfs uit aan een externe partij. Wanneer de uitwisseling beperkt van omvang en incidenteel van aard is, maken organisaties echter nog steeds graag gebruik van het oude vertrouwde e-mail. Deze voorziening is vaak al aanwezig, waardoor het gebruik ervan goedkoop en bovendien snel geregeld is. Maar ook bij uitwisseling via e-mail is het belangrijk om de beveiliging goed te regelen. Helaas gaat dit niet altijd goed, en zie ik nog regelmatig dat er ten onrechte wordt vertrouwd op maatregelen die niet de benodigde zekerheid bieden.

De beste manier om de vertrouwelijkheid en integriteit van een e-mail te garanderen, is het gebruik van encryptie voor het e-mailbericht zelf. Bijvoorbeeld met behulp van PGP of S/MIME. Beide maken gebruik van public key cryptografie, maar waar je bij PGP zelf verantwoordelijk bent voor het uitwisselen van de publieke sleutel, maakt S/MIME hiervoor (net zoals SSL certificaten) gebruik van een PKI infrastructuur. In het geval van S/MIME vertrouw je dus wat meer op externe partijen, wat voor sommigen principieel bezwaarlijk is.

De kracht van dergelijke oplossingen is gelegen in het feit dat er sprake is van end-to-end encryptie op de berichtinhoud. Aangenomen dat er geen kwetsbaarheden zitten in (de implementatie van) het gebruikte algoritme voor versleuteling, ben je voor de vertrouwelijkheid en integriteit nauwelijks afhankelijk van de (configuratie van de) e-mailserver. Toch is deze oplossing vaak niet populair, wat veelal te maken heeft met de verhoogde complexiteit voor gebruikers en/of beheerders. Met name in grotere omgevingen vormt dit een drempel. Er wordt dan vaak gezocht naar een alternatief dat voor beheerders behapbaar is, en voor gebruikers geen verandering in werkwijze/gedrag tot gevolg heeft.

Een populair alternatief is het toepassen van een versleutelde TLS verbinding (SSL is verouderd en het gebruik ervan wordt afgeraden) tussen de e-mailservers die de berichten met elkaar uitwisselen. Op zichzelf is dat natuurlijk een prima idee, maar er liggen een aantal risico’s op de loer waar mensen zich vaak niet van bewust zijn. Om deze risico’s te begrijpen, ga ik eerst wat verder in op de wijze waarop mailservers omgaan met TLS verbindingen.

Mailservers en TLS

TLS biedt de mogelijkheid om aan weerszijden een authenticiteitscontrole uit te voeren op het aangeboden certificaat. Wanneer is vastgesteld dat beide certificaten valide zijn, wordt er een verbinding tot stand gebracht. De meeste mensen kennen dit mechanisme uit de browser; wanneer je een website bezoekt waarvan het certificaat niet klopt, dan resulteert dat in het onderbreken van de verbindingsopbouw en een foutmelding aan de gebruiker. De standaard wijze waarop mailservers bij het gebruik van SMTPS omgaan met TLS certificaten, wijkt waarschijnlijk af van hetgeen je zou verwachten.

Allereerst ondersteunen niet alle mailservers het gebruik van een TLS verbinding. Om te borgen dat e-mailverkeer altijd mogelijk is, wordt het verplichten van SMTP over TLS voor publieke mailservers in RFC 2487 afgeraden. Mailservers lossen dit op door het gebruik van oppertunistic TLS, waarbij er in eerste instantie wel wordt geprobeerd een TLS verbinding op te zetten, maar er wordt terug gevallen op een onversleutelde verbinding wanneer dit niet lukt. Bij de bekende open source mailserver Postfix wordt dit ingesteld door de configuratievariabele “smtp_tls_security_level” in te stellen op “may”. Voor mailservers in gesloten (niet-internet) omgevingen, kunnen hogere security levels worden gebruikt voor meer zekerheid.

Mailservers die TLS wel ondersteunen, zijn standaard vaak niet ingesteld om de gebruikte TLS certificaten te verifiëren. Dergelijke mailservers accepteren dus elke willekeurig TLS certificaat zoals verlopen of self-signed certificaten voor het opzetten van een verbinding, en zijn daarmee vatbaar voor man-in-the-middle aanvallen. Ik kan nergens overduidelijk vinden dat inderdaad ooit is afgesproken dat een goede certificaatverificatie niet noodzakelijk is, maar in RFC 2487 zie ik wel het volgende staan:

Both the STMP client and server must check the result of the TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security.  The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependant, and is beyond the scope of this document.

A publicly-referenced  SMTP server would probably want to accept any certificate from an SMTP client, and would possibly want to put distinguishing information about the certificate in the Received header of messages that were relayed or submitted from the client.

Ik vermoed dat dit vanwege praktische redenen heeft geleid tot een soort de facto standaard om alle certificaten te accepteren. Het scheelt namelijk enorm in de beheerlast wanneer de certificaatverificatie niet heel strak is ingeregeld. Daarnaast was het beveiligingsbewustzijn 15 tot 20 jaar geleden een fractie van wat het tegenwoordig is, en betrof het bovendien server-to-server verkeer waar eindgebruikers beperkt zicht op hadden. Deels is dit dus een erfenis uit het verleden, waar vanwege de hoge penetratiegraad niet zomaar overheen kan worden gestapt.

Het goede nieuws is dat mailservers vaak (niet altijd) de mogelijkheid bieden om authenticiteitscontroles voor certificaten aan te zetten. In Postfix kan dat bijvoorbeeld met de configuratievariabele “smtp_tls_policy_maps“. Het gewenste effect kan ook worden bereikt met de eerder genoemde configuratievariabele “smtp_tls_security_level”, maar het voordeel van “smtp_tls_policy_maps” is dat per domein kan worden aangegeven welke controles uitgevoerd dienen te worden. Het is zelfs mogelijk om zelf een lijst met vertrouwde certificaten te beheren, zodat je ook niet meer afhankelijk bent van een certificaatautoriteit.

Restrisico

Maar zelfs wanneer het gebruik van TLS tussen de e-mailserver van twee domeinen goed is ingeregeld en de out-of-the-box schijnveiligheid is geëlimineerd door het toepassen van wederzijdse authenticatie, zijn er nog steeds risico’s. Hieronder een aantal voorbeelden:

• Typefouten in e-mailadressen (bijvoorbeeld naam@domein.com in plaats van naam@domein.nl) vormen ondanks het toepassen van een versleutelde verbinding nog steeds een risico. Hierdoor kunnen vertrouwelijke gegevens bij de verkeerde personen terecht komen. Het gebruik van PGP of S/MIME verhelpt dit probleem: het gebruik van de publieke sleutel van de ontvanger, voorkomt dat foutieve ontvangers het bericht kunnen lezen (zij bezitten immers niet de privésleutel die nodig is om het bericht te ontsleutelen).
• Er is geen e-mailverkeer mogelijk wanneer een van de partijen overschakelt op de secundaire e-mailserver, terwijl deze niet als vertrouwd staat aangemerkt door de andere partij. Partijen dienen elkaar proactief te informeren over wijzigingen in de e-mailomgeving, zodat de uitwisseling van e-mailberichten kan worden gegarandeerd.
• Het betreft geen end-to-end encryptie, dus mogelijk zitten er elders in het (interne) netwerk nog ongewenste risico’s. Denk bijvoorbeeld aan onversleuteld verkeer tussen de werkplek van de gebruiker en de e-mailserver.

Conclusie

Als je e-mail wil gebruiken voor een betrouwbare gegevensuitwisseling, dan is het gebruik van end-to-end encryptie op basis van PGP of S/MIME de beste keuze. Wanneer dit om wat voor reden dan ook geen optie is, kun je besluiten om de bovengenoemde restrisico’s te accepteren en het berichtenverkeer tussen de desbetreffende e-mailservers te versleutelen met TLS (SMTPS). Zorg er dan wel voor dat de mailservers zodanig zijn geconfigureerd, dat deze beide de noodzakelijke authenticiteitscontroles uitvoeren voordat de TLS verbinding definitief tot stand wordt gebracht. Standaard (out-of-the-box) is dit vaak niet het geval, waardoor het e-mailverkeer tussen de servers kwetsbaar is voor man-in-the-middle aanvallen. Reken af met deze schijnveiligheid en maak het hackers niet te makkelijk!

Afbeelding van IT Security Guru.