Je e-mail optimaal beveiligen

Iedereen heeft wel eens gehoord dat e-mail eigenlijk helemaal geen veilige manier van communiceren is. Maar e-mail wordt nog steeds fanatiek gebruikt en de situatie is niet zo slecht als je denkt: de belangrijkste veiligheidsmaatregelen zijn achteraf aan te brengen.

In het tijdperk dat e-mail voor het eerst opkwam, was het voornamelijk belangrijk om computernetwerken goed te beveiligen tegen nucleaire aanvallen. Sindsdien is de situatie wel aardig veranderd. De bedreigingen zijn op dit moment malware en industriële spionage geworden. Die dreigingen heeft het medium helaas nauwelijks kunnen bijbenen. E-mails worden niet standaard versleuteld of geauthenticeerd en ook de meer geavanceerde cryptografische functies zijn meestal in geen velden of wegen te bekennen.

E-mails zijn op het gebied van transportversleuteling nog goed met de tijd meegegaan. Tegenwoordig is het gebruikelijk om mails alleen versleuteld te verzenden en op te halen, ongeacht of dat via IMAP of POP3 gebeurt. Dat gebeurt door de mailclient die een versleutelde verbinding tot stand brengt (TLS) of door een normaal tot stand gebrachte verbinding te versleutelen (STARTTLS). Vrijwel alle clients en mailservers kunnen wel met beide methodes overweg, je hoeft er alleen maar voor te zorgen dat je e-mailprogramma TLS of STARTTLS gebruikt bij de serverinstellingen. Op die manier valt dan te voorkomen dat de dienstverleners van wifidiensten of andere gasten in een openbare hotspot je berichten kunnen lezen.

Het wordt lastig als het gaat om het sturen van e-mails. TLS en STARTTLS worden ook hier veel gebruikt, maar de op die manier gestarte versleuteling reikt natuurlijk niet verder dan je eigen mailprovider. Van daaruit moet de e-mail verder naar de provider van de geadresseerde, en die overdacht kan onversleuteld zijn, want het is afhankelijk van of de betrokken mailservers aangeven dat zij versleuteling ondersteunen. Aanvallers die zich tussen zender en ontvanger wurmen (Man-in-the-Middle, MITM) kunnen die informatie zelfs manipuleren en zo een onversleutelde verbinding afdwingen, zelfs als TLS beschikbaar is.

Als eindgebruiker valt daar niet veel aan te doen. Er zijn opties om dergelijke aanvallen te voorkomen (bijvoorbeeld via DANE of de MTA-STS-standaard), maar die worden nog niet universeel ondersteund. Uiteindelijk hangt het van de betrokken e-mailproviders af of encryptie tijdens het transport gebruikt wordt om e-mail te beveiligen. Sommige mailproviders (bijvoorbeeld mailbox.org) bieden de mogelijkheid om helemaal geen e-mails te verzenden als zij geen transportversleuteling tot stand kunnen brengen. Die optie (als je provider die biedt) zit in de webmail of je accountbeheer.

Maar zelfs met end-to-end-transportencryptie worden e-mails geen absoluut veilig medium. Enerzijds kunnen alle betrokken mailproviders de berichten nog steeds lezen. De encryptie bestaat alleen tussen hen om afluisteraars onderweg op de lijn te voorkomen. De provider-systemen zien de e-mails in platte tekst. Als het om interne bedrijfsmails gaat en de eigen mailserver de enige betrokken provider is, dan kan die situatie aanvaardbaar zijn – maar erg wenselijk is het niet. Misschien verlaten de mails de bedrijfsserver op een bepaald moment, bijvoorbeeld als het bedrijf besluit een back-up in de cloud te parkeren.

Zo is er ook nog het punt van helemaal geen authenticatie, zelfs niet bij tijdens transport versleutelde mails: een mail van [email protected] hoeft in geen geval echt afkomstig te zijn van het account van die directeur en de servers voor het domein example.com – een van de redenen waarom spam zo wijdverbreid is. Met SPF, DKIM, en DMARC zijn er weer verschillende opties beschikbaar die de situatie verbeteren. Zij worden echter (net als DANE en MTA-STS) slechts langzaam populair en zijn niet iets waar je als eindgebruiker de controle over hebt.

De problemen zijn aan te pakken door end-to-end-encryptie (E2EE) te gebruiken. Dan kan niemand onderweg meelezen, zelfs de mailprovider niet. Met de gangbare E2EE-methoden kunnen berichten ook worden geauthenticeerd door ze door de afzender digitaal te laten ondertekenen. Twee varianten van E2EE zijn momenteel gangbaar in de e-mailwereld: S/MIME en OpenPGP. Maar echt veel gebruikt worden die opties helaas niet.

Net als e-mail zelf zijn S/MIME en (Open)PGP vrij oud en hebben ze te maken met ouderdomsverschijnselen. Sommige ontwerpbeslissingen zouden tegenwoordig niet meer worden genomen en meer geavanceerde functies zoals Perfect Forward Secrecy of post-compromise security zijn daarmee niet te realiseren. Maar dat mag je er niet van weerhouden S/MIME of OpenPGP te gebruiken. Die systemen gebruiken is altijd nog beter dan e-mails zonder E2EE.

S/MIME wordt voornamelijk gebruikt in zakelijke omgevingen. Om het te gebruiken heb je een betaald certificaat nodig. De meeste e-mailclients ondersteunen S/MIME out-of-the-box. PGP is gratis en wordt meer ingezet in de privésfeer. Sommige clients hebben dat ook ingebouwd, en er zijn plug-ins voor diverse clients (waaronder Outlook). Met Mailvelope is er zelfs een browser-add-on die OpenPGP geschikt maakt voor webmailers. Die wordt ondersteund door populaire mailproviders zoals Gmail, Outlook. com en Mailbox.org.

Van OpenPGP wordt gezegd (helaas om goede redenen) dat het ingewikkeld en omslachtig is in het gebruik. De verschillende implementaties proberen die complexiteit op diverse manieren te verbergen of toegankelijk te maken. Met de Thunderbird-mailclient wordt het e-mail beveiligen een stuk eenvoudiger. Daar zit OpenPGP sinds versie 78 al ingebouwd. Gebruikers van de al langere tijd beschikbare plug-in Enigmail zijn nogal kritisch over de nieuwe implementatie, maar vooral voor PGP-newbees is de mailclient een goede keuze. Je krijgt alles wat je nodig hebt uit één bron, je kunt niet te veel fout doen, en in geval van problemen heb je de kennis van de grote community om op terug te vallen. Een inleiding tot de PGP-functies van Thunderbird hebben we besproken in c’t 1-2/2021, p.134.

Je hoeft niet volledig op Thunderbird over te stappen alleen omdat je af en toe mails wilt versleutelen (en niet overweg kunt met de PGP-ondersteuning van je eigen client). E-mail is gebaseerd op open standaarden en niets weerhoudt je ervan om twee of meer clients parallel te gebruiken als je IMAP gebruikt. Zelfs propriëtaire systemen zoals Exchange van Microsoft bieden IMAP- en SMTP-interfaces waarmee Thunderbird er als tweede client naast kan worden gebruikt.

Geen enkele client kan echter sommige van OpenPGP’s problemen, zoals sleutelbeheer, verhullen. Je moet je privé-PGP-sleutel goed bewaken: als die in verkeerde handen valt, kan iedereen e-mails namens jou ondertekenen en huidige en eerdere communicatie ontcijferen. Bescherm je sleutel daarom met een degelijk wachtwoord (Thunderbird regelt dat via het hoofdwachtwoord) en laat niet zomaar iedereen toegang krijgen tot je mailclient.

Je moet ook de private-key beschermen tegen verlies om oude berichten te kunnen lezen. Dat is ook belangrijk voor berichten die moeten worden gearchiveerd. Het is het beste om de private-key te exporteren naar een veilige back-up. Je openbare PGP-key moet aan de andere kant juist worden uitgedeeld alsof het snoep is zodat mensen versleuteld en wel contact met je kunnen opnemen. In het ideale geval kan niemand vervalste sleutels in je naam publiceren en zo je digitale gesprekspartners misleiden. Het concept dat OpenPGP voor dat doel biedt, Web-of-Trust genaamd, vertoont echter ernstige gebreken. Een gebruikelijke noodoplossing is de server keys.openpgp.org. Voor sleutels die daar worden gepubliceerd, wordt er echter alleen op toegezien dat het e-mailadres correct is. Sommige clients (waaronder Thunderbird) kunnen rechtstreeks zoeken via keys.openpgp. org als er lokaal geen matchende sleutel beschikbaar is.

Er zijn projecten zoals Pretty Easy Privacy (pEp), Autocrypt of Web Key Directories (WKD) die de OpenPGP- versleuteling en vooral het problematische sleutelbeheer verder willen vereenvoudigen. Op dit ogenblik is de ondersteuning in clients echter zo beperkt dat zij niet algemeen kunnen worden gebruikt. Thunderbird ondersteunt in ieder geval WKD en delen van de Autocrypt-specificatie.

Een ander probleem van e-mail beveiligen kan ook niet door de E2EE-oplossingen worden opgelost: er wordt een massa aan metadata bij gebruikt. Absurd genoeg is zelfs het onderwerp van een e-mail technisch gezien metadata en wordt het daarom meestal niet versleuteld. Dat is gelukkig langzaam aan het veranderen. Mailclients als Thunderbird versleutelen ook het onderwerp. Dat betekent echter dat clients die OpenPGP ondersteunen maar niet het versleutelen van het onderwerp altijd ‘…’ als onderwerp zullen weergeven.

Echte metadata, zoals de geadresseerden en verzend- of ontvangsttijdstippen, kunnen niet worden versleuteld voor e-mails aangezien die vereist zijn voor de aflevering of tijdens het proces gegenereerd worden. Om dat te veranderen zou een nieuw protocol moeten worden ingevoerd, waar normale e-mailclients en -servers niet compatibel mee zouden zijn. Dus zelfs met E2EE weten alle betrokken mailservers wie met wie communiceert en wanneer (en met de gangbare end-to-end transportversleuteling ook alleen die). Niet alles kan achteraf worden ingepast in een 50 jaar oud protocol. Als je meer wilt, of gewoon zo weinig mogelijk met encryptie te maken wilt hebben, moet je voor je communicatie overschakelen op messengers.

(Dit artikel is verschenen in c’t 5/2021, p.62, met medewerking van Sylvester Tremmel en Daniel Dupré)