Skyddsmekanismer och hur de fungerar

PGP

PGP står för Pretty Good Privacy och kan skydda innehållet i e-posten med både kryptering och signaturer. Mjukvaran installeras på kli­enten och två användare som båda har PGP kan skicka e-post mel­lan sig utan att någon utomstående kan läsa eller förvanska den. Signaturer tillför non-repudiating, eller icke-förnekande, vilket ska tolkas som att man både kan fastställa vem avsändaren är och veri­fiera att innehållet inte förvanskats. Dessutom är PGP ett uttryck för end-to-end-filosofin för internet, där nätet bara förmedlar det råa meddelandet och alla kontroller och säkerhetsåtgärder görs hos av­sändare och mottagare.

PGP skapades 1991 av amerikanen Philip Zimmerman som en reaktion på ett lagförslag om att kryptoprodukter skulle tvingas ha bakdörrar tillgängliga för amerikanska myndigheter. Kryptopro­dukter betraktades dessutom som krigsmateriel och omgärdades av exportrestriktioner. Det löste Zimmerman genom att bygga PGP med öppen källkod som han sedan publicerade som en bok. Böcker skyddas av tryckfriheten och kan därför exporteras utan påföljd, hävdade Zimmerman. Det gjorde honom till folkhjälte men ledde också till en lång juridisk strid med både myndigheter som hävdade att han bröt mot exportregler och med företaget RSA som hävdade äganderätt till krypteringssystemet han använde. Zimmerman vann till slut men risken för ett långvarigt fängelsestraff hängde över honom under den fleråriga processen.

Nu när nästan två decennier gått sedan kontroversen bröt ut är det inget politiskt ställningstagande att använda PGP och det innebär inga juridiska risker. Men ursprunget i kretsar som misstror myndigheter och företag syns fortfarande i PGP:s uppbyggnad.

PGP använder en kombination av asymmetrisk och symmetrisk kryptering för att skydda innehållet i e-posten och även signera meddelanden. Det är ett vanligt missförstånd att asymmetrisk kryptering har ersatt symmetrisk kryptering. I själva verket lever båda och har hälsan och används parallellt av PGP. Symmetrisk kryptering är effektivt för stora informationsmängder och kan byggas in i hårdvara, medan asymmetrisk kryptering ofta används för att starta kommunikationen och föra över nyckeln för symmetrisk kryptering.

Den asymmetriska krypteringen i PGP använder Diffie-Hellmanalgoritmen. Kärnan i den är att man kan använda en publik nyckel för att kryptera och en privat för att dekryptera, och vice versa för signaturer. Man kan alltså starta en skyddad informationsöverföring med en öppen oskyddad nyckel. Det används i sin tur för att över­föra en tillfällig, symmetrisk så kallad sessionsnyckel som skapas av PGP vid varje tillfälle när e-post ska skickas.

PGP använder en så kallad Web of Trust för att verifiera den publika nyckeln med ett identitetscertifikat. Web of Trust innebär att andra användare, gärna sådana som är relativt kända och har ett gott anseende i internetkretsar, går i god för det egna nycklar. Tanken är att om mottagaren känner igen och litar på en eller flera av de per­soner som går i god för mitt certifikat så kan de även lita på mig som avsändare. Det går även att använda andra sätt att verifiera nycklar, till exempel med en vanlig svensk e-legitimation. Däremot finns det inget standardiserat sätt att använda DNS för att lagra publika nycklar för PGP, vilket av en del uppfattas som en svaghet hos PGP.

PGP är verktyget för individer som vill kryptera sin e-post utan att en IT-avdelning behöver blandas in. PGP ger ett bra skydd men kräver att program installeras hos både avsändare och mottagare, och båda parter behöver vara förhållandevis kunniga och engagerade. En påtaglig nackdel är att om en PGP-användare skickar ett med­delande till någon som inte använder PGP kommer det eventuellt att synas svårbegripliga teckensträngar i meddelandet.

Idag förvaltas PGP som en IETF-standard under namnet Open­PGP och kan laddas ned från http://www.pgpi.org. Det finns även kommersiella tjänster och produkter baserade på PGP från PGP Corporation, se http://www.pgp.com.

TLS

TLS (Transport Layer Security) skyddar mot att FRA eller andra lyssnar på kommunikationen eller förvanskar data på vägen. TLS-protokollet ger konfidentiell kommunikation med hjälp av kryptering. Som namnet säger är det transportlagret, själva kommunikationen på internet, som skyddas. TLS kan endera vara unilateral, där servern autentiseras av klienten medan klienten är anonym mot servern, eller bilateral vilket ger bättre säkerhet. I den senare kan båda ändarna i en kommunikation vara säkra på vem de pratar med.

TLS är liksom PGP en end-to-end-lösning. En skillnad är att TLS-protokollet typiskt införs av IT-avdelningen och är transparent för användaren. Det innebär lägre kompetenskrav för enskilda användare.

TLS används förutom för att skydda e-postprotokollet SMTP även för säker webbtrafik med HTTPS och kan även vara en del i en VPN-lösning. En nackdel med TLS är att till skillnad från till exempel PGP kan inte användaren få bekräftat om meddelandet verkligen var krypterat eller inte.

TLS kan användas med flera olika säkerhetsfunktioner och det förekommer minst tre olika former av handskakning för att initiera förbindelsen.

Säkerhetsarbete är en ständigt pågående katt-och-råtta-lek mellan dem som gör intrång och dem som vill skydda sig. I augusti 2009 upptäcktes ett säkerhetshål som möjliggör en så kallad man-in-the-middle-attack. Sårbarheten finns i ett flertal leverantörers implementation av TLS och visar sig när en TLS-session ska omförhandlas. En angripare som placerar sig mellan en användare och en TLS-skyddad tjänst kan skicka med godtycklig text i en pågående kommunika­tionssession som för användaren till synes är skyddad av TLS. Detta kan utnyttjas för att till exempel injicera en godtycklig HTTP-förfrågan. Angriparen kan dock inte dekryptera själva kommunikationen och ta del av innehållet.

Den snabba lösningen är att stänga av omförhandling av TLS-sessioner medan en långsiktig lösning föreslagits i form striktare regler för hur omförhandling av TLS ska gå till.

En grundlig genomgång av TLS finns på http://en.wikipedia.org/wiki/Transport_Layer_Security.

DKIM

DKIM står för DomainKeys Identified Mail. Det grundläggande syftet med DKIM är att den mottagande parten kan verifiera att den sändande parten verkligen är den som den utger sig för att vara och därigenom öka chansen att meddelandet tar sig genom spamfilter. DKIM skyddar normalt sett information i meddelandets huvud men kan också skydda själva innehållet.

Huvudsyftet med DKIM är att komma tillrätta med spam och phishing som utger sig vara från en legitim avsändare för att lura mottagaren att öppna ett skadligt e-postmeddelande. Det ligger i både mottagarens och den förespeglade avsändarens intresse att av­slöja sådan e-post.

Även DKIM är ett utryck för end-to-end-filosofin som ser internet som ett renodlat transportlager där operatörer i princip inte ska göra någonting med informationen på vägen, bara skicka den från avsändare till mottagare. Men till skillnad från PGP hanteras DKIM typiskt av sändande och mottagande organisationer i stället för på individnivå. Därav domain i namnet. DKIM används inte bara av företag och organisationer med egen e-postserver utan även av stora e-postoperatörer som till exempel Yahoo och Gmail.

E-posten signeras av DKIM med en öppen nyckel som lagras i och hämtas från DNS. Det betyder att ingen extra infrastruktur eller tredjepartstjänst behövs för nyckelhanteringen eftersom DNS redan finns, och alla potentiella avsändare och mottagare finns också där eftersom de har e-postservrar som måste finnas i DNS för att e-posten ska fungera över huvud taget. När ett meddelande ska skickas räknar DKIM ut en checksumma för de delar avsändaren valt att skydda. Checksumman hjälper mottagaren att verifiera att meddelandet inte ändrats.

Det är dock inte ovanligt att något händer på vägen, till exempel att en mellanliggande e-postserver gör en liten förändring i till exempel hur adressen skrivs, vilket gör checksumman felaktig och signaturen blir ogiltig. Dock är det inte självklart att ett sådant meddelande ska kastas, utan felet rapporteras framåt i leveranskedjan och mottagaren får bestämma vad som ska göras med meddelandet.

Det är troligt att sådana oavsiktliga ändringar utan ont uppsåt kommer att minska genom att produktutvecklare och systemadmi­nistratörer blir mer uppmärksamma i takt med att spridningen av DKIM ökar, men för närvarande måste de hanteras. En viktig uppgift för den som sätter upp DKIM är att fastställa regler för hur e-post som saknar signatur eller där signaturen är ogiltig ska hanteras.

DKIM är transparent för enskilda användare eftersom ingenting läggs till själva meddelandet. Signaturen lägger istället till infor­mation i brevhuvudet vilket har två fördelar. De som inte har DKIM ser inga konstiga extratecken i meddelandet och andra signaturer från till exempel PGP påverkas inte.

För att få bästa kompatibilitet med andra skyddstekniker är det lämpligt att signera med DKIM som sista steg innan meddelandet skickas och att validering görs vid mottagandet som första steg eller möjligen andra efter en kontroll mot eventuella svarta listor.

DKIM har en inbyggd begränsning genom att de publika nyck­larna som lagras i DNS inte är skyddade. Det hanteras genom att använda DKIM tillsammans med DNSSEC. I kombination med DNSSEC är DKIM ett robust sätt att verifiera att ett e-postmeddelande verkligen kommer från den avsändare som påstås och att innehållet inte ändrats under överföringen.

Ett intressant specialfall är när någon skickar e-post till en stor organisation och utger sig för att vara från samma domän. Om organisationen bestämt att all e-post signeras och det kommer meddelanden med en intern avsändaradress men som saknar signatur så vet man med säkerhet att det är en attack.

Det är viktigt att förstå att en giltig DKIM-signatur inte i sig är en garanti för att meddelandet inte är spam, eller att avsändardomänen har rent mjöl i påsen. Även spammare kan signera sin e-post och signaturen visar bara att meddelandet kommer från samma domän som signerat det, inte om detta är en god eller ond domän.

En giltig DKIM-signatur visar egentligen bara två saker: Att meddelandet är detsamma som avsändaren signerade eftersom checksumman stämmer, och att den som sköter domänen godkänt signaturen eftersom det finns en valideringsnyckel i domänens DNS.

Det verkliga värdet av DKIM visar sig när man har en ström av signerade meddelanden från samma domän. Om domänen är känd för att signera ”bra” meddelanden, där det är upp till varje mottagare att hitta sin egen definition av vad som är ”bra”, kan man förutsätta att ytterligare ett signerat e-postmeddelande från samma domän även det är ”bra”.

Som avsändare av stora mängder e-post i marknadsföringssyfte kan man anta att DKIM ökar chansen att meddelandena passerar mottagarens filter, men variationen är stor eftersom användaren bestämmer reglerna och även valet av filter påverkar.

Det finns en inbyggd möjlighet att använda mer än en nyckel i en domän. Fördelen med det är att olika avdelningar under en orga­nisations gemensamma domän kan ha sin egen signaturhantering. Det ger också möjlighet att överlåta delar av signaturhanteringen till en tredjepart som arbetar för domäninnehavaren.

DKIM togs fram av ett branschkonsortium 2004 och är idag en IETF-standard. DKIM är tillgängligt för implementation nu och körs på servern utan ingrepp i klienterna. Signering och validering med DKIM kan även outsourcas utan större tekniska problem.

ADSP

ADSP uttyds Author Domain Signing Practices och är ett frivilligt till­lägg till DKIM. ADSP låter en domänägare publicera en policy för hur domänen använder DKIM-signaturer. ADSP kan också infor­mera om vilka rekommendationer avsändaren har om en signatur skulle vara felaktig. En bank eller annan organisation som har högt anseende och skickar mycket e-post kan meddela att den alltid signerar sin e-post. Avsändaren kan även rekommendera mottagaren att kasta meddelandet om det saknar korrekt DKIM-signatur. Om en mottagare då får e-post som utger sig för att komma från banken men som saknar DKIM-signatur kan man utgå från att meddelandet kommer från en falsk källa och att rätt åtgärd är att kasta det.

ADSP använder DNS för att lagra uppgifterna. För att skydda sin ADSP-information i DNS använder man med fördel DNSSEC. ADSP väntas bli en fullvärdig del av DKIM-standarden relativt snart.

SPF

SPF (Sender Policy Framework) bygger liksom ADSP på att avsändar­domänen publicerar uppgifter om hur man skickar e-post på ett sätt som mottagaren kan kontrollera och agera på. Man talar om vilka servrar som ska få skicka e-post och hur det bör tolkas ifall en annan server använts.

En stor del av den illasinnade e-posten har falska avsändar­adresser. Spammare vill undvika e-post som returneras, bedragare vill sopa igen spåren, en mask vill bara skapa förvirring och bryr sig inte om avsändaradresser och de som nätfiskar låtsas vara en be­trodd avsändare för att kunna stjäla inloggningsuppgifter från an­vändare.

De flesta har väl fått meddelanden om att e-post man påstås ha sänt själv inte kommit fram. Det kan vara ett tecken på att någon annan använder ens e-postadress och därmed utnyttjar ens goda rykte.

Precis som de flesta pappersbrev har e-postmeddelanden två adresser. En returadress som i pappersvärlden står på kuvertet, och en header sender address i e-posthuvudet som motsvarar brevhuvudet på det brevpapper som ligger i kuvertet. Det är den senare som syns som avsändare i e-postprogrammen, medan e-postservern normalt bara bryr sig om adressen som står ”på kuvertet”.

SPF skyddar adressen ”på kuvertet”. För att det ska fungera måste ägaren till den sändande domänen publicera sin SPF-information i DNS och mottagaren måste kontrollera att e-postmeddelandet stämmer med de angivna uppgifterna, till exempel vilka e-postservrar som har rätt att skicka från den angivna adressen. Det finns även planer på att framtida versioner av SPF ska kunna specificera andra regler, till exempel att avsändaren signerar med PGP.

De flesta e-postservrar stöder kontroll av SPF, eller kan fås att göra det med tilläggsprogram.

SPF är en IETF-standard. Mer finns att läsa på http://www.openspf.org.

DNSSEC

DNSSEC (DNS Security Extensions) är den säkra varianten av katalog­tjänsten DNS. DNS är en global, hierarkisk men distribuerad katalog som bland annat översätter domännamn till IP-adresser. Flera sätt att kompromettera DNS har varit kända länge, men betraktades som mer eller mindre hypotetiska eftersom konsensus var att det var allför krävande att utnyttja svagheterna. Sedan kom Dan Kaminsky och chockerade världen 2008 genom att visa att det närmast var löjligt enkelt att lura DNS.

Den så kallade Kaminsky-buggen satte fart på säkerhetsarbetet inom DNS och resulterade i ett uppsving för DNSSEC. Sverige har varit och fortsätter vara en drivande kraft i införandet av DNSSEC och IIS har drivit ett pionjärarbete och signerade .se-zonen redan 2005.

Under 2010 kommer mycket att hända och bland annat kommer rotzonen (startpunkten för DNS) införa DNSSEC. Ett antal andra toppdomäner, bland annat .org, .th och .fi är också på väg att införa DNSSEC. Det är mycket troligt att införandet kommer att accelerera betydligt i och med införandet i rot-zonen.

Med DNSSEC kan man lita på översättningen mellan domäner och IP-adresser så att e-posten går dit den ska och att den verkligen kommer från den angivna avsändardomänen. Dessutom får man en säker distributionsmetod för certifikat och nycklar som används av andra säkerhetssystem.

Funktionen i DNS bygger på den hierarkiska strukturen där en nivå hänvisar till närmast lägre nivå tills man hittat den IP-adress som motsvarar ett domännamn. DNS, med eller utan DNSSEC, består av en distribuerad katalog som innehåller de IP-adresser som är de verkliga adresserna bakom URL:er och e-postadresser och annan information. Den del som ställer frågor till DNS-systemet är en pro­gram som kallas resolver. Två svagheter i hur man programmerat re­solvrar utgjorde förutsättningarna för Kaminsky-buggen. Resolvrar är stateless (tillståndslösa på svenska) vilket ska uttydas som att de inte håller reda på om de till exempel ställt en fråga. Det innebär bland annat att man kan skicka svar till en resolver utan att den frågat något och den kommer ändå att agera på svaret. Den andra svagheten är att svarspaketet till resolvern i och för sig innehåller många fält, men tyvärr är de flesta fält i praktiken tomma så det är ändå lätt att gissa vad som ska stå i dem. Det tar bara en bråkdels sekund att skicka ett svar så en angripare kan försöka många gånger utan ansträngning. Detta är något förenklat mekanismen för att lura en användare att använda en falsk IP-adress istället för den som verkligen tillhör en domän.

Med DNSSEC sätter man en signatur på svarspaketet så att mot­tagaren kan se om paketet är äkta eller inte. Säkerhetskedjan bygger bland annat på att närmast högre nivå går i god för underliggande nivå i DNS.

Fullt utbyggt kommer DNS-roten att gå i god för alla toppdomäner som infört DNSSEC, och en hundraprocentig täckning för toppdomänerna är målet. Större organisationer som har många do­mäner under sin huvuddomän kan på motsvarande sätt säkra un­derdomänerna så länge kedjan från toppdomänen är obruten. Det är viktigt med stor täckning eftersom skyddet för en mottagare kräver att avsändaren använder DNSSEC.

En domänägare under toppdomänen .se kan beställa DNSSEC från ett urval av IIS ombud. Startavgiften fastställs av ombudet och varierar.

DNSSEC är en tjänst som inte ställer några särskilda tekniska krav varken hos domännamnsinnehavaren eller hos internetanvän­daren. Dock måste DNS- och resolver-operatören, vanligen ett om­bud eller en internetleverantör, kunna hantera DNSSEC.

Man kan även administrera sin egen DNS men det är då viktigt att ha tillräcklig kompetens även på DNSSEC eftersom misstag i administrationen kan leda till att domännamnet, och därmed både webbplats och e-post, försvinner från internet.

Oavsett om man gör det själv eller outsourcar DNS-hanteringen måste den som administrerar domänens DNSSEC-nycklar ha ett certifikat från en av IIS godkänd certifikatsutfärdare CA (Certificate Authority) för att identifiera sig i användargränssnittet.

Antispam

Det finns ett stort antal kommersiella produkter för att motverka spam, för många för att lista i denna guide. Dessutom förändras fältet hela tiden i försöken att hålla jämna steg med spammarna. Det finns också väl fungerande gratisprogram för att städa bort spammen. Ett sådant öppen källkod-program är SpamAssassin. SpamAssassin sätter liksom de flesta andra alternativen ett betyg på varje e-postmeddelande. Administratören har i förväg bestämt vilka betygsnivåer som gäller för att släppa igenom meddelandet, lägga det i spam-foldern eller ta bort det innan adressaten ser det.

Spam filtreras bort på flera nivåer. Som användare ser man spam­filtret i sitt e-postverktyg men dessförinnan har företagets e-post­server sorterat bort spam och om man är kund hos en internetoperatör så har denne tagit bort det värsta skräpet redan innan e-posten når företagets e-postserver.

Det finns olika åsikter om var spamfiltreringen bör ligga. Många är glada och nöjda nu när operatörerna har blivit mycket bättre på att filtrera och släpper igenom allt mindre spam trots att volymen faktiskt ökar därute. Andra anser att det sanna internet ska vara en öppen kanal från punkt till punkt och att operatörerna ska göra så lite som möjligt. Filosofiskt är det lätt att hålla med om att kända och okända aktörer ska göra så lite som möjligt med den informa­tion de förmedlar och att sändare och mottagare ska få göra sina egna val. Men i praktiken tycker många att det är bra att slippa grovjobbet. Ytterligare en skola väljer att skicka företagets inkommande e-post på spamtvättning hos något fristående företag som erbjuder den tjänsten.

Om man väljer att sätta sin e-postserver direkt på internet utan att utnyttja en tjänsteoperatör tvingas man själv ta ansvar för sin spamfiltrering. Även i andra änden av spektrumet måste man ta ställning, eftersom en outsourcingpartner som tvättar e-post har svårt att dra en skarp gräns mellan legitim e-post och sådant som ska kastas. Det som hamnar i gråzonen kanske man ändå måste ta ställning till hos mottagaren.

Oavsett vilket antispam-program man väljer fungerar de snarlikt.

Första steget är ofta att kontrollera mot en eller flera kända svarta listor. Dessa listor uppdateras i realtid när någon domän plötsligt börjar skicka stora mängder suspekt e-post. Genom att kolla mot en eller flera sådana listor kan man sortera bort det värsta. En annan åtgärd som är vanlig på företag som tar emot stora mängder e-post är att jämföra med tidigare e-post. Om man aldrig tidigare fått med­delanden från avsändaren släpper man inte igenom meddelandet direkt, så kallad grålistning. Om det är en spammare är det troligt att de inte försöker igen, men om det är en legitim avsändare kommer den skickande e-postservern att försöka igen och först då tittar man på meddelandet hos mottagaren. Man kan även upprätta vitlistor, som helt enkelt är listor med avsändare man litar på.

När sedan själva spamfiltret går igång tittar det på ett antal faktorer som viktas olika. Resultatet blir ett betyg i form av en siffra, och förutbestämda regler säger om betyget är tillräckligt bra för att ta emot e-posten, lägga det i spamfoldern eller kasta det innan någon får möjlighet att öppna det. Exakt vad som betygsätts och hur vikt­ningen ser ut vill man inte avslöja för spammare men man vet att det är en variation på känt tema.

Signaturer och certifikat (PGP, DKIM, ADSP, SPF) enligt den tidigare genomgången är bra, vissa avsändarländer är dåligt, länkar är dåligt, vissa ord och mönster i innehållet är dåligt, bilagor med exekverbar kod är dåligt och så vidare.