Varför e-post är osäker i grunden

Simple Mail Transfer Protocol utformades 1982 för ett litet akademiskt nätverk med ömsesidigt förtroende. Säkerhet var aldrig ett krav: meddelanden skickas i klartext och alla servrar längs vägen kan läsa dem. Årtionden av tillägg har åtgärdat delar av, men aldrig helt löst, denna grundläggande svaghet.

När ett e-postmeddelande skickas går det sällan direkt till mottagaren. Det passerar genom flera Mail Transfer Agents, som var och en identifieras av DNS MX-poster. Varje hopp motsvarar en server som kan logga, kopiera eller ändra meddelandet innan det skickas vidare.

SMTP AUTH låter en e-postklient logga in på en server, men autentiseringsuppgifterna skickas ofta som Base64, vilket är trivialt att avkoda. Utan TLS är hela autentiseringsutbytet synligt i nätverket. Många äldre servrar tillåter fortfarande oautentiserad vidarebefordran från betrodda IP-intervall.

STARTTLS uppgraderar en vanlig SMTP-anslutning till TLS om båda servrarna har stöd för det. Problemet är att uppgraderingen förhandlas i klartext, så en angripare som kan avlyssna trafiken i tysthet kan ta bort STARTTLS-annonseringen och tvinga fram en klartextanslutning. Detta kallas ett STARTTLS-nedgraderingsangrepp.

Varje server som hanterar ett e-postmeddelande lägger till en Received-header med sin IP-adress, programvaruversion och tidsstämpel. Genom att läsa dessa rubriker nedifrån och upp kan meddelandets fullständiga väg spåras, vilket ofta avslöjar avsändarens ursprungliga IP-adress och den interna e-postinfrastrukturen.

DomainKeys Identified Mail lägger till en kryptografisk signatur i utgående e-post, skapad med den sändande domänens privata nyckel. Mottagare verifierar signaturen med hjälp av den publika nyckel som publicerats i DNS. DKIM visar att ett meddelande signerades av den angivna domänen, men krypterar inte brödtexten och förhindrar inte att mellanliggande servrar läser den.

Sender Policy Framework är en DNS TXT-post som listar vilka IP-adresser som får skicka e-post för en domän. När en mottagande server kontrollerar SPF och hittar en obehörig avsändare kan den avvisa eller flagga meddelandet. SPF kan inte ensamt förhindra förfalskning av den synliga From-rubriken som visas för användare.

DMARC bygger vidare på SPF och DKIM genom att ange vad en mottagande server ska göra när kontrollerna misslyckas: ingenting (p=none), placera meddelandet i karantän som skräppost eller avvisa det direkt. DMARC-rapporter gör att domänägare kan se vem som skickar e-post på deras vägnar. Tillsammans utgör SPF, DKIM och DMARC ett lagerbaserat skydd mot förfalskning.

Även när kryptering av e-postmeddelandets brödtext används är metadata fortfarande synliga för alla servrar längs vägen. Servrar måste läsa To-, From- och Subject-rubrikerna för att dirigera och leverera meddelandet. Trafikanalys av enbart metadata kan avslöja relationer, organisationer och kommunikationsmönster utan att innehållet berörs.

Framåtsekretess innebär att tidigare sessioner inte avslöjas om dagens nycklar komprometteras. Vanlig e-post kan inte uppnå detta eftersom meddelanden lagras på servrar med långlivade nycklar. Om en e-postservers privata nyckel någon gång erhålls kan alla tidigare e-postmeddelanden som krypterats för den servern dekrypteras. End-to-end-krypteringsverktyg som PGP krävs för någon form av framåtsekretess i e-post.

E-postens öppna, federerade utformning innebär att ingen enskild organisation kontrollerar alla inblandade servrar. Införandet av säkerhetstillägg som DMARC och MTA-STS är frivilligt och ojämnt. Äldre servrar, felkonfigurerade reläer och organisatorisk tröghet innebär att helt säker e-post kräver medvetna åtgärder på både den sändande och den mottagande sidan.

SMTP byggdes för bekvämlighet, inte säkerhet, och e-postmeddelanden passerar som standard genom flera servrar i klartext. STARTTLS kan nedgraderas, DKIM signerar men krypterar inte, och metadata är alltid synliga. DMARC tillämpar en policy men skyddar inte meddelandets innehåll. Verklig konfidentialitet för e-post kräver end-to-end-krypteringsverktyg som PGP eller S/MIME.