E-mail, SMTP, TLS & S/MIME

E-mail, SMTP, TLS & S/MIME

Inhoudsopgave Inhoudsopgave... 2 1. Inleiding... 3 1.1. E-mail via het internet... 3 2. E-mail transport... 4 2.1. Kwetsbaarheden van het e-mail transport via het internet... 5 2.2. Eisen aan het transport van e-mail... 6 3. SMTP/TLS - Transport Layer Security... 7 3.1. TLS en de vier kwetsbaarheden van SMTP... 8 4. S/MIME - Secure MIME... 9 4.1. Client based S/MIME... 9 4.2. Server based S/MIME... 9 4.3. S/MIME en de vier kwetsbaarheden van SMTP... 10 E-mail, SMTP, TLS & S/MIME versie 1 H.E. van der Pols esecor BV, Blaricum, april 2014 Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microfilm of op welke wijze dan ook, zonder voorafgaande schriftelijke toestemming van esecor BV.

1. Inleiding E-mail, zowel intern als extern, is een breed geaccepteerd hulpmiddel voor communicatie tussen individuen en tussen organisaties. Wat ongeveer twintig jaar geleden voor veel organisaties beschikbaar kwam als een nice-to-have functionaliteit is, vooral sinds de opkomst van het internet en de daarmee gepaard gaande mogelijkheid om gegevens uit te wisselen, uitgegroeid tot een essentieel stuk bedrijfsgereedschap. Nu e-mail in veel gevallen zelfs het primaire communicatiemiddel is geworden zijn ook de eisen aan de omgang met en ondersteuning van e mail veranderd. Dit document gaat in op de bescherming van de informatie opgenomen in e-mail tijdens het uitwisselen van deze berichten tussen organisaties. Basiseis voor deze uitwisseling is het beschikbaar hebben van een netwerkverbinding waarover deze e-mail communicatie plaats kan vinden. Er zijn diverse methoden om een dergelijke netwerkverbinding te realiseren, maar de voor e-mail meest gebruikte connectie is verzenden van e-mail via het Internet. Alternatieve mogelijkheden zijn bijvoorbeeld een VPN verbinding of zelfs een leased line waarmee de netwerkinfrastructuren van organisaties onderling gekoppeld kunnen worden. Deze alternatieven vallen echter buiten het bereik van dit document. 1.1. E-mail via het internet Voor het uitwisselen van e-mail via het internet wordt gebruik gemaakt van het standaard protocol SMTP (Simpel Mail Transport Protocol), een 30 jaar oud protocol dat oorspronkelijk is ontwikkeld voor het uitwisselen van tekstbestanden tussen computers. Een SMTP bericht is feitelijk niets anders dan een tekstbestand met een geformatteerd begin met daarin de basisgegevens nodig voor het transport van dit bericht. Minimaal zijn dit de afzender en de beoogde ontvanger. Dit alom gebruikte SMTP protocol heeft geen voorzieningen waarmee de integriteit en authenticiteit van SMTP e-mailberichten gewaarborgd kunnen worden. In hoofdstuk 2 wordt ingegaan op het transport van e-mail en de beperkingen van SMTP. In hoofdstukken 3 en 4 wordt ingegaan op de mogelijkheden die TLS en S/MIME bieden om risico s van SMTP e-mail te beperken.

2. E-mail transport Hoewel er significante verschillen zijn tussen de voor e-mailtransport beschikbare protocollen werkt een e-mail systeem volgens het principe van store-and-forward. Dit kan eenvoudig geïllustreerd worden met onderstaand schema. Figuur 1 store-and-forward e-mail transport Als Alice (alice@a.nl) een mail stuurt naar Bob (bob@b.nl) worden de volgende acties ondernomen: 1. De mail client van Alice levert het bericht af op de mail server van Alice (mail spoke). 2. De mail spoke stuurt de kopie voor Bob door naar de mail hub van organisatie A. 3. De mail hub stuurt de kopie voor Bob door naar de mail relay van organisatie A. 4. De mail relay doet een DNS lookup om het adres op te halen van de mail relay van domein b.nl 1. 5. De mail relay van A stuurt het bericht naar de mail relay van B 2. Hierbij wordt gebruik gemaakt van het SMTP protocol. 6. De mail relay van B stuurt het bericht door naar de mail hub van B. 7. De mail hub van B stuurt het bericht door naar de mail server (mail spoke) van Bob. Met uitzondering van stap 5 gaat het routeren van e-mail op basis van vaste gegevens die gecontroleerd worden door organisatie A resp. B. De stap tussen beide organisaties (stap 5) wordt echter gezet op basis van informatie in de Internet DNS (stap 4). Hierbij wordt meestal een DNS server geraadpleegd die een tijdelijke kopie van de adresgegevens van de ontvangende partij bevat (een z.g. caching name server). 1 Het adres waarop mail voor een domein afgeleverd moet worden staat vermeld in een of meerdere MX records. Indien de DNS meerdere MX records en dus meerdere adressen bevat wordt het adres met de laagste prioriteit gekozen. 2 De mail relay van domein b.nl kan een door B beheerd systeem zijn, bijvoorbeeld als onderdeel van de Firewall van B. Het kan ook een fall-back server zijn of een systeem van een derde partij die diensten levert aan B. De afzender heeft hier geen invloed op.

2.1. Kwetsbaarheden van het e-mail transport via het internet Zoals in de inleiding is aangegeven is het SMTP protocol oud en gericht op het uitwisselen van tekstbestanden. Binaire informatie wordt daarom eerst gecodeerd voordat het via SMTP verstuurd kan worden. Voor deze codering zijn een aantal standaard methoden beschikbaar zoals UUEncode/UUDecode. Dit zijn allemaal symmetrische systemen waarbij gebruik gemaakt wordt van een vaste, publiekelijk bekende, sleutel. Deze codering is daarom geen afscherming. De standaard voor het coderen van de inhoud van een SMTP bericht is MIME 3. Het eenvoudige en tekst georiënteerde karakter van SMTP maakt het gevoelig voor een lange reeks kwetsbaarheden. De belangrijkste daarvan zijn: 1. Falsificeren van de afzender (originator spoofing) Alle informatie in een SMTP bericht is tekst, ook de gegevens gebruikt voor de adressering van het bericht. Spam is het levende bewijs dat het afzenderadres van een SMTP bericht niet vertrouwd kan worden. 2. Herleiden van een bericht (man in the middle) Bij het versturen van berichten tussen organisaties wordt de adressering gebaseerd op gegevens in een DNS server. Het probleem hierbij is dat deze informatie eenvoudig veranderd kan worden waardoor het bericht omgeleid wordt langs een vijandige server. Dit is voor de ontvanger van het bericht niet te ontdekken. Figuur 2 "Man in the Middle" 3. Het veranderen van informatie in de DNS database staat inmiddels bekend onder de naam DNS Cache Poisoning. Recente onderzoeken geven aan dat tussen de 30% tot 40% van de Nederlandse recursive name servers of cache servers nog steeds kwetsbaar zijn voor dit inmiddels ruim bekende probleem. Zie ook FACTSHEET FS- 2008-06: De Kaminsky Code : Kwetsbaarheden in DNS - GOVCERT.NL 25/7/2008 4 4. Veranderen van de inhoud van een bericht (tampering) Het volledig ontbreken van elke controle op de inhoud van een SMTP bericht maakt het mogelijk om de inhoud van een bericht tijdens het transport aan te passen zonder dat dit door de ontvanger ontdekt kan worden. 3 MIME: Multipurpose Internet Mail Extensions, beschreven in diverse RFC s, beschrijft de formaten waarin complexe informatie opgenomen kan worden in een SMTP bericht. 4 http://www.govcert.nl/download.html?f=118.

5. Afluisteren (eavesdropping) Alle informatie vervat in een SMTP bericht dat tijdens het transport onderschept wordt is voor iedereen beschikbaar. Het sturen van een SMTP bericht wordt daarom veelvuldig vergeleken met het sturen van een briefkaart waarop de informatie van buitenaf leesbaar is. Hoewel van alle kwetsbaarheden de eerste twee veruit de belangrijkste zijn dient een goede beveiliging van de e-mail correspondentie minimaal deze vier kwetsbaarheden te blokkeren. 2.2. Eisen aan het transport van e-mail Om e-mail te behouden als belangrijk bedrijfshulpmiddel dient de informatie in het emailsysteem als geheel en speciaal de informatie vervat in e-mailberichten betrouwbaar te zijn. Bij het versturen van een e-mail moet een gebruiker ervan uit kunnen gaan dat het bericht wordt afgeleverd bij de geadresseerde(n) en niet bij derden. Verder moet een ontvanger van een bericht kunnen controleren dat het bericht inderdaad afkomstig is van de genoemde afzender. Bij het versturen van gevoelige of vertrouwelijke informatie moeten zowel de afzender als de ontvanger(s) van een bericht er vanuit kunnen gaan dat de informatie niet beschikbaar is voor derden. Dit impliceert dat een veilig e-mailsysteem alle vier eerder genoemde kwetsbaarheden moet elimineren of minimaal moet zorgen dat de kwetsbaarheid geen bedreiging vormt voor de authenticiteit en integriteit van de informatie vervat in e-mail.

3. SMTP/TLS - Transport Layer Security SMTP/TLS is de versleutelde variant van SMTP, vergelijkbaar met S/HTTP of HTTPS als de versleutelde variant van het HTTP protocol. SMTP/TLS staat beschreven in RFC 2487 SMTP Service Extension for Secure SMTP over TLS 5. Een SMTP/TLS sessie wordt geïnitieerd door de SMTP client die een voorkeur voor TLS kenbaar kan maken m.b.v. van het STARTTLS commando. De SMTP client is hier de zendende MTA 6, in figuur 1 is dat de Mail relay van organisatie A. Volgens de SMTP standaard mag een aan internet gekoppelde SMTP server geen TLS sessie afdwingen. Het behoort dus tot de verantwoordelijkheid van de zendende partij om te controleren of een SMTP sessie daadwerkelijk beveiligd wordt m.b.v. TLS. De zendende partij (SMTP client) kan controleren of het certificaat dat door de ontvangende partij (SMTP server) gebruikt wordt voldoet aan de verwachting. Er kan bijvoorbeeld gecontroleerd worden of het domein in het certificaat gelijk is aan het domainpart in het adres van de beoogde ontvanger. Probleem hierbij is dat dit vaak niet overeenkomt. Organisaties kunnen mail voor meerdere domeinen ontvangen op de zelfde server(s). Denk bijvoorbeeld aan een internationale organisatie die als domainpart een land sub-domein gebruikt zoals nl.bank.com, terwijl de SMTP relay servers als hostnaam bank.nl hanteren. Dit is een volledig legale configuratie waarbij de SMTP client geen validatie op host/certifcaat kan doen. Bij organsiaties die gebruik maken van de diensten van een PSP (Perimeter Service Provider) als Symantec s MessageLabs of Google s Postini wordt de mail afgeleverd op SMTP servers van de dienstverlener. Ook hierbij is de controle in de praktijk niet uitvoerbaar. Het aantal van dit soort uitzonderingen is zo groot dat de daadwerkelijke implementaties van TLS vaak geen gebruik maken van de optie om de ontvangende MTA te valideren. Hierdoor wordt de meerwaarde van TLS boven een normale SMTP sessie drastisch verminderd. Verder wordt met SMTP/TLS alleen een individuele SMTP sessie afgeschermd, in figuur 1 is dat stap 5. SMTP/TLS routeert berichten nog steeds op grond van informatie verkregen uit de Internet DNS. Indien deze DNS-gegevens veranderd zijn wordt de SMTP/TLS sessie gestart met de server-in-the-middle. Gezien de losse implementatie van SMTP/TLS zal het bericht gewoon aan de server-in-the-middle afgeleverd worden alwaar alle gelegenheid bestaat om het bericht te kopiëren dan wel aan te passen alvoor het naar de eigenlijke bestemming wordt doorgezonden. Een bericht dat tijdelijk op een legale tussen server opgeslagen wordt staat daar als leesbare tekst. De bescherming van de informatie in het e-mailbericht is hier volledig afhankelijk van de bescherming van deze tijdelijke opslag server. Het probleem hierbij is dat deze server door een derde partij beheerd wordt. Zowel de zendende als ontvangende organisatie heeft geen controle over het beheer van deze server noch de kwaliteit van de beveiliging daarvan. Dit mag acceptabel zijn indien dit een server van een PSP of de eigen provider is, echter indien de tijdelijke server een vijandige server is heeft de exploitant van deze server vrije toegang tot de informatie in het e-mail bericht. 5 http://www.ietf.org/rfc/rfc2487.txt. 6 MTA: Message Transfer Agent.

3.1. TLS en de vier kwetsbaarheden van SMTP Van de vier eerder aangehaalde kwetsbaarheden adresseert TLS alleen het afluisteren. SMTP over TLS blijft kwetsbaar op de andere drie punten. Falsificeren van de afzender (originator spoofing) TLS beschermt alleen de SMTP sessie en heeft geen invloed op de bron van het bericht. Ook een e-mail van een vervalste bron kan via SMTP over TLS verzonden worden Herleiden van een bericht (man in the middle) TLS beschermt alleen de SMTP sessie en heeft geen invloed op de routering van een bericht die plaatsvindt voordat een SMTP/TLS sessie gestart wordt Veranderen van de inhoud van een bericht (tampering) TLS beschermt alleen de SMTP sessie, niet de informatie opgenomen in het bericht. Zowel op de SMTP client als de SMTP server staat het bericht in leesbare vorm. Tijdens deze (tijdelijke) opslag kan de inhoud van het bericht veranderd worden Afluisteren (eavesdropping) Bij het afluisteren van een versleutelde TLS sessie zal geen informatie uit het bericht verkregen worden

4. S/MIME - Secure MIME S/MIME is de versleutelde variant van MIME. Bij gebruik van S/MIME wordt de inhoud van een e-mailbericht versleuteld. Tevens wordt informatie over de afzender vastgelegd in een S/MIME Signature. S/MIME biedt geen oplossing voor de overige kwetsbaarheden van SMTP, maar het risico wordt wel weggenomen doordat de informatie in het bericht te allen tijde versleuteld is. 4.1. Client based S/MIME Puur S/MIME is een client-to-client protocol. Indien een gebruiker bij het verzenden aangeeft dat een bericht versleuteld moet worden en de mail client de beschikking heeft over de publieke sleutel van de geadresseerden zal het bericht versleuteld en gesigneerd worden. De implementatie van client based S/MIME stuit echter op een groot aantal praktische bezwaren. De belangrijkste daarvan zijn het arbeidsintensieve karakter en de afhankelijkheid van de gebruikers, welke immers moeten aangeven dat een bericht versleuteld moet worden. 4.2. Server based S/MIME Server based S/MIME is gebaseerd op een vrije interpretatie van de S/MIME standaard 7 waarbij de mate en manier waarop van de standaard wordt afgeweken per leverancier verschilt. Naast de producten die alleen bescherming bieden als zowel zender als ontvanger Figuur 3 server-to-server S/MIME gebruik maken van hetzelfde product zijn er meerdere server based S/MIME oplossingen beschikbaar die compatible zijn met client based S/MIME. Hierdoor zijn deze server based S/MIME oplossingen ook onderling te koppelen. Server based S/MIME is dus geen single vendor oplossing. Doordat de feitelijke versleuteling in een gecontroleerde omgeving plaatsvindt op een server, worden de grootste bezwaren van een organisatiebrede implementatie van S/MIME 7 De S/MIME standaard is beschreven in RFC s 2630-2634 is een client-to-client standaard. Op dit moment is er geen standaard voor server based S/MIME, noch zijn er ontwikkelingen op dat gebied.

weggenomen. Bij server based S/MIME wordt de beslissing of een e-mail bericht versleuteld moet worden gebaseerd op regels. Met twee eenvoudige regels kunnen de organisaties A en B al hun onderling uitgewisselde e-mail verkeer beveiligen. 4.3. S/MIME en de vier kwetsbaarheden van SMTP S/MIME adresseert vier eerder aangehaalde kwetsbaarheden. Alleen ten aanzien van het afluisteren van SMTP transport moet opgemerkt worden dat bij gebruik van S/MIME de adresgegevens leesbaar blijven. Falsificeren van de afzender (originator spoofing) De inhoud van een S/MIME bericht is door de afzender voorzien van en elektronische handtekening. Hierdoor is de authenticiteit van het bericht voor de ontvanger eenvoudig te verifiëren Herleiden van een bericht (man in the middle) Hoewel S/MIME feitelijk niets verandert aan deze kwetsbaarheid van het SMTP protocol is het risico wel weggenomen. De middle man kan alleen beschikken over de versleutelde inhoud van het bericht en niet over de daarin opgenomen informatie. Veranderen van de inhoud van een bericht (tampering) Hoewel S/MIME feitelijk niets verandert aan deze kwetsbaarheid van het SMTP protocol is het risico wel weggenomen. De middle man kan alleen beschikken over de versleutelde inhoud van het bericht en niet over de daarin opgenomen informatie. Deze informatie kan ook niet veranderd worden. Afluisteren (eavesdropping) Bij het afluisteren van een verzending van een S/MIME bericht kan alleen informatie over de afzender en ontvangers van het bericht verkregen worden.