Ook verdwaald in het oerwoud van SPF, DKIM, DMARC en SMTP? Of altijd willen weten wat er gebeurt zodra je op "Verzenden" drukt na het dichten van een mailbericht? Laten we eens duiken in de wereld van een van de oudste Internet communicatiemethoden: e-mail
Zo'n beetje iedereen heeft wel een of meerdere e-mailadressen. Maar hoe weet nou de afzender jouw mailbox te vinden op basis van een e-mailadres> Een emailadres bestaat uit twee delen: een lokaal deel en een domeindeel, gescheiden door het @-symbool (bijvoorbeeld: hacker@nlcyber.com). Een verzendende mailserver maakt zich eigenlijk alleen maar druk om het domeindeel. Op basis van het lokale deel een bericht in jouw mailbox laten landen is de verantwoordelijkheid voor de ontvangende mailserver. Om de mailserver van de geadresseerde te achterhalen wordt een systeem gebruikt dat we ook kennen van webbrowsers die een servernaam in de adresbalk omzetten naar een IP-adres: DNS
De verzendende mailserver zoekt naar een zogenaamd MX record (Mail Exchange) voor het domein dat is besloten in het e-mailadres van de geadresseerde, in ons geval nlcyber.com. Dit kunnen we eenvoudig nabootsen met het nslookup commando:
nslookup
> set type=mx
> nlcyber.com
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
nlcyber.com mail exchanger = 10 smtp.google.com.
Dit zegt ons in feite dat er een server met de naam smtp.google.com is, die mail accepteert voor e-mailadressen in het nlcyber.com domein.
Willen we nu ook het IP-adres weten, dan kunnen we dat doen door het op te zoeken via een 'A'-record (wat het standaard type is voor nslookup):
nslookup smtp.google.com
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
Name: smtp.google.com
Address: 142.250.27.26
Name: smtp.google.com
Address: 142.250.102.26
Name: smtp.google.com
Address: 142.250.27.27
Name: smtp.google.com
Address: 142.250.102.27
De verzendende mailserver zal nu proberen via een protocol genaamd SMTP (Simple Mail Transfer Protocol) proberen om het e-mailbericht af te leveren op 1 van deze servers. SMTP maakt gebruik van TCP poort 25 en begroet ons ongeveer als volgt:
nc smtp.google.com 25
220 mx.google.com ESMTP a640c23a62f3a-af99cc36d3csi1199283766b.528 - gsmtp
Als wij teruggroeten met een EHLO-commando (Extended Hello), krijgen we van die mailserver een antwoord met een aantal functies die de server te bieden heeft:
EHLO mail.nlcyber.com
250-mx.google.com at your service, [62.45.33.51]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
Deze server van Google meldt ons bijvoorbeeld:
Let op dat wij in onze EHLO-begroeting de naam mail.nlcyber.com meegeven. Veel mailservers zullen deze informatie checken door te kijken of er een overeenkomstig A record in DNS bestaat. De meeste mailservers checken zelfs het adres dat daaruit volgt ook geregistreerd is in DNS in de vorm van een PTR record (reverse lookup).
De volgende regels identificeren de afzender en de ontvangers(s), gevolg door het bericht zelf:
MAIL FROM:<sender@nlcyber.com>
RCPT TO:<receiver@nlcyber.com>
DATA
Hello world!
.
Ooit was dit al genoeg om een mailtje in iemands inbox te laten belanden. Maar het is mogelijk al duidelijk dat deze tranmissie een aantal problemen heeft:
MX-records)Om nu de vertrouwelijkheid te kunnen garanderen, ondersteunen de meeste mailservers TLS. Met het STARTTLS commando wordt binnen de bestaande TCP sessie een versleutelde TLS-sessie(ook nog wel eens SSL genoemd, naar de verouderde standaard) onderhandeld. Dit is vergelijkbaar met hoe een webbrowser een HTTPS gebruikt, met een certificaat dat gepresenteerd wordt door de serverzijde. In tegenstelling tot websites, hebben nog altijd veel mailservers geen certificaat dat is uitgegeven door een vertrouwde CA (Certificate Authority. Bovendien, het identificeert dus in feite alleen de ontvangende mailserver en niet de verzendende mailserver. Dus als we communiceren met een mailserver die een TLS sessie opzet met een vertrouwd certificaat, dan hebben we naast het MX record een stukje extra zekerheid dat we met de juiste server praten, plus dat de communicatie niet afgeluisterd kan worden (omdat het versleuteld is én omdat een Man-in-the-Middle aanval niet kan slagen omdat de aanvaller niet over een geldig certificaat beschikt). De ontvangende partij weet echter nog steeds niet of de identiteit van de verzendende mailserver klopt...
Om ook de verzendende partij te kunnen valideren is SPF (Sender Policy Framework) in het leven geroepen. Ook dat mechanisme maakt gebruik van DNS en is bedoeld om valide mailservers aan te wijzen, die uit naam een bepaald domein mail mogen verzenden.
SPF maakt gebruik van TXT records. Een voorbeeld voor nlcyber.com kunnen we weer opvragen met NSLOOKUP:
nslookup
> set type=txt
> nlcyber.com
Server: 192.168.1.254
Address: 192.168.1.254#53
nlcyber.com text = "v=spf1 ip:1.2.3.4 include:_spf.firebasemail.com include:amazonses.com ~all"
Een SPF is in feite een lijst met naam/waarde combinaties:
-all, wat betekent dat de mail geweigerd dient te worden. Waarom dat niet altijd een goed idee is valt buitende scope van dit artikel.Met SPF hebben we de verzendende server gevalideerd, maar nog niet de individuele berichten. Het komt namelijk vaak voor dat mail wordt doorgestuurd via meerdere servers, en in principe hebben al die servers de mogelijkheid om de inhoud van een bericht te wijzigen. Om dat te ondervangen bestaat DKIM. Dit mechanisme kent aan een mailserver een asymetrische sleutel toe. Het privedeel kan de server gebruiken om berichten te voorzien van een digitale handtekening. Het publieke deel van de sleutel word gepubliceerd in -jawel- DNS, zodat ontvangers de digitale handtekening kunnen valideren, en daarmee kunnen vaststellen dat er niet met het bericht (inclusief headers) tussen de server en de eindbestemming is geknoeid.
Een handtekening wordt aan een bericht toegevoegd in de vorm van een header, bijvoorbeeld:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; t=1678886400;
h=From:To:Subject:Date;
bh=********;
b=*****************************************************
Hierin zijn een aantal kenmerken te onderscheiden:
selector die aangeeft welke sleutel is gebruikt, en bepaalt welk "subdomein" je moet opzoeken in DNSAls we nu de handtekening willen valideren hebben we de bijbehorende public key nodig. Zoals gezegd kunnen we die samenstellen uit de waarden hierboven:
In dit geval zegt q dat we een TXT record moeten gebruiken:
> selector1._domainkey.example.com
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
selector1._domainkey.example.com text = "v=DKIM1; p=*********"
De laatste schakel in emailbeveiliging is DMARC. DMARC geeft aan wat een ontvangende mailserver wordt geacht te doen als bepaalde checks falen. Bijvoorbeeld: