Jag har länge tänkt skriva om certifikat och vikten av att ha certifikat. Tyvärr måste sägas att det idag är mycket problem med certifikat. Många av dem har sin grund i att det inte är lätt för en helt oinvigd hur idén med certifikat fungerar. Det är heller inte lätt att som webbadministratör förstå hur certifikat fungerar. Mycket har skrivits om hur tekniken bakom certifikat fungerar, men det är svårt att ta till sig. Om jag frågar min mamma om hur hon kan vara säker på att www.hennesbank.se verkligen är den bank som den utger sig att vara, kan hon inte svara. Så länge det är så, finns det stora möjligheter att lura en vanlig användare.
Som av en händelse uppmärksammades inte bara ett, utan två problem med certifikat under veckan som gick. Först ut var problemet med ogiltiga eller felaktiga certifikat. Genom att många webbplatser använder sig av sådana certifikat så lär man upp användarna att slentrianmässigt klicka sig förbi de varningar som webbläsaren slänger upp. Detta kan vara när ett certifikats giltighetstid har gått ut, att certifikatet har flyttats från www.webplats.se till www2.webplats.se istället för att bytas ut, eller att man använder sig av självsignerade certifikat.
Sett ur ett dataintegritetsperspektiv så är det egentligen ingen fara att använda sig av felaktiga certifikat. Datatrafiken krypteras i alla fall och ingen som sniffar trafiken kan läsa vad som sägs. Det stora problemet med detta är att det blir så oerhört enkelt att utföra en man-in-the-middle-attack. Jag sätter upp en webbserver som utger sig föra att vara en annan. Jag skapar ett eget certifikat och styr användarna dit. Eftersom ingen numera höjer på ögonbrynen för en certifikatsvarning så klickar man sig fram på webbsidan och jag som utför attacken kan enkelt avlyssna allt som sägs. Tänk att göra detta och utge sig för att vara bank!
Nu ska det sägas att de nya webbläsarna (Internet Explorer 7 och Firefox 3) på ett mycket tydligare sätt varnar för certifikat som inte stämmer överens med den besökta webbsidan. Det är ett viktigt steg mot en säkrare identifiering av webbservrarna. Men fortfarande är det alldeles för många webbplatser där certifikatsfel genererar en varning och man som användare klickar sig förbi.
Dagen efter flaggades upp för ett annat problem med certifikat. Denna gång handlade det om certifikat som genererats på en Debian-plattform, eller de Linuxdistributioner som härstammar ur Debian, till exempel Ubuntu. Genom slarv av en av programmerarna så togs ett par rader kod bort i den del av programvaran som genererar den slumpmässiga nyckeln. Dessa rader kod hade orsakat varningar vid kompileringen, och istället för att rätta till felet, så togs raderna bort. De såg ändå inte ut att göra något viktigt. Tyvärr visade det sig vid en närmare kontroll att dessa rader kod genererade den grund som används av slumpgeneratorn. Istället för ett väldigt slumpmässigt frö (eng. ‘seed’) användes enbart processens ID som frö. Detta begränsade mängden frön till 32768. Det är idag en enkel match att skapa ett program som under några timmar räknar fram slumptalet ur denna begränsade mängd. Det finns en rad av dessa program ute på nätet som på ett enkelt sätt kan knäcka alla certifikat som tillverkats på en Debian-burk mellan september 2006 och maj 2008. Sådana här fel är det som användare mycket svårt att skydda sig mot. Men det pekar samtidigt på att alla, även programmerare, måste få en större förståelse för dessa digitala identitetskort.
När man har valt att använda certifikat så måste man besluta sig för vilken utfärdare man ska köpa certifikatet från, Certificate Authority eller CA. Enklast är att välja någon CA som redan har sitt root-certifikat installerat med Windows operativsystem (t.ex. Verisign, Thawte, GeoTrust eller DigiCert). Utmaningen i valet av CA består i hur mycket man tror att användarna kommer att lita på det utgivna certifikatet. Skickar jag in en ansökan (d.v.s. en Certificate Signing Request, CSR) till någon seriös utgivare så vet jag att Verisign kontrollerar att jag är jag och att domänen jag försöker få certifikatet till ägs av mig. Det finns också inskrivet i avtalet om eventuell ersättning om en bedragare råkar få ut ett certifikat i mitt namn. Andra CA gör kanske inte alla kontroller som en dyrare utfärdare gör, inte heller utgår ersättning vid ett bedrägeri.
Det är således både användaren som kommer till en HTTPS-webbsida, och du som certifikatsköpare som är intresserad av vem som utfärdat certifikatet. Jag skulle personligen dra mig för att handla på en webbhandelsplats där identiteten sägs vara garanterad av en för mig okänd CA. Å andra sidan så skulle alla certifikatsutgivare vara okända för min mamma som inte alls jobbar inom detta område, vilket göra att hon antingen litar på alla typer av certifikat, eller inga alls; det sistnämnda är dock inte så troligt.
Det måste bli en större medvetenhet om hur man ska använda sig av certifikat, införa certifikat i större utsträckning och underhålla sin certifikatstruktur. Annars kommer konceptet med certifikat att falla samman. De som måste börja med denna uppsträckning är vi som jobbar med IT-säkerhet. Utbilda er i hur certifikat fungerar, vad man kan använda sig av dem och upprätta interna rutiner om hur ni hanterar certifikaten. Ställ egna krav på att era besökare ska känna sig säkra vid besök till er webbplats. Det kommer ni och era webbesökare att tjäna på i längden.
© 2008 Carl Ljungqvist, Certezza AB
Carl Ljungqvist
