GlobalSign Blog

E-mailauthenticatie – De ins en outs van het beschermen van jouw inbox

E-mailauthenticatie – De ins en outs van het beschermen van jouw inbox

eIDAs Blog CTA.png

E-mails – je kunt er niet mee leven, je kunt niet zonder, nietwaar?

De gemiddelde kantoormedewerker krijgt er ongeveer 121 per dag, dus is het geen wonder dat de werknemers hun eigen mechanismen hebben moeten bedenken om te beslissen aan welke e-mails ze aandacht moeten besteden en aan welke niet. Enkele jaren geleden was dat ook het geval voor de goede oude ‘fysieke’ post. Hoeveel advertenties heeft u moeten bekijken om bij de belangrijkste stukken te komen?

Interessant genoeg is de beslissing om een poststuk - digitaal of fysiek - te openen of in de prullenbak te gooien vaak op één enkele factor gebaseerd: de naam van de afzender die op de enveloppe staat.

Afzenderauthenticatie voor e-mail

Maar is dit eigenlijk wel een redelijke manier om een onderscheid te maken? Hoe kunnen we weten dat de naam op de enveloppe niet vervalst is?

Het antwoord luidt: Zonder beter te kijken, kunnen we dat niet! Voor fysieke post zijn er garanties zoals handtekeningen, stempels, zegels en een correcte procedure voor degenen die onze post behandelen. Maar zelfs dan zullen er af en toe zeer geloofwaardige vervalsingen van officiële documenten de ronde doen, omdat misdadigers hun best doen om mensen op te lichten en hun geld afhandig te maken.

Het kan de besten van ons overkomen. Enkele jaren geleden ontving ik een aantal facturen van mijn vervoerder. Ik betaalde maar een paar weken later kreeg ik dezelfde factuur. Bij een tweede blik werd het duidelijk dat het rekeningnummer op de tweede factuur anders was. Nadat ik de vervoerder gebeld had, vernam ik dat het om oplichterij ging - slimme oplichterij, want de brief zelf was totaal niet van echt te onderscheiden!

Voor elektronische post zijn er andere mechanismen om te bepalen of het bericht al dan niet legitiem is en die tools moeten zeker gebruikt worden; want er is niet veel technische kennis voor nodig om het ‘Van’ verzendersadres (naam en e-mailadres dat aan de ontvanger getoond wordt) te vervalsen. In technische termen heet dit spoofing. Kijk maar eens hier:

FakeEmailAddressVideo.jpg

Welke mechanismen hebben wij om vervalste e-mails te voorkomen en op te sporen?

DKIM, SPF en DMARC

DomainKey Identified Mail (DKIM), Sender Policy Framework (SPF) en Domain-based Message Authentication, Reporting & Conformance (DMARC) zijn op DNS gebaseerde mechanismen die het vervalsen van e-maildomeinen moeten voorkomen.

Laten we elk van deze mechanismen in meer detail bekijken, waarbij we bekijken hoe ze werken en wat ze wel en niet kunnen doen.

SPF

Het idee achter SPF is eenvoudig. Wanneer SPF voor een domein wordt ingesteld, wordt er een specifieke DNS TXT-vermelding voor dat domein aangemaakt. Een juist geconfigureerde mailserver aan de ontvangende kant, die een mail verstuurt van het domein van de afzender, zal dan de SPF-vermelding tegenkomen bij een DNS lookup.

Laten we eens kijken naar het eerste deel van de vermelding voor globalsign.com om dit beter te begrijpen:

v=spf1 ip4:114.179.250.0/30 ip4:211.123.204.251/32 ip4:27.121.42.215/32 […] -all

De logica is hier vrij eenvoudig. v=spf1 verklaart dat deze vermelding betrekking heeft op SPF. De reeks IP-adressen geeft alle IP-adressen aan die een ontvangende mailserver moet accepteren als herkomst voor een mail met het domein globalsign.com. En -all betekent dat als een ander IP-adres namens globalsign.com een mail verstuurt, de ontvangende mailserver de mail in quarantaine moet plaatsen of hem helemaal moet weigeren.

De hele invoer zou nog wat langer zijn en een lijst bevatten van domeinen die namens globalsign.com kunnen verzenden, maar het bovenstaande is zo'n beetje alles wat erover te zeggen valt. Er zijn echter enkele beperkingen aan SPF. Bij doorgestuurde mails en geavanceerde spoofing, waarbij ook het IP-adres van de afzender gemanipuleerd wordt, kan SPF falen. In dat geval zijn er andere mechanismen nodig om hogere zekerheidsniveaus te creëren.

DKIM

Daarom is DKIM in het leven geroepen. Het biedt een hogere mate van zekerheid voor de echtheid van het domeingedeelte van de e-mail van een afzender. De hogere mate van zekerheid komt van een cryptografische handtekening (een beetje zoals S/MIME, maar niet helemaal...) en dus is één vereiste voor het instellen van DKIM het maken van een openbaar/privé sleutelpaar. De openbare sleutel wordt dan genoteerd in de DNS-zone van het domein en kan door de ontvangende mailserver worden opgehaald om e-mails te valideren die van dat domein komen, en die ondertekend zijn met de bijpassende privé sleutel.

Laten we nog eens kijken naar een van de vermeldingen voor globalsign.com:

"v=DKIM1;k=rsa;

p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1vhugV30ayqwRy2mu+m6QyxvdVtHe

e/ChrUqtrPflazjf3LfuGryocUGTZ66DsHZeTpjqdcRRXms1+xpVsqqeiXipw4jNPwx9VpyIyg0suI/2Q

YsIjKyj0OFYWe22Ilgp/zjXXJUxJ4fTqT5ae0cAX5u3GNsj6dA8u9n3atIlIwIDAQAB"

Net als bij SPF verklaart v=DKIM1 dat deze invoer bedoeld is voor DKIM. k=rsa laat de ontvangende mailserver weten dat dit sleutelpaar van het RSA-type is en de p=[...] is de openbare sleutel zelf. Opnieuw vrij eenvoudig. Wanneer een mail van globalsign.com verzonden wordt, zal de globalsign.com mailserver de DKIM openbare sleutel gebruiken om de mail cryptografisch te ondertekenen door de mail te hashen, de hash met de openbare sleutel te versleutelen en hem aan de mail te hechten. De ontvangende mailserver kan de mail dan opnieuw hashen en de gecodeerde hash ontcijferen met de openbare sleutel die hij van de DNS-vermelding heeft opgehaald. Als beide hashes overeenkomen, is de mail gegarandeerd afkomstig van globalsign.com en is er niet mee geknoeid.

DMARC

DMARC bindt zowel SPF als DKIM aan elkaar met enkele extra regels om een ontvangende mailserver te laten weten wat hij moet doen met e-mails die niet aan een van de bovenstaande beleidsregels voldoen.

Laten we nog eens naar de vermelding voor globalsign.com kijken:

v=DMARC1; p=reject; rua=mailto:dmarc@globalsign.com

Net als bij SPF en DKIM, geeft v=DMARC1 gewoon aan dat deze DNS TXT-regel een DMARC-beleid declareert. P=reject is het beleid voor mails die niet voldoen aan het bovenstaande, waarbij ‘reject’ betekent dat de ontvangende mailserver deze mails altijd moet weigeren. ‘Quarantaine’ zou betekenen dat de mails naar een soort quarantaine moeten worden verplaatst, zoals spam-mappen of zo. En ‘None’ zou de ontvangende mailserver zelf laten beoordelen of e-mails geweigerd, in quarantaine geplaatst, of doorgelaten moeten worden.

rua=mailto:dmarc@globalsign.com specificeert dan een of meer e-mailadressen die moeten worden verwittigd wanneer de SPF- of DKIM-validatie mislukt. Dit kan nuttig zijn om georganiseerde pogingen van slechte actoren om een domein te vervalsen te onderdrukken, wat vooral nuttig is voor domeinen die vaak het voorwerp zijn van imitatie.

De gaten dichten met S/MIME

SPF, DKIM en DMARC zorgen weliswaar voor een aanzienlijke verbetering van de e-mailbeveiliging, maar ze zijn niet het complete pakket. Er zijn ten minste drie zwakke punten:

  1. Al deze beleidsmaatregelen zijn gebaseerd op DNS en worden dus omzeild door, bijvoorbeeld, de DNS lookup aan de kant van de ontvangers te vervalsen of gewoon een homoglief/alternatieve e-mailadressen voor het afzenderadres te gebruiken die niet het beleid van het eigenlijke domein delen.
  2. De echtheid van e-mail is beperkt tot het domeingedeelte van de e-mail, wat betekent dat er weliswaar enige zekerheid is dat de mail werkelijk van een bepaald domein afkomstig is, maar dat het niet-domeingedeelte nog steeds kan worden vervalst. Dit kan de afzender kwetsbaar maken voor bijvoorbeeld kwaadwillende insiders die mail vervalsen uit naam van een andere interne afdeling of persoon.
  3. Aangezien DKIM-handtekeningen alleen door de mailserver van de afzender worden toegepast en door de mailserver van de ontvanger worden gevalideerd, is de garantie van integriteit van de inhoud en authenticiteit van de afzender niet volledig end-to-end. Het bericht blijft kwetsbaar tussen de client en de mailserver, zowel voor de afzender als voor de ontvanger. Dit kan ondervangen worden door een goede implementatie van TLS voor de mailserver van zowel de afzender als de ontvanger, maar dat is een ander onderwerp dat buiten het bereik van dit artikel valt.

EmailAuth_ServerGraphic.png

Afbeelding 1: Vereenvoudigd overzicht van hoe een standaard e-mail wordt gerouteerd, inclusief relevante DNS lookups

Dit is waar S/MIME het beter doet dan SPF, DKIM en DMARC:

  • S/MIME-handtekeningen worden rechtstreeks door het e-mailprogramma toegepast en worden alleen gevalideerd door het e-mailprogramma van de ontvanger. Dit betekent dat er geen manipulatie van het bericht kan plaatsvinden, zelfs niet tussen mailserver en mailclient.
  • De openbare sleutel voor de validatie van de handtekening is bijgevoegd bij het certificaat dat bij de e-mail zit, en de e-mailclient hoeft dus niet te vertrouwen op een DNS-vermelding.
  • De organisatie van de afzender in het certificaat is ook geverifieerd door de CA die het S/MIME-certificaat afgeeft. Daarom wordt een slechte actor die een homoglief e-mailadres gebruikt, buitengesloten van het gebruik van de organisatienaam van het oorspronkelijke domein.
  • En ten slotte moet de RFC 822-naam in het certificaat precies overeenstemmen met het ‘Van’ e-mailadres, wat betekent dat de authenticiteit van de afzender nu gegarandeerd wordt op het niveau van het e-mailadres en niet langer alleen op het niveau van het domein. Hierdoor worden de hierboven genoemde zwakke punten aanzienlijk verminderd.

Goed, beter, best - wat kiest u voor de e-mailbeveiliging in uw onderneming?

Betekent dit dat elke organisatie S/MIME moet verkiezen boven SPF, DKIM en DMARC? Het antwoord is duidelijk ‘nee’.

Organisaties moeten hun SPF, DKIM en DMARC goed geconfigureerd hebben - eerlijk gezegd zou dit het absolute minimum moeten zijn - maar zoals eerder gezegd, gaan ze niet tot het uiterste. Voor wie de ontvangers van zijn e-mail de hoogste mate van zekerheid wil bieden, moeten S/MIME-certificaten het middel bij uitstek zijn.

Vergeet niet dat S/MIME end-to-end encryptie van e-mail mogelijk maakt - iets wat SPF, DKIM en DMARC helemaal buiten beschouwing laten.

E-mail heeft de laatste twee jaar een ongelooflijke opleving gekend, ongetwijfeld geholpen door de groei van de e-commerce en de verschuiving naar werken op afstand die we tijdens de pandemie hebben gezien. Elke dag worden er meer dan 306 miljard e-mails verzonden en ontvangen (Statista, 2021, via Hubspot).

Helaas hebben hackers dit ook in de gaten en zoeken ze naar nieuwe en geraffineerde manieren om bedrijfsgegevens te infiltreren en schade aan te richten. Slimme bedrijven wapenen hun werknemers met de sterkste methoden voor e-mailbeveiliging die er zijn en op dit moment is dat S/MIME.

Gelukkig zijn de methodes om S/MIME-certificaten in te voeren en te beheren in de loop der tijd alleen maar beter en naadlozer geworden. Ontdek hoe eenvoudig het inschrijven en intrekken van S/MIME-certificaten kan zijn met de Auto Enrollment Gateway, of bekijk nu onze complete reeks tools voor e-mailbeveiliging voor ondernemingen.

Share this Post

Recent Blogs