Dags att göra rätt saker

Ha det så skönt – och glöm inte handduken

Lagom till semestern vill jag ge er något att fundera på där ni ligger i hängmattan och har det skönt. Något som jag själv har haft anledning att fundera på en tid. Vad skulle ni göra om det som inte får hända ändå skulle inträffa? Nu när telefonen tystnat och ni inte längre är absorberade av vardagens ständiga möten och pockande ärenden så får ni kanske tid att reflektera: Vad borde jag egentligen göra i höst?

Till vardags finns det massor av saker som vi skjuter framför oss därför att de inte är ”måsten”, bara ”borden”, sådant som vi skulle vilja göra men inte riktigt hinner med. Som att höja grundsäkerheten i systemen. Vad har hänt sedan det gjordes senast? Har det kommit några nya standarder som jag behöver känna till? Hur skyddar jag vår infrastruktur för DNS från att bli hi-jackad? Har jag infört moderna säkerhetsfunktioner för mejl och webb? Har vi signerat våra domäner med DNSSEC? Vilka funktioner har blivit så inaktuella att de inte längre är till någon hjälp utan snarare förvärrar situationen den dagen något inträffar? Krypterar vi information vid lagring och under transport? Har vi fortfarande kontroll över all information? Har någon annan kontroll över vår information.

Det är inte så att jag tycker att man ska jobba hela semestern och därmed slippa undan små grodorna, säcklöpningen eller kubbspelet med den odrägliga svågern. Inte alls. Men när alla deckare är slut och ni inte kan komma överens om reglerna i Monopol så kanske det är skönt med lite enskild kontemplation.

Själv skriver jag listor. Det är mitt sätt att få ner och sortera tankarna. Andra ritar skisser med boxar, fyrkanter, och pilar. Så, fram med block och penna, lägg dig i hängmattan, sätt dig i skuggan under trädet i skogen, vid stranden på kobben, på verandan på sommarstället, på caféet i världsmetropolen eller något annat av de många smultronställen där du trivs som bäst, och rita lite. Fundera på de stora frågorna. På vad du skulle vilja göra, i stället för att alltid vara tvungen att göra det du måste.

Här är min lista över några av de viktigaste funktionerna för att uppnå en säkrare infrastruktur för kommunikation över internet.

Infrastruktur:

• IPv4 och IPv6 för samtliga funktioner (DNS, mejl, webb)
• Konnektivitet (robusthet)

Domännamnsystemet (DNS):

• Name server configuration
• DNS/DNSSEC
• CAA

Webbtjänster:

Protokoll

• HTTP
• HTTPS

Säker transport

• TLS
• Certificates
• DANE
• Cookies
• Mixed Content

Modernare säkerhetsfunktioner

• Strict Transport Security
• Content Security Policy
• Subresource Integrity
• Referrer Policy
• Permissions Policy
• security.txt

Applikationssäkerhet

• Frame Options
• Content Type Options

Mejl:

Transportskydd (SMTP)

• STARTTLS
• Certificates
• MTA-STS
• TLS-RPT
• DANE

Autentisering och policyer

• SPF
• DMARC

Sommaren är den allra bästa tiden för långsiktig planering och reflektion. Lägg upp en plan för en bättre internetnärvaro. Kolla regelbundet status med Hardenize.com.

Använd säker DNS

Det är genom uppslagningar i domännamnssystemet DNS som det går att hitta fram till rätt dator på internet när man till exempel surfar eller skickar e-post till en viss domän. DNS är en gigantisk databas som översätter domännamn till IP-adresser, det vill säga de unika nummerserier som unikt identifierar internetuppkopplade datorer. Man kan likna det vid hur en telefonkatalog ”översätter” namn till telefonnummer.

Säker DNS, eller DNSSEC som det förkortas, är en funktion som gör internet säkrare genom att försvåra manipulation av den information som trafikerar domännamnssystemet. Med DNSSEC signeras DNS-uppslagningar med kryptografiska nycklar och på så sätt säkerställs att svaren verkligen kommer från rätt källa och inte har ändrats under överföringen till mottagarens resolver.

Genom att använda DNSSEC motverkar du möjligheten att utnyttja några av de mest kända och största hoten mot DNS, cacheförgiftning (cache poisoning) och farmning (pharming).

Cacheförgiftning innebär att en situation skapas, antingen genom en attack eller oavsiktligt, som förser en namnserver med DNS-data som inte kommer från någon auktoritativ källa. Ett av de mest välkända exemplen på detta är den 2008 mycket uppmärksammade Kaminskybuggen.

Farmning innebär att någon kan få själva innehållet i DNS att peka på felaktiga servrar. Rent konkret innebär det att en webbadress för exempelvis en bank kan pekas om till en helt annan webbserver, men för besökaren ser det i adressfältet fortfarande ut som att det är rätt server i andra änden. På det sättet kan en besökare aningslöst lämna ifrån sig känslig information till en angripare.

Många andra internetprotokoll än webb och mejl är också beroende av DNS, medan DNS-information i resolvrarna har kommit att bli så sårbar för attacker att den inte längre går att lita på. Den ökade säkerhet som DNSSEC tillför gör att många attacker inte längre får någon effekt.

Även om man försöker täppa till säkerhetshål så gott det går med de program och verktyg som används vid DNS-uppslagningar, ligger grundproblemet i hur DNS fungerar. Det råder ingen tvekan om att DNS behöver bli säkrare. DNSSEC är en långsiktig lösning som skyddar mot flera olika typer av manipulering av DNS-frågor och -svar under kommunikationen mellan olika servrar i domännamnssystemet.

Det har inte gått någon längre tid sedan den allvarliga attacken med BGP-kapning riktad mot MyEtherwallet, där angriparen använde BGP-läckor för att kapa MyEhterwallets namnservrar på Amazons Route53 och ersätta dem med sina egna falska namnservrar som dirigerade om offer till sina egna falska plånböcker och därmed dränerade deras plånböcker. Det startade en hel del diskussion när det var aktuellt, men nu har den i princip dött ut. Folk slår sig till ro och fortsätter med sina liv. Det som inte alla har förstått är att attacken faktiskt har förändrat spelreglerna något, och det betyder att alla behöver ompröva sin syn på DNSSEC.

Varför spelar DNSSEC någon roll i ett hack som utfördes via BGP-kidnappning? Det går att diskutera hur lätt det är att utföra BGP-kidnappningar, men det finns trots allt inget definierat säkerhetsprotokoll på plats för att förhindra sådana attacker. Förra året fick EasyDNS några av sina IP-adressutrymmen kapade och det tog dem ungefär en vecka för att reda ut det. Den kunde tacka sin lyckliga stjärna att det handlade om outnyttjade IP-adresser, men hela händelsen fick många att inse hur dålig autentiseringen av routingmeddelanden verkligen är. Sedan dess har RPKI, Resource Public Key Infrastructure, fått betydligt större spridning. Med hjälp av Route Origin Authorisations, ROA, kan innehavaren av ett IP-prefix ange vilket autonomt system som har rätt att annonsera det, och nätoperatörer kan använda Route Origin Validation för att upptäcka och avvisa ogiltiga annonser. Införandet är dock ännu inte heltäckande, och ursprungsvalideringen skyddar inte mot alla former av felaktig eller avsiktligt manipulerad routing. DNSSEC är därför fortfarande ett viktigt, oberoende skyddslager som kan förhindra att en omdirigering av trafiken samtidigt leder till att användarna får manipulerade DNS-svar.

Kvar har vi DNSSEC som huvudspår för att försvara oss mot dessa och andra attacker.

Hade MyEtherwallet DNSSEC-signerat sin zon, och dessutom använt TLSA pinning för sina TLS certifikat skulle attacken begränsats. Två av de resolver-tjänster som hämtade de falska IP-adresserna för MyEhterwallet var Google Public DNS och Cloudflare 1.1.1.1, båda DNSSEC-kompetenta resolvrar som istället för falska adresser skulle ha returnerat felmeddelanden.

Office365 och DMARC

Microsoft har gjort ett bra jobb för att stödja SPF, DKIM och DMARC i sin Office365 miljö.

En sak är dock värt att notera:

Fel domän signeras by default

Vanligtvis dyker problemen upp först då en organisation som använder Office365, aktiverar DMARC med en "riktig" policy, dvs "quarantine" eller "reject".

Problemet manifesterar sig vanligen att mottagare, som validerar DMARC, inte längre kan ta emot (om policyn är satt till "reject") mail, alterntivt att inkommande mejl sätt i karantän (om policyn är satt till "quarantine").

Problemet beror i korthet på att defaultinställningen för DKIM i Office365 signerar "fel" domän. Korrigeras detta, så kommer också DMARC att fungera.

Lösning

Publicera två stycken DNS CNAME resource records som pekar på de två DKIM nycklar Microsoft har publicerat för er domän.

Tas lämpligast fram via Powershell:

PS C:\> Get-DkimSigningConfig -Identity xpd.se | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Name            : xpd.se
Enabled         : False
Status          : CnameMissing
Selector1CNAME  : selector1-xpd-se._domainkey.xpd.onmicrosoft.com
Selector2CNAME  : selector2-xpd-se._domainkey.xpd.onmicrosoft.com
			

Sätt sedan upp rätt CNAME i domänen:

selector1._domainkey.xpd.se. IN CNAME selector1-xpd-se._domainkey.xpd.onmicrosoft.com.
selector2._domainkey.xpd.se. IN CNAME selector2-xpd-se._domainkey.xpd.onmicrosoft.com.
			

När det är genomfört så kontrollera att man ser att DKIM är aktiverat och giltigt:

PS C:\> Get-DkimSigningConfig -Identity xpd.se | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Name            : xpd.se
Enabled         : True
Status          : Valid
Selector1CNAME  : selector1-xpd-se._domainkey.xpd.onmicrosoft.com
Selector2CNAME  : selector2-xpd-se._domainkey.xpd.onmicrosoft.com
			

(Jag använder XPD i mina exempel, även om vi inte använder Office365, för att göra det hela lite enklare att förstå)

Förfarandet ovan finns väldigt bra beskrivet av Microsoft i " Use DKIM to validate outbound email sent from your custom domain in Office 365", dock verkar väldigt få hitta den artikeln eller ens känna till problemet innan de drabbas av det.

Det gamla formatet använder ofta mål under onmicrosoft.com. Nyare domäner kan få mål under dkim.mail.microsoft. Det viktiga är inte vilket format som används utan att rätt CNAME-värden publiceras och att signeringen faktiskt är aktiverad.

TL;DR

För varje ny mejlkund i Office365, så sätts en subdomän upp under onmicrosoft.com.

I detta exempel så skulle det ha inneburit att subdomänen xpd.onmicrosoft.com skapas.

Microsoft aktiverar DKIM automatiskt för alla nya kunder, vilket innebär att två stycken DKIM nyckelpar skapas och att de publika nycklarna publiceras som:

selector1-xpd-se._domainkey.xpd.onmicrosoft.com.
selector2-xpd-se._domainkey.xpd.onmicrosoft.com.

(Att två stycken nycklar skapas, selector1 och selector2, är för att facilitera automatisk nyckelrotation enligt Microsoft)

Office365 kommer nu att att genomföra DKIM signering med ovanstående nycklar för domänen xpd.onmicrosoft.com för utgående mejl från Office365:

From: Fredrik Soderblom <fredrik@xpd.se>
.
.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xpd.onmicrosoft.com;
    s=selector1-xpd-se;
    h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
    bh=iWawpsGgHFHdTHWJP334GNNkbPbgdgt0PrAlsT3Lzvg=;

Problemet med detta är att DKIM signeringen kommer endast att vara giltig för domänen xpd.onmicrosoft.com, vilket inte matchar min emailadress (fredrik@xpd.se), vilket i sig inte är ett problem när DMARC inte används.

Men, som leder till ovanstående problem, när DMARC aktiveras i "reject" eller "quarantine" läge, vilket då innebär att DMARC kommer att kräva att domänen som använts för DKIM signering matchar domänen i From: adressen.

Går inte den matchningen att göra, så klarar inte heller mejlet DMARC validering och kommer antingen att kastas (om policyn är "reject") eller att sättas i karantän (om policyn är "quarantine").

Skydda domänen innan någon annan använder den

Flera av de problem som drabbar små och stora företag och myndigheter till exempel skadlig kod eller ransomware, felaktiga utbetalningar har inte alltför sällan sitt ursprung ur nätfiske eller lösenordsfiske (phishing) eller det som kallas "whaling" och som till stor del bygger på att lura mottagaren på ett eller annat sätt, bland annat via förfalskade mejl.

Du har garanterat sett dem, du utlovas ett överdåd av pengar i arv från din saligt avlidne släkting i ett fjärran land, eller bilagor till mejl som innehåller vad som förefaller vara en faktura som behöver betalas skyndsamt.

Inte alltid, men ofta förefaller dessutom mejlen att komma från din egen organisation. "Hur är det möjligt?" kanske du tänker. Det är en mycket rimlig fundering, då skydd för detta har funnits i flera år nu, men väldigt få företag har infört det.

Historik

För att reda ut hur vi hamnade här så behöver vi backa ett antal år, tillbaka till 1982 då Jonathan Postel först skrev det förslag till standard som kom att kallas "Simple Mail Transfer Protocol" eller i korthet, SMTP.

Problemet är att protokollet utformades i en era då Internet var relativt litet och förhållandevis säkert. Det var till och med så säkert, så att en av de första programvarorna som implementerade SMTP protokollet, Eric Allmans Sendmail, hade en bakdörr som gjorde det möjligt för Eric att logga in med högsta möjliga privilegier på den server som körde Sendmail för att kunna hjälpa till vid eventuella problem.

Vad är trasigt med SMTP?

En hel del, med dagens mått mätt. Med mycket begränsad kunskap kan en angripare till exempel:

• Förfalska avsändaren och få mejlet att se ut att komma från vem som helst, exempelvis tomten@tomteland.se eller potus@us.gov.

Redan här är ju det mesta trasigt. Kan jag förfalska avsändaren, på ett sätt att mottagaren inte kan avslöja falsariet, så är ju möjligheterna oändliga som en del skulle säga.

Varför?

Av olika anledningar finns det två ställen där man anger vem som är avsändare av ett mejl, och det behöver inte vara samma. Detta gjordes på grunder som var rimliga 1982, men som leder till en del intressanta bieffekter om det utnyttjas på ett skadligt sätt.

Detta innebär att den som din mejlserver tror att mejlet är ifrån (via något som ibland refereras till som RFC5321.MailFrom) och det som kommer att stå på From: raden i ditt mejl (som kommer via RFC5322.From) inte behöver vara lika.

Liknelsen är att din mobiltelefon får ett samtal från ett vanligt nummer (RFC5321.MailFrom), exempelvis 070-123 456 789, men när du tittar på displayen så står det att det är nödnummret i Sverige, 112, som samtalet kommer ifrån (det sistnämnda sätts i det som kallas RFC5322.From när det gäller mejl).

Mitigerande kontroller

Vad har man då gjort för att försöka komma tillrätta med dessa problem?

Det har under åren rullats ut olika tekniker, som tillsammans, ger ett rätt vettigt skydd för både dig som konsument och för ditt företag eller organisation.

SPF

Först ut var något som kallas "Sender Policy Framework", eller SPF som det vanligen förkortas.

Tanken med SPF är att ett företag eller en organisation kan annonsera till omvärlden vilka mejlservrar som har rätt att skicka mejl som det företaget eller organisationen. Enkelt va?

Om mejlet inte kommer från någon av de utpekade mejlservrarna, så har mottagande mejlserver möjlighet att antingen neka mejlet, sätta det i karantän eller flagga det som möjligt SPAM.

DKIM

Något därefter kom en teknik som kallas "DomainKeys Identified Mail", förkortningen DKIM är dock det som vanligtvis används.

Tanken här är ungefär som ett signerat vykort, känner jag igen signaturen så kan jag på goda grunder anta att vykortet kommer från den som det utger sig att komma från.

DKIM är både en autentiseringmetod för mejl och ett sätt att försäkra sig om att antal signerade delar av mejlet inte har förändrats.

DMARC

Det senaste tillskottet heter DMARC, en förkortning för "Domain-based Message Authentication, Reporting and Conformance" och är egentligen ett sätt för ett företag eller organisation att kunna meddela andra vad man vill att de ska göra, om de får mejl från företaget som bryter mot deras SPF policy (dvs mejlet skickades inte via de utpekade mejlservrarna) eller om det är en trasig eller att DKIM signering saknas helt och hållet.

Policies

De möjligheter som står till buds som DMARC policy är "none", vilket innebär att det berörda bolaget har DMARC i monitorläge (mer om detta nedan), "quarantine" dvs sätt mejlet i karantän, eller "reject", dvs avvisa mejlet om det bryter mot policyn för SPF eller DKIM.

Rapporter

Ytterligare en finess med DMARC är möjligheten att få rapporter, ett företag kan i sin DMARC policy be att få dagliga rapporter på hur mejl som skickas fråm deras domännamn tas emot.

Fungerar som en liten automatiserad visselblåsarfunktion kan man säga, om någon från Brasilien har försökt att skicka ett förfalskat mejl från ditt företag till exempelvis Google, så kommer Google att rapportera detta till dig.

Tips

Ett varningens ord dock, att aktivera DMARC i karantän eller reject läge direkt kan leda till en del oönskade sido-effekter. Framförallt berörs vidarebefodring av mejl och postningar till en del mejlinglistor.

Utrullning i faser

Detta går dock att mildra samt upptäcka i tid, om man genomför en mjuk utrullning av DMARC i 7 faser:

• Fas 1: aktivera DMARC med policyn "none" och minst en rapportmottagare (rua=mailto:ad@res.se)
• Fas 2: Ändra DMARC policyn till "quarantine" på 1% av mejlen (pct=1)
• Fas 3: Ändra DMARC policyn till "quarantine" på 50% av mejlen (pct=50)
• Fas 4: Ändra DMARC policyn till "quarantine" på 100% av mejlen (pct=100)
• Fas 5: Ändra DMARC policyn till "reject" på 1% av mejlen (pct=1)
• Fas 6: Ändra DMARC policyn till "reject" på 50% av mejlen (pct=50)
• Fas 7: Sista fasen, ändra DMARC policyn till "reject" på 100% av mejlen (pct=100)

Under alla faser behöver du monitorera de DMARC rapporter som kommer in för att kontrollera om du behöver justera SPF och/eller DKIM.

Rapporterna kommer in komprimerade i XML-format, så någon form av verktyg kan behövas för att få ut något vettigt av det. Jag kan rekommendera både dmarcian och DMARC Analyzer, som bägge har en gratisversion man kan testa under vissa en tid.

Alternativt körschema enligt RFC 9989

RFC 7489 ersattes av RFC 9989 i maj 2026 och där flyttas pct till "historic state" och ersätts med t=y, så alternativt körschema blir då:

• Fas 1: aktivera DMARC med policyn "none" och minst en rapportmottagare (rua=mailto:ad@res.se)
• Fas 2: Ändra DMARC policyn till "quarantine" (p=quarantine) testläge aktiverat (t=y)
• Fas 3: Ändra DMARC policyn till "reject" (p=reject)

Monitorering

Under alla faser behöver du monitorera de DMARC rapporter som kommer in för att kontrollera om du behöver justera SPF och/eller DKIM.

DMARC kräver inte att både SPF och DKIM passerar.

DMARC godkänns om något av följande villkor är uppfyllt:

• SPF pass + alignment
• DKIM pass + alignment

Ett vanligt SPF pass eller DKIM pass är alltså inte tillräckligt. Den domän som autentiseras måste dessutom vara aligned med domänen i RFC5322.From-huvudet.

Flytta externa parter till separat domän

Ett sista tips avseende DMARC (egentligen SPF). Detta kan vara ett bra läge att flytta eventuella externa parter som används för att göra utskick åt företaget, tex nyhetsbrev eller marknadsundersökningar, till en separat underdomän, exempelvis marketing.domänen.se samt skapa egna SPF och DMARC policies för den nya domänen.

På detta sätt har du dessutom också "städat" upp vilka som får använda ditt övergripande domännamn, vilket minskar dina risker något för obehörigt bruk av ditt huvudsakliga domännamn.

DANE / TLSA

Om du tröttnat på att lita på externa CA:s ska du definitivt studera TLSA (även kallat DANE) som ger dig möjligheten att vara din egen betrodda CA, under förutsättning att du använder DNSSEC för din domän.

Fungerar utmärkt redan idag för SMTP i samband med STARTTLS som beskrivs nedan.

STARTTLS

STARTTLS ger möjlighet att kryptera transporten av mejl mellan mejlservrar, så att ingen kan tjuvlyssna eller förändra mejl du skickar externt.

Sker helt transparent, och oftast helt utan att användaren vet om det. Så även om innehållet i mejlet inte är krypterat med tex PGP eller S/MIME, så skapas en skyddad tunnel mellan mejlservrarna som mejlet transporteras skyddat i.

Med andra ord, mejlen kan gå i klartext internt, fram till den externa mejlservern för att sedan föras över krypterat, och sedan återigen eventuellt transporteras i klartext från mottagande mejlserver till själva mottagaren.

Mer om detta nedan.

Sammanfattning

Vad har dessa tekniker gemensamt?

SPF, DKIM, DMARC, DANE/TLSA och flera andra e-postsäkerhetsmekanismer är beroende av DNS. Om en angripare kan manipulera DNS-svaren kan skyddsmekanismerna också kringgås. Därför bör DNS alltid skyddas med DNSSEC.

Observationer

Trots att vi redan har tekniker som SPF, DKIM, DMARC, DANE, STARTTLS och DNSSEC som gör livet svårare för de som försöker göra livet surt för dig, är det långt ifrån alla företag som använder dem.

Komplexitet

Det tar normalt 2-3 dagar för ett medelstort företag att komma igång med SPF, DKIM, DMARC, DANE, STARTTLS och DNSSEC. Den investeringen i tid, torde skriva av sig rätt snabbt, om det hjälper till att avvärja en enda incident med skadlig kod eller ransomware.

Källor

• SMTP, RFC 5321
• SPF, RFC 7208
• DKIM, RFC 6376
• DMARC, RFC 9989
• DANE för SMTP, RFC 7672
• DNSSEC, RFC 4033, RFC 4034 och RFC 4035
• SMTP STARTTLS, RFC 3207

Se till att mejlen verkligen går krypterat

STARTTLS gör det möjligt för två mejlservrar att kryptera överföringen av ett mejl. Problemet är att STARTTLS traditionellt har varit opportunistiskt: om kryptering inte kan förhandlas fram kan den sändande mejlservern i många fall försöka leverera mejlet ändå, utan TLS.

Det ger ett betydligt bättre skydd än att alltid skicka mejl i klartext, men lämnar samtidigt utrymme för en angripare att försöka ta bort erbjudandet om STARTTLS eller styra trafiken till en annan mejlserver. Den sändande servern kan då ha svårt att avgöra om mottagaren verkligen saknar stöd för TLS eller om någon har manipulerat kommunikationen.

Det finns flera tekniker som stärker SMTP-transporten på olika sätt:

• MTA-STS publicerar en transportpolicy för all inkommande mejl till en domän.
• TLS-RPT ger domänägaren rapporter om lyckade och misslyckade TLS-anslutningar.
• REQUIRETLS låter avsändaren kräva säker TLS-transport för ett enskilt meddelande.
• DANE/TLSA använder DNSSEC och TLSA-poster för att autentisera mottagande mejlservrar.

MTA-STS – en transportpolicy för domänen

MTA-STS, SMTP MTA Strict Transport Security, gör det möjligt för en domänägare att tala om att de mottagande mejlservrarna ska använda TLS, vilka MX-servrar som är tillåtna och att deras TLS-certifikat ska kunna valideras mot den publika certifikatinfrastrukturen.

Om policyn är satt till enforce ska en sändande server som stöder MTA-STS inte leverera mejlet om dessa krav inte kan uppfyllas. MTA-STS definieras i RFC 8461.

MTA-STS består av två delar. Först publiceras en TXT-post i DNS som talar om att domänen använder MTA-STS och identifierar den aktuella versionen av policyn:

_mta-sts.domain.cc. IN TXT "v=STSv1; id=2026073001;"

Själva policyn hämtas därefter via HTTPS från en fast adress:

https://mta-sts.domain.cc/.well-known/mta-sts.txt

Webbservern behöver ett giltigt TLS-certifikat och ska leverera policyn som text/plain. En enkel policy kan se ut så här:

version: STSv1
mode: enforce
mx: mx1.domain.cc
mx: mx2.domain.cc
max_age: 604800

Varje server som förekommer i domänens MX-poster behöver omfattas av en egen mx:-rad eller av ett korrekt wildcard. Namnen i policyn måste motsvara de verkliga MX-värdarna, inte de IP-adresser som de råkar peka på.

Policyn kan använda tre olika lägen:

• testing – fel rapporteras, men mejl ska normalt fortfarande kunna levereras.
• enforce – mejl ska inte levereras om TLS, certifikatet eller MX-servern inte uppfyller policyn.
• none – talar om att en tidigare MTA-STS-policy ska avvecklas.

Det är klokt att börja med testing, kontrollera rapporterna och gå över till enforce först när samtliga MX-servrar har rätt namn, giltiga certifikat och fungerande TLS.

När policyn ändras ska även värdet för id i DNS-posten ändras, så att sändande servrar förstår att deras cachade version behöver hämtas på nytt. Policyns max_age anger hur länge den får sparas av avsändande servrar.

TLS-RPT berättar vad som går fel

TLS-RPT, SMTP TLS Reporting, kompletterar MTA-STS genom att låta andra mejloperatörer skicka sammanställda rapporter om lyckade och misslyckade TLS-anslutningar till domänen.

Rapporterna kan bland annat visa fel vid DNS-uppslagning, STARTTLS-förhandling, certifikatvalidering och kontroll av MTA-STS- eller DANE-policyer. TLS-RPT definieras i RFC 8460.

TLS-RPT aktiveras med en TXT-post under _smtp._tls:

_smtp._tls.domain.cc. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@domain.cc"

Rapporter kan även skickas till en HTTPS-adress. De levereras normalt som JSON-baserade sammanställningar och fungerar ungefär som DMARC:s aggregerade rapporter: de visar vilka system som har försökt leverera mejl, hur många anslutningar som lyckades och vilka typer av fel som uppstod.

TLS-RPT innebär inte i sig att någon leverans stoppas och aktiverar inte heller TLS. Det är ett övervakningsverktyg som gör det möjligt att upptäcka konfigurationsfel och möjliga nedgraderingsförsök.

REQUIRETLS – krav för ett enskilt meddelande

MTA-STS och DANE publicerar transportkrav för all mejl som skickas till en viss mottagardomän. REQUIRETLS fungerar åt andra hållet: avsändaren kan ange att ett visst meddelande endast får skickas vidare över autentiserade och TLS-skyddade SMTP-anslutningar.

REQUIRETLS definieras i RFC 8689 och består huvudsakligen av en SMTP-utökning med EHLO-nyckelordet REQUIRETLS.

Efter att STARTTLS har förhandlats fram annonserar en server med stöd för funktionen exempelvis:

250-STARTTLS
250-REQUIRETLS

När ett meddelande ska omfattas av kravet skickas det med parametern REQUIRETLS på SMTP-kommandot MAIL FROM:

MAIL FROM:<sender@domain.cc> REQUIRETLS

Servern som tar emot meddelandet förbinder sig då att bevara kravet vid fortsatt vidaresändning. Innan meddelandet får överföras måste nästa SMTP-session använda TLS, mottagarserverns identitet måste kunna valideras och nästa server måste själv annonsera stöd för REQUIRETLS.

Om dessa krav inte kan uppfyllas ska meddelandet inte skickas vidare. Resultatet blir i stället en leveransfördröjning eller en studs, beroende på om felet bedöms vara tillfälligt eller permanent.

REQUIRETLS är därför främst användbart när avsändaren hellre accepterar att ett meddelande inte levereras än att det riskerar att transporteras okrypterat eller till en server vars identitet inte kan verifieras.

Det är viktigt att skilja mellan SMTP-parametern REQUIRETLS och meddelandeheadern:

TLS-Required: No

Headern TLS-Required: No betyder inte att TLS krävs. Den har motsatt innebörd och kan användas i särskilda situationer där avsändaren vill att leveransen ska kunna genomföras trots en felaktig MTA-STS- eller DANE-policy, exempelvis för att rapportera att mottagarens TLS-konfiguration är trasig.

Detta bör betraktas som ett undantagsförfarande, inte som en normal inställning för mejltransport.

MTA-STS, REQUIRETLS eller DANE?

Teknikerna löser närliggande men olika problem:

• MTA-STS är mottagardomänens publicerade krav på hur all inkommande mejl ska transporteras.
• DANE är mottagardomänens DNSSEC-skyddade uppgift om vilka certifikat eller nycklar som får användas av dess MX-servrar.
• REQUIRETLS är avsändarens krav på säker transport för ett enskilt meddelande och genom samtliga SMTP-reläer som hanterar det.
• TLS-RPT rapporterar problem med MTA-STS, DANE och den underliggande TLS-transporten.

MTA-STS och DANE kan användas parallellt. En avsändande server som har verifierat en giltig DANE-policy ska inte använda MTA-STS som en väg runt en misslyckad DANE-validering.

REQUIRETLS kan använda både MTA-STS och DNSSEC/DANE för att säkerställa att mottagande server är rätt server och att TLS-sessionen är autentiserad.

Ingen av teknikerna ger end-to-end-kryptering. Mejlets innehåll är fortfarande tillgängligt för de mejlservrar som hanterar det. För information som inte får kunna läsas av mellanliggande eller mottagande mejlsystem krävs innehållskryptering, exempelvis S/MIME eller OpenPGP.

TL;DR: STARTTLS krypterar när det fungerar. MTA-STS och DANE talar om att det måste fungera för en mottagardomän. REQUIRETLS ställer motsvarande krav för ett enskilt meddelande. TLS-RPT berättar när transportskyddet inte fungerar.