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:
- HTTP
- HTTPS
- TLS
- Certificates
- DANE
- Cookies
- Mixed Content
- Strict Transport Security
- Content Security Policy
- Subresource Integrity
- Referrer Policy
- Permissions Policy
- security.txt
- Frame Options
- Content Type Options
Protokoll
Säker transport
Modernare säkerhetsfunktioner
Applikationssäkerhet
Mejl:
- STARTTLS
- Certificates
- MTA-STS
- TLS-RPT
- DANE
- SPF
- DMARC
Transportskydd (SMTP)
Autentisering och policyer
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 enklast fram via Powershell
Get-DkimSigningConfig -Identity domain.cc | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Och sedan sätts rätt CNAME upp 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.
(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 (Punkt två), 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").
Varför låser du inte dörren?
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.
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 då trasigt med SMTP? Ja, rätt mycket med dagens mått mätt.
Du kan med ytterst sparsamma kunskaper enkelt göra följande:
-
Påstå att mejlet kommer från vem som helst. tomten@tomteland.se, potus@us.gov för att ge ett par exempel.
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.
-
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).
Vad har man då gjort för att försöka komma tillrätta med dessa problem?
Det har under åren rullats ut tre 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.
-
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.
-
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.
-
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.
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.
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.
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.
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.
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)
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 - SPF pass + alignment ELLER DKIM pass + alignment, Det räcker alltså inte med vanlig SPF/DKIM-pass; den autentiserade domänen måste också vara aligned med domänen i RFC5322.From
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.
-
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 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.
Vad har dessa tekniker gemensamt då?
Jo, de bygger till stor del på DNS och kan sålunda sättas ur spel om inte DNS säkras upp med DNSSEC.
Så vad är slutklämmen då?
Jo, 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.
Hur svårt är det?
Inte speciellt svårt, det kanske tar 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.
Så, ryck tag i närmaste tekniker, peka på den här artikeln, och säg "Det är inte så svårt tydligen?" :-)
Så kanske ni också kan få till vettiga skyddsmekanismer, som har funnits ett bra tag nu, för en kommunikationsform från 80:talet som vi förlitar oss på för merparten av vår kommunikation idag.
Lycka till!
Källor
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 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.
SPF
Peter Norin på XPD gjorde i november 2016 en undersökning av bruket av SPF i .se domänen.
Tyvärr var det en smula nedslående resultat.
Av drygt en miljon (968 222 stycken) .SE domäner, hade bara 16% SPF uppsatt.
Och av dessa 16%, drygt 155 000 domäner, som har konfigurerat grundläggande säkerhet för mejl, dvs SPF, så var det bara 40% av dessa, dvs lite drygt 60 000 domäner som hade satt upp SPF på ett korrekt sätt. Detta motsvarar drygt 6% av alla undersökta .se domäner.
Resterande 60% (ca 90 000) hade inte lyckats konfigurera SPF rätt, och därmed helt satt den skyddsmekanismen ur spel.
DMARC
Då mellan 80% och 90% av all skadlig kod som smittar företag och privatpersoner initieras via mail, så gjorde XPD i mars 2021 en undersökning av hur väl DMARC används av samtliga domäner i .se zonen.
En korrekt uppsatt DMARC policy, dvs med en policy antingen satt till "reject" eller "quarantine", ger ett grundläggande skydd mot Whaling och Phishing samt skyddar ens egen domän för missbruk mot 3:e part, exempelvis kunder.
Bara 2.1% av domänerna har satt upp DMARC korrekt, resterande 97.9% av domänerna saknar DMARC och det skydd DMARC erbjuder. (I ärlighetens namn så är detta inte helt rättvisande, då en okänd del av .se-zonen har domäner som är rena skyddsregistreringar, felstavade domäner, mer om det nedan, domäner för privatpersoner med mera och i viss mån saknar behovet av ett gott mailskydd)
Intressant är att nästan hälften av de organisationer som har gjort sig besväret att sätta upp DMARC, har missuppfattat hur DMARC fungerar och har en policy som är satt till "none", vilket effektivt sett innebär att DMARC inte är aktiverat.
Avseende DMARC för myndigheter och företag, så är den rapport som underhålls av Internetstiftelsen som nämns nedan, mer rättvisande, men också lika nedslående, eftersom i snitt endast 10% av de myndigheter och företag som är viktiga för Sverige, har något så grundläggande som DMARC korrekt konfigurerat.
Verktyg
Internetstiftelsen har publicerat en sammanställning på Ivan Ristiks fina site hardenize.com där de för Sverige, viktigaste domänerna (Myndigheter, Banker etc) i .se-zonen kontinuerligt kontrolleras.
Den visar till exempel att endast 10% av dessa, för samhället viktiga domäner, har DMARC korrekt uppsatt. Det finns en del gyllene undantag, exempelvis har Handelsbanken i princip full pott.
Holländska Internet Standards Platform har ett utmärkt och enkelt verktyg för att kontrollera hur väl webb och mail är uppsatt för en domän. Till exempel så har Skatteverket och Frobbit full poäng (100%) för sin respektive uppsättningar. Bra jobbat!
dnstwist är ett mycket trevligt verktyg för att hitta felstavade domäner som Marcin Ulikowski har skrivit, har ni inte provat den på era egna domäner, så bör ni göra det nu innan någon annan, med mindre goda avsikter, gör det.