Waarom elke mailinstelling goed moet staan

Elke naam die je machine vandaag opzocht, geloofde hij, en daar heb ik een hele post over geschreven. Deze gaat over wat er met de mail gebeurt na de lookup. De korte versie: hij wordt verstuurd naar een server die DNS koos, over een kanaal dat alleen versleuteld is als niemand bezwaar maakt, met een bericht dat iedereen op het pad kan lezen en wijzigen, en vrijwel geen van de beschermingen die dat zouden tegenhouden staat aan.

Dat is niet één kapot ding. Het zijn er zeven, elk zo ontworpen dat de mail bij een fout toch doorgaat. Geen foutmelding. De factuur komt aan. De wachtwoordreset komt aan. Ze komen alleen ook aan bij, of via, iemand die ze nooit had mogen zien, en nergens zegt iets dat.

Deze post is het pleidooi om elk van die instellingen goed te zetten, met het bewijs voor wat elk waard is. De drie posts erna bouwen het op echte servers: Postfix, Microsoft 365 en Stalwart. Deze gaat over het waarom.

De aanval die de standaard beschrijft en vervolgens verbiedt

Begin bij de pijp tussen twee mailservers, want dat is het deel waarvan de meeste mensen denken dat het al opgelost is. STARTTLS is het commando dat een SMTP-verbinding opwaardeert naar TLS. De meeste mailservers ondersteunen het, de meeste mail is versleuteld onderweg, en dat klinkt als een opgelost probleem tot je leest hoe de opwaardering wordt aangeboden.

De ontvangende server adverteert STARTTLS in zijn begroeting. De verzendende server ziet het aanbod en neemt het aan. Niets ondertekent dat aanbod en niets beschermt het. Dus een machine op het pad ertussen kan de regel verwijderen, en dit is het resultaat, vastgelegd in een lab vanaf een verzender die op de gewone opportunistische standaard staat:

 ~> EHLO client.test
[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
 -> Please pay invoice 1042 to sort code 20-00-00, account 12345678.
<-  250 2.0.0 Ok: queued as D6A84132069C

De verzender zag geen STARTTLS aangeboden, dus deed hij wat opportunistisch betekent: hij verstuurde toch, in leesbare tekst. De machine in het midden las het hele ding, inclusief factuur en bankgegevens. De mail werd bezorgd. Geen foutmelding bereikte iemand.

Ik heb die aanval niet verzonnen. RFC 3207, de standaard die STARTTLS definieert, beschrijft hem precies in zijn eigen Security Considerations:

A man-in-the-middle attack can be launched by deleting the “250 STARTTLS” response from the server. This would cause the client not to try to start a TLS session.¹

Dezelfde sectie geeft de verdediging, en het is de voor de hand liggende: kunnen eisen dat er TLS is. “both clients and servers MUST be able to be configured to require successful TLS negotiation … for selected hosts before messages can be successfully transferred.”¹ Configureer de ontvanger dus om het te eisen, en de gestripte sessie wordt geweigerd:

[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
<** 530 5.7.0 Must issue a STARTTLS command first

Behalve dat je dat niet kunt, niet op een publieke MX, want dezelfde standaard verbiedt het:

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.²

Lees die twee citaten samen. De standaard beschrijft een man-in-the-middle-aanval, vertelt je dat de verdediging is om TLS te eisen, en vertelt je dan dat je publieke mailserver het niet mág eisen. Lees dat nog eens. Die regel werd in 2002 geschreven om de mail te laten stromen tussen servers die nog niet allemaal TLS konden. Hij geldt nog steeds, en het is de reden dat het grootste deel van het internet nog steeds mail in leesbare tekst accepteert, en de reden dat het strippen van STARTTLS vandaag nog werkt.

Er is ook een competente versie van de aanvaller. Een ontvanger die TLS eist redt je niet, want de aanvaller hoeft de sessie niet in leesbare tekst door te geven. Hij kan de gedowngradede leesbare tekst van de verzender lezen en zijn eigen volstrekt geldige TLS-verbinding naar de ontvanger openen, die een goed certificaat ziet en tevreden is. Ik liet beide helften in het lab zien: de strip die de verzender blootlegt, en een gewone TLS-client die de strikte ontvanger zonder klagen accepteert. Het beleid van de ontvanger kan dit niet tegenhouden. Alleen de verzender die weigert te versturen zonder geauthenticeerde TLS houdt het tegen, en dat is het hele pleidooi voor DANE³ en MTA-STS,⁴ die verderop in deze post komen.

Zeven instellingen, en hoe elk ervan open faalt

De pijp is een van twee problemen. Het andere is identiteit: een bericht dat versleuteld aankomt, beweert nog steeds alleen maar van wie het zegt te zijn. Er zijn dus zeven instellingen in het spel, verdeeld over die twee taken, en wat ze gemeen hebben is het eerste wat je moet leren.

Hier is elk ervan: wat het beschermt, en wat het doet als het fout staat. Let op de laatste kolom. Er staat bijna altijd dat de mail toch doorgaat.

Zes van die zeven bezorgen de mail toch als ze fout staan. DANE is de uitzondering. Het is de enige instelling in de hele lijst die gesloten faalt: zet hem fout en je mail stopt in plaats van te lekken. Houd die gedachte vast, want het blijkt de reden te zijn dat mensen er bang voor zijn, en de reden dat het de meest waardevolle is.

Een woord over elk van de identiteitsdrie, want de rest van deze serie leunt erop. SPF somt de servers op die voor een domein mogen versturen, en eindigt in een regel: -all betekent “niemand anders”, ~all betekent “niemand anders, maar bezorg het toch”. DKIM voegt een cryptografische handtekening over het bericht toe, zodat elke wijziging zichtbaar wordt, zolang het domein daadwerkelijk een sleutel heeft gepubliceerd om hem tegen te controleren. DMARC knoopt de twee aan elkaar en vertelt de ontvanger wat te doen als ze falen, en of ze overeenkomen met het From:-adres dat de lezer werkelijk ziet. Dit zijn RFC’s 7208, 6376 en 7489, en ze zijn elk een eigen post waard.^{6 7 8}

DMARC alleen laat een geknoeide factuur door

De identiteitslaag heeft een gat precies waar het het meest kost, en dat is het waard om te laten zien, want “wij hebben DMARC op reject” is wat mensen zeggen als ze denken dat ze gedekt zijn.

DMARC slaagt als of SPF of DKIM slaagt en overeenkomt met het From:-domein. Een van beide, niet allebei. Neem dus een echt ondertekend bericht van een domein, wijzig de bankgegevens in de body, en stuur het door vanaf dezelfde plek:

SPF slaagt nog steeds, want het kwam van een geautoriseerde server. De DKIM-handtekening faalt nu, want de body is gewijzigd. Maar DMARC heeft maar één uitgelijnde pass nodig, en SPF gaf er een, dus DMARC slaagt en het bericht met het nieuwe rekeningnummer wordt bezorgd en ziet er precies uit als het origineel. Ik legde dit vast in het lab: Rspamd scoorde het als R_SPF_ALLOW, R_DKIM_REJECT en DMARC_POLICY_ALLOW, en op zichzelf zou het bezorgd zijn. Het enige wat het tegenhield was een regel die bij een gebroken handtekening botweg weigert. Een domein op p=reject is niet beschermd tegen het knoeien dat die handtekening juist moest opvangen. Dat is het waard om te weten voordat je de klus klaar noemt.

DANE is niet beter dan de DNSSEC eronder

Nu de transportinstellingen die de competente aanvaller wél tegenhouden, want ze verplaatsen de beslissing naar de verzender. DANE is de sterkste ervan. Het laat een domein in DNS een vingerafdruk publiceren van de sleutel die zijn mailserver zal presenteren, in een TLSA-record, zodat een verzendende server alles kan weigeren wat niet overeenkomt.⁹ Geen certificaatautoriteit erbij, geen vertrouwen in wie de TLS-handshake ook beantwoordde. De domeineigenaar zegt “dit is mijn sleutel”, en daarmee is het klaar.

Behalve dat DNS-antwoorden vervalsbaar zijn, dus een vingerafdruk die in gewone DNS wordt gepubliceerd is niets waard: dezelfde aanvaller die STARTTLS stript kan je een valse vingerafdruk aanreiken die bij een valse sleutel past. DANE betekent pas iets als de DNS waarin het leeft met DNSSEC is ondertekend, zodat de vingerafdruk zelf niet vervalst kan worden. Dat is de hele keten, en het is de reden dat deze post in een serie staat die met DNSSEC begon. Als je het nog niet bent tegengekomen, het voorwerk staat in /nl/dns/dnssec-the-root-is-signed-you-are-not/, en de versie van één regel is: de root is ondertekend, elk noemenswaardig TLD is ondertekend, en dan houdt het abrupt op bij de namen die mensen werkelijk gebruiken.

Het diagram toont twee domeinen die beide een TLSA-record publiceren. Het ene zit in een ondertekende zone, met een ononderbroken keten van handtekeningen van de root tot aan de vingerafdruk, dus een verzender kan het vertrouwen. Het andere zit in een niet-ondertekende zone, dus zijn vingerafdruk is gewoon bytes die iedereen geschreven kan hebben, en een correcte verzender negeert het volledig en krijgt helemaal geen DANE-bescherming. Hetzelfde record, op twee manieren gepubliceerd. Maar één ervan kan bewijzen dat het echt is.

Het te publiceren record is 3 1 1: de eigen sleutel van de server in plaats van die van een CA, de publieke sleutel in plaats van het hele certificaat, gehasht met SHA-256. Het middelste getal is het getal dat operationeel loont, want het pinnen van de sleutel in plaats van het certificaat betekent dat het record elke vernieuwing overleeft zolang je dezelfde sleutel houdt. De Postfix-post heeft de volledige procedure en de valkuil waar mensen in trappen, namelijk dat de gebruikelijke manier om certificaten te vernieuwen elke keer een nieuwe sleutel maakt en het record stilletjes breekt. Voor hier is het ding om mee te nemen dat 3 1 1 plus hergebruik van de sleutel een record is dat je één keer publiceert en verder met rust laat.

De huisregels, en wat elk ervan kost

Alles hierboven wordt een korte lijst regels, en de volgende drie posts houden echte servers eraan. Ze zijn niet verzacht, en ze zijn niet gratis. Hier zijn ze met de rekening erbij, want een regel waarvan je de kosten verzwijgt is een regel die je niet echt besloten hebt te houden.

De doorstuurkosten zijn degene die bijten, en ze zijn echt: weiger op SPF alleen en een bericht dat is doorgestuurd vanaf een plek die niet in het SPF-record van de verzender staat, wordt geweigerd, want voor de ontvanger ziet een doorstuurder er precies uit als een vervalser. Er zijn oplossingen, SRS en ARC,¹⁰ en de Postfix-post toont de mislukking. Het eerlijke standpunt is dat deze regels wat mail terugsturen die een lossere server wel bezorgd zou hebben. Dat is juist de bedoeling. Een deel van die mail hoorde teruggestuurd te worden, en de rest vertelt je over een doorstuuropstelling die erop leunde dat niemand controleerde.

Het faalt open, en hier is het bewijs

De bewering waar deze hele post op rust, is dat deze instellingen stil open falen, zodat je een werkende niet van een kapotte kunt onderscheiden door te kijken. Dat is geen theoretische zorg. Bij het bouwen van de Postfix-server voor de volgende post gebeurde elk van deze mislukkingen, en elk was een instelling die er geconfigureerd uitzag en niets deed.

Zes echte instellingen, elk uit het bouwen van de Postfix-server voor de volgende post. Vijf faalden open: ze bezorgden de mail, zonder foutmelding, en leken in alle opzichten gewoon goed te werken. De zesde, het verouderde DANE-record, faalde gesloten. Het is degene waar iedereen bang voor is, en het is de enige die het bericht beschermde in plaats van het te laten lekken. De les staat precies daar in de laatste kolom van het diagram: de instelling die mensen mijden omdat die hun mail zou kunnen tegenhouden, is de enige die zich gedraagt zoals een beveiligingsmaatregel hoort.

Elke regel daarvan is een vastlegging, geen lezing van een handleiding. De manier om een werkende instelling van een kapotte te onderscheiden is om het bericht te sturen dat die moet tegenhouden en te kijken wat er terugkomt, en ik zeg het hier één keer en bewijs het drie keer in de rest van de serie.

Dus wie doet er eigenlijk iets van dit alles?

Zeggen dat de instellingen ertoe doen is één ding. Vragen of de organisaties wier mail er het meest toe doet ze hebben aangezet, is iets anders. Dus dat deed ik, met niets dan alleen-lezen DNS en een validerende resolver, op 22 oktober 2026: zesentwintig domeinen die mail ontvangen, de banken, de grote providers, de Duitse specialisten en de certificaatautoriteiten, elk gecontroleerd op de zeven dingen in deze post.¹¹

Lees eerst de DMARC-kolom van boven naar beneden, want dat is degene die grotendeels is ingevuld. De meeste hiervan publiceren een DMARC-beleid, en de meeste banken staan op reject. DMARC is de instelling die wél wordt gedaan, want het is degene waar een auditor naar vraagt en degene die een leverancier je kan verkopen, en het is zichtbaar: je kunt het opzoeken en een vakje aanvinken. Het is ook, op zichzelf, de instelling die eerder in deze post een geknoeide factuur doorliet.

Lees nu de DANE-kolom, de enige instelling hier die niet gedowngraded en niet vervalst kan worden. Vijf domeinen van de zesentwintig. Elk ervan is een Duitse provider of Proton. Geen enkele Britse bank. Geen van de certificaatautoriteiten, de bedrijven wier hele business het is om in te staan voor sleutels. De sterkste bescherming tegen precies de aanval waarmee deze post opende, wordt gedaan door een handvol mensen dat erom geeft, en door niemand die louter compliant is.

De banken zijn de scherpste rij. Acht ervan, elk op DMARC reject, en samen: geen DANE, geen afgedwongen MTA-STS, en één enkele, Monzo, bereikbaar over IPv6. Twee van de vier certificaatautoriteiten publiceren geen SPF-record op hun eigen apex. HMRC en NatWest hebben er ook geen. Dit zijn geen kleine clubjes die er nooit aan toe kwamen. Dit zijn de organisaties die je de mail sturen waarvan je het meest bang bent dat iemand die namaakt, en de bescherming die ze hebben is het keurmerk dat er het sterkst uitziet en het minst doet.

De IPv6-kolom is zijn eigen kleine schandaal. Twintig van de zesentwintig hebben helemaal geen AAAA-record op hun mailserver, dus een verzender op een IPv6-only-netwerk kan ze niet bereiken, en dat getal gaat maar één kant op. Ik schreef /nl/networking/we-never-ran-out-of-addresses/ over de weigering van de sector om die klus af te maken, en hier is het weer, dit keer in het mailpad. Het heeft dezelfde vorm als de gov.uk-telling in /nl/dns/dnssec-the-root-is-signed-you-are-not/: het moeilijke deel was jaren geleden af, de registries geven het weg, en de mensen die het het duidelijkst zouden moeten gebruiken, deden het niet. Het centrale gov.uk staat niet eens in de tabel, want het publiceert helemaal geen MX. Het ontvangt geen mail. Dat is één manier om de test te doorstaan.

Als je dit nog steeds niet doet, kun je jezelf dan een professional noemen?

Elke standaard die in deze post wordt genoemd, en de telling eronder, wijzen één kant op: dit is geen onderzoeksprobleem, het is een aanzetprobleem, en het aanzetten wordt niet gedaan door de mensen die er het best voor zitten. Als het bewijs zo scheef ligt, houdt de vraag op academisch te zijn en wordt het er een die je over je eigen servers moet beantwoorden. Als je mail draait voor een organisatie die het geld van anderen of de gezondheid van anderen beheert, en je MX doet geen DANE, dwingt geen MTA-STS af en is niet over IPv6 te bereiken, kun je dat dan professioneel werk noemen?

Er zijn drie eerlijke antwoorden, en alleen de eerste twee houden stand. Ja, met een reden opgeschreven en een datum ernaast: je zit op een platform dat nog geen DANE biedt, je hebt het aangekaart, en er staat een regel in het plan van volgend jaar. Dat is een professional die een echte beperking beheert, en dat is prima. Ja, omdat je het niet wist, en nu wel, en je gaat deze week uitzoeken hoe je server ervoor staat. Niemand begon dit te weten. En nee: je wist genoeg om je ongemakkelijk te voelen, je hebt tot hier gelezen, en je zult het tabblad sluiten en niets veranderen, want de mail stroomt en er wordt geen foutmelding gegeven en niemand dwingt je. Dat laatste is geen kennisgat. Het is een besluit om iets waar je verantwoordelijk voor bent kapot te laten omdat kapot stiller is.

De standaard dwingt je niet. Dat is het hele probleem, en het is ook het hele punt. Weten is niet iets wat je overkomt, en niemand komt je vertellen dat je mailserver twee jaar lang stilletjes in leesbare tekst heeft verstuurd. Zorgen dat je het weet is dan ook de klus, en van niemand anders.

Een standaard is een belofte die je houdt als niemand kijkt

De onderdelen hiervan waren allemaal jaren geleden af. STARTTLS is van 2002, SPF en DKIM en DMARC zijn tien jaar oud of meer, DANE voor mail werd in 2015 gespecificeerd, MTA-STS in 2018. Niets ervan zit achter een licentie, niets ervan heeft een leverancier nodig, en de registries die de DNSSEC-records zouden dragen, geven ze weg. Het zware engineeringwerk is gedaan. Wat rest is het makkelijke deel, het deel dat alleen makkelijk is als iemand de moeite neemt: het aanzetten, en controleren dat het echt aanstaat, en het aan houden als het certificaat vernieuwt en het record moet volgen.

Dat laatste deel is eigenlijk het hele ding. Een standaard is niet het document. Het document bestaat al twintig jaar en de mail gaat nog steeds in leesbare tekst. Een standaard is iets wat je houdt als er geen foutmelding is die je dwingt het te houden, als de mail net zo goed zou stromen als je het stilletjes liet versloffen, als de enige die het ooit zou weten jijzelf bent. Elk van deze instellingen faalt open juist zodat niemand gedwongen wordt zich erom te bekommeren. Wat betekent dat je erom bekommeren de hele klus is.

Je krijgt er geen beloning voor. De factuur die niet gewijzigd werd, ziet er precies zo uit als de factuur die dat wel werd. De wachtwoordreset die niemand onderweg las, ziet er precies zo uit als die iemand wel las. Het enige verschil zit op de dagen dat er iets probeerde, en op die dagen komt degene die het allemaal aanzette en controleerde dat het werkte er nooit achter dat hij werd aangevallen, want het werkte niet. Zo ziet de klus goed doen er van buitenaf uit: niets dat gebeurt, om redenen die niemand kan zien.

Zet dus toch elke instelling goed. Niet omdat iemand controleert, want niemand doet dat. Doe het omdat jij degene bent die zei dat de mail veilig was, en hier telt dat nog steeds ergens voor.