När vi kollade med några vanliga ­internetanvändare hur säkert de surfade hade ingen av dem läst avtalen för de webbtjänster de använde och bara några få visste att s:et i https troligen stod för säker. Ingen visste vad ett certifikat egentligen är.
Internetanvändaren tar upp sitt kreditkort och lämnar gladeligen ut kortnummer till diverse webbplatser. En del gör det helt utan urskillning.

De mer vaksamma kontrollerar om sessionen är krypterad, antingen genom att titta efter hänglåset i webb­läsaren eller genom att se efter om det står https i url-fönstret. Frågan är bara hur säkra vi är. Innebär https och hänglås att vi kan lämna ut våra kreditkortsnummer och ­annan viktig information eller att vi på ett säkert sätt kan genomföra våra bankärenden på nätet?

Det finns många sätt att kringgå lösningar med certifikat, som man in the browser-­attacker, olika man in the middle-attacker eller att helt kallt kringgå säkerheten genom att utnyttja att de flesta struntar i varningar om ogiltiga certifikat. Har certifikaten ­kanske till och med spelat ut sin roll?


Enkelt eller dubbelt godkännande
Https visar att sessionen är säkrad med ssl (secure socket layer). Ssl kan användas på många olika sätt, där vissa metoder betraktas som säkrare än andra. Ssl levererar tre säkerhetsmekanismer: identifiering, autenticering och kryptering. Identifieringen och autenticieringen kan vara enkel- eller ömsesidig. Vid enkelsidig identifiering och autenticering har bara en av parterna ett certifikat medan båda har det vid den ömsesidiga identifieringen.


Man in the browser-attack. I den här typen av attack behöver angriparen inte ta hänsyn till vilket servercertifikat som används.

Angriparen kommunicerar eller genomför sin attack via en webbläsarutökning som han har låtit en trojan placera eller ”bett” användaren att installera.



Man in the middle-attack. Här tar angriparen kontroll över kommunikationen mellan användaren och den säkra sajten.

För att angreppet ska lyckas måste angriparen upprätta en session mot den säkra sajten som användare och en session mot användaren som server. Därefter måste angriparen kunna presentera ett servercertifikat av ­något slag. Problemet angriparen har är att dölja att certifikatet är ”felaktigt”.

Ett certifikat innehåller information om ägaren, en publik kryptonyckel, en digital signatur samt information om vem som har gjort den digitala signaturen. I de flesta ­säkra webbtjänster brukar säkerheten bestå i att servern ensidigt identifierar och autenticerar sig mot klienten innan den krypterade sessionen påbörjas. Hur sedan användaren identifierar sig och autenticerar sig mot servern är upp till programmet. Det skapar en lucka i säkerheten.


Gör en dns-kontroll
Vi antar att en webbläsare vill koppla sig till en säker sajt, till exempel en internetbank. Webbläsaren begär först serverns certifikat. Certifikatet innehåller serverns domänadress, giltighetstid, den digitala signaturen och information om vem som har gjort signaturen.

Webbläsaren kontrollerar därefter om domänadressen i certifikatet stämmer med det ip-nummer det hämtades ifrån. Det löser den genom att göra en omvänd dns-uppslagning av ip-adressen och jämföra ­svaret med innehållet i certifikatet. Därefter kontrollerar webbläsaren om certifikatet fortfarande är giltigt och om den kan verifiera signaturen i det. Det kräver att webb­läsare på förhand kommer åt det rootcertifikat som går i god för serverns signatur.

Det finns en mängd rootcertifikat att välja mellan som redan är förinstallerade i klienten/webbläsaren och för det mesta är det här ganska smidigt. De stora företagen har köpt servercertifikat från de certifikatutgivare som de vet finns med i samtliga webbläsare och klientoperativ. Ett exempel på en sådan ut­givare är Verisign.

Eftersom företagets certifikat är dyra väljer dock vissa billigare alternativ. Det innebär att användaren måste ladda ned ett rootcertifikat för att undvika felmeddelanden när han eller hon kopplar sig till den säkra webbplatsen. Ett annat alternativ är att ägaren till webbtjänsten sätter upp en egen certifikatutgivare och låter användarna ladda ned rootcertifikatet från den.


Information skickas krypterad
När webbläsaren har kontrollerat certifikatet etableras en sessionskryptonyckel mellan den och servern och informationen skickas sedan krypterat mellan de två noderna. Syftet med serverns enkelsidiga autenticering och identifiering är att användaren på ett betryggande sätt ska kunna verifiera att han eller hon kommunicerar med den han eller hon ville surfa till.

Användaren kan verifiera detta på ett passivt och ett aktivt sätt. Det passiva sättet innebär att hänglåset kommer upp på skärmen och att url:en i webbläsaren stämmer överens med den sajt som användaren ville surfa till. Det aktiva sättet innebär att användaren verifierar serverns certifikat personligen genom att läsa dess innehåll manuellt och förstår exakt vad signaturernas innebörd betyder. Det sistnämnda innebär att användaren själv måste ta aktiva beslut och veta vad ett säkert servercertifikat är.

Redan för tio år sedan fick man bevis på att ssl inte är den garant för säkerhet man hade hoppats. Många installerar fortfarande i dag sin säkra webbplats på samma server som den ordinarie, osäkra webbplatsen. Årsskiftet 1997/1998 bröt sig några hackare in på First National Bank in Brookings (www.bankeasy.com) vanliga webbsida och kom genom den även åt den säkra webbplatsen. Internetbankkunder kunde då i stället för en inloggningssida hitta reklam för George Foremans Grill. Att servern ­visade ett giltigt certifikat var här ingen ­garanti för att servern skulle vara säker.

Även om servern är säker och certifikatet inköpt från en säker källa (ttp, trusted third party) kan en angripare fortfarande hitta på saker och ting. Det enklaste är en typ av nätfiskeattack där offret blir omdirigerad till en webbsida som tillhör angriparen men som ser likadan ut som den riktiga sidan. Angriparen kan där lura av användare lösenord och kreditkortsnummer. När användaren har matat in informationen visar nätfiske­sidan bara upp ett felmeddelande eller omdirigerar användaren till den riktiga sidan.

Här attackerar angriparen antingen dns (domännamnservern) så att användarna dirigeras till den falska sidan eller sprider ut falska länkar till sidan via e-post eller andra webbsidor. Frågan är om det är nödvändigt för angriparen att ha ett servercertifikat. Merparten av dem som kommer till den ­falska sidan reflekterar inte ens över om sidan är skyddad med ett servercertifikat eller ej.

Den falska sidan kan visas i ett popup-fönster med ett för angriparen giltigt servercertifikat och angriparen kan då lätt ange sin egen domänadress utan att offret märker det, där den falska webbplatsen autenticerar och identifierar sig till webbläsaren. Vissa utländska banker har till exempel gjort det enkelt för angripare genom att placera alla säkerhetsrelevanta sidor i popupfönster, det vill säga fönster utan url-rad. Genom att undersöka certifikatet skulle en person dock kunna upptäcka att han eller hon har kommit till en falsk sajt.


Döljer webbadresserna
En angripare har också andra möjligheter att manipulera det en användare får eller inte får se. Det finns otaliga sätt att maskera url:er så att de ser ut som om de går till en sajt fastän de i själva verket leder till en helt annan. Läs mer om det i rutan till vänster.

Det har hänt att angripare har kunnat köpa giltiga certifikat. Verisign sålde till exempel till privatpersoner två certifikat som om de skulle vara tillhörande Microsoft. Det visar att leverantören av servercertifikat har svårt att ha kontroll över vem de lämnar ut certifikat till. En utländsk leverantör av certifikat har mycket svårare att verifiera äktheten hos en svensk beställning än ett svenskt företag.

Certifikatleverantören begär in skriftliga bevis på att man arbetar på företaget eller begär en firmatecknares underskrift. Leverantörerna ringer ibland upp företaget ifråga för att kontrollera äktheten i beställningen av certifikatet.

Svårigheten är att kunna bestämma om styrkande dokument är äkta, underskriften verkligen tillhör en firmatecknare och den person leverantören ringer upp verkligen är den han eller hon utger sig för att vara. Leverantörerna har ingen vattentät rutin för detta. Ett annat problem är antalet godkända utgivare. Det räcker med att en utgivare gör fel. I Windows XP finns över hundra rootcertifikat. I Windows Vista är antalet förinstallerade rootcertifikat reducerade till ett tjugotal, vilket har förbättrat situationen något.


Kan skapa egna certifikat
En angripare har också möjlighet att skapa egna certifikat. Då visar webbläsaren varningar, men det går att komma runt genom att på den falska sidan ge användarna instruktioner om att installera ett nytt rootcertifikat för att bli av med varningen. I det kan det mycket väl stå att det är Verisign som har utfärdat det.

I stället för att upprätta en nätfiskesajt kan en angripare genomföra en äkta man in the middle-attack, där han eller hon installerar en proxy mellan sig och offret. Den typen av angrepp är gynnsam när webbprogrammet använder engångslösenord genererade av tokens som inte kan återanvändas av angriparen, till exempel digipass, secure id och engångskoder över gsm.

Angriparens attack går ut på att genomföra förändringar i affärslogistiken. Användaren tror att han eller hon har gjort en banktransaktion till ett eget konto men egentligen skickas pengarna till angriparens konto. För att attacken ska verka trovärdig måste angriparen kunna presentera ett fungerande servercertifikat.



Så här såg www.bankeasy.com ut 30/12 1997. Inte ens då kunde man lita på servercertifikat; i stället för en banktjänst möttes man av reklam för George Foremans grill.

En relativt ny variant där angriparen slipper trassel med certifikat är den så kallade man in the browser-attacken. Den bygger på att angriparen lyckas aktivera ett programlager mellan webbläsaren och ssl-sessionen, det vill säga installera en aktiv komponent mellan läsaren och ssl-komponenten. Angriparen gör då attacken i själva webbläsaren.

Här ger inte servercertifikatet någon säkerhet. Svårigheten för angriparen är att installera mellanlagret. Det kan göras med en trojansk häst eller genom att lura användaren till en sajt där han eller hon lockas installera ett tilläggsprogram.


Har certifikat spelat ut sin roll?
Användare kan för lite om certifikat för att kunna lita på det datorn talar om för dem. Felmeddelanden om att sidor är osäkra och farliga är så frekventa att användare inte längre bryr sig om dem. Felmeddelandet ”Du har kommit till en osäker sida, vill du verkligen fortsätta?” tar få notis om, eftersom de ville besöka just den sidan.

Servercertifikat ger en ökad säkerhet för de användare som bryr sig och förstår sig på deras innebörd. Servercertifikat från en giltig trusted third party ger också en liten ­högre tröskel för angripare, vilket gör att de kanske angriper enklare mål.
Störst nytta av servercertifikat har ändå de som äger webbtjänsterna. De kan ge användarna instruktioner i både avtal och på sin hemsida om hur de ska agera vid konstigheter.

Samtidigt är servercertifikatens egentliga syfte att ge webbtjänsternas ägare en möjlighet att lägga ansvaret för säker­heten på sina kunder.