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
