EXTRA INFORMATIONSSÄKERHETSÖVERSIKT 3b/2011 28.11.2011 Brister i certifikatsystem 1
CERT-FI:s 3b/2011 informationssäkerhetsöversikt Brister i certifikatsystem Denna extra CERT-FI-informationssäkerhetsöversikt handlar om brister som upptäckts i certifikatsystemen och kränkningar av informationssäkerheten som riktats mot leverantörer av certifikattjänster. Översikten kompletterar innehållet i informationssäkerhetsöversikten 3/2011. Artikeln innehåller rekommenderade åtgärder och förfaranden för slutanvändare, dataadministratörer och applikationsutvecklare genom vilka man kan garantera sin egen och utomståendes informationssäkerhet. Certifikatsystemets säkerhet är hotad Flera företag som beviljar servercertifikat har under innevarande år blivit offer för dataintrång eller föremål för försök till dataintrång. Användarbehörigheter som inkräktarna kommit över har använts för att skapa servercertifikat i tredje parters såsom Googles namn. Inga säkra uppgifter finns om användningssyftet för de falska certifikaten. Det har spekulerats att vissa statliga säkerhetsorgan varit inblandademan har även tidigare kunnat visa på brister i anslutning till certifikatsystemets teknik och process. De som tillhandahåller certifikattjänster har certifierat servercertifikat utan att reda ut sökandens verkliga identitet och ställning. Kontrollen av certifikatens giltighet och makuleringen av dem fungerar inte tillförlitligt, vilket orsakar problem då certifikatens nyckelpar hamnar i utomståendes händer. Operativsystemen och applikationerna stöder sig på ett stort antal rotcertifierare som antas vara tillförlitliga även om största delen av användarna aldrig behöver certifikat som beviljats av dem. I praktiken har det visat sig att alla certifierare inte är värda förtroendet. Det finns inga säkra tekniska metoder för att avbryta förtroenderelationen. Händelserna under det gångna året har avslöjat problemen på ett allmänt plan. Svagheterna i systemet har utnyttjats systematiskt, och informationssäkerheten för ett stort antal användare har äventyrats. Det skydd som certifikaten ger är ofullständigt i sin nuvarande form, och inga betydande förbättringar är i sikte utan en genomgripande ändring av hela certifikatsystemet. I detta dokument går vi igenom kränkningar av och hot mot informationssäkerheten som blivit offentliga samt ger råd med vars hjälp användare, dataadministratörer och applikationsutvecklare kan utnyttja säkerhetsegenskaperna hos det existerande certifikatsystemet för att skydda sina miljöer. 2
Fallet ComodoHacker År 2011 gjordes flera lyckade dataintrång mot företag som beviljar certifikat. Det som är gemensamt för fallen är att gärningsmannen strävat efter att skapa äkta servercertifikat åt sig. I en del fall har inkräktaren lyckats med detta till och med utan att bli avslöjad. Gärningsmännen och uppdragsgivarna är inte kända. En hackare som använder signaturen ComodoHacker har offentligt meddelat sig stå bakom gärningarna. Parten bakom signaturen har motiverat sina gärningar med att påstå sig ha agerat för regimen i Iran mot oroligheterna under arabvåren. Det finns inga uppgifter om signaturens identitet eller nationalitet. Det är också oklart om signaturen står för en enskild person eller en grupp. Det första intrånget som allmänheten fick kännedom om riktade sig mot den amerikanska rotcertifieraren Comodo. Den 23 mars 2011 publicerade bolaget ett meddelande om att lösenorden som tillhörde en person som arbetade för en underleverantör hamnat i utomståendes händer. Med hjälp av lösenorden skapades nio servercertifikat, bland annat för adresserna www.google.com och login.skype.com. Företaget upptäckte intrånget inom några timmar och makulerade de falska certifikaten. Eftersom makuleringen av certifikat inte nödvändigtvis förhindrar missbruk, gav de viktigaste programvaruleverantörerna såsom Microsoft och Mozilla snabbt ut uppdaterade programversioner genom vilka användningen av de otillförlitliga certifikaten stoppades. I mitten av juni 2011 gjordes ett dataintrångsförsök mot den israeliska certifieraren StartSSL. Inkräktaren försökte komma över certifikat beviljade av certifieraren till andra tjänster såsom i de andra attackerna. Enligt StartSSL misslyckades dock försöket. I slutet av augusti avslöjades det att man i samband med dataintrånget i det nederländska företaget DigiNotar hade lyckats skapa certifikat som verkade äkta för alla Googles tjänster. Fallet uppdagades den 28 augusti då en iransk användare skickade en felbeskrivning av webbläsaren Chromes konstiga beteende till ett supportforum. Det visade sig att den iranska operatören Pars Online omdirigerade trafiken till Googles servrar till förmedlarservrar som verkade ha äkta servercertifikat beviljade av DigiNotar. Fallet avslöjades eftersom Googles webbläsare Chrome larmar om servercertifikatet beviljats av en certifierare som Google inte fastställt i förväg. DigiNotar fanns inte på Googles lista över certifierare. DigiNotars system hade beviljat certifikatet redan den 10 juli 2011, och således hade dataintrånget inträffat minst en och en halv månad tidigare. DigiNotar medgav fallet först efter att bolaget utsatts för press i offentligheten. Senare framgick det att bolaget aktivt försökt dölja det inträffade. Den säkerhetskartläggning som de nederländska myndigheterna beordrade avslöjade allvarliga brister i certifierarens informationssäkerhetspraxis. Det är oklart hur DigiNotar tidigare hade lyckats vilseleda informationssäkerhetsinspektörerna. DigiNotar hade kommit med på webbläsartillverkarnas lista över tillförlitliga certifierare efter att bolaget godkänts i en revision som utfördes av ett respekterat konsultföretag i branschen. Landets myndigheter har sedermera tagit över DigiNotars certifikatverksamhet och annullerat dess certifikat. Det amerikanska bolaget Vasco som köpte DigiNotar i januari 2011 lämnade in konkursansökan för bolaget knappt en månad efter att dataintrången avslöjats. Såsom i fallet Comodo förutsatte även makuleringen av DigiNotars certifikat reaktioner från programvaruleverantörernas sida. Det finns inga egentliga förfaranden för ogiltigförklarande av rotcertifierare inom själva certifikatsystemet. Misstankarna om dataintrång i certifieraren GlobalSign avslöjades den 5 september 2011, då signaturen ComodoHacker som gjort de tidigare dataintrången öppet 3
skröt om saken. Beviljandet av Global- Sign-certifikat avbröts temporärt. Undersökningarna visade att man endast lyckats bryta sig in i företagets www-servrar. Beviljandet av certifikat fortsatte efter några dagar 13.9.2011 då utredningen var klar. Äldre fall Brister i certifikatsystemens processer har även tidigare utnyttjats i identitetsbedrägerier. År 2008 kunde till exempel en informationssäkerhetsforskare komma över Live.com-certifikat från Thawte. Nyare fall Efter fallet ComodoHacker har två nya informationssäkerhetsproblem i anslutning till certifierare avslöjats. Den 3 november 2011 upptäckte man att Entrusts underleverantör DigiCert Malaysia hade beviljat 22 certifikat i vilka man använt nycklar på 512 bitar som anses vara osäkra. Det fanns ingen information om certifikatets makuleringstjänst eller användningssyfte i certifikaten. Det finns inga bevis på att certifikaten skulle ha använts i bedräglig verksamhet eller erhållits bedrägligt. Digi- Cert Malaysias certifikat har raderats från webbläsarnas listor över rotcertifikat. Ytterligare förvirring orsakades av att det på listan över rotcertifikat finns en betydande amerikansk försäljare av certifikat med samma namn. mekanismer för makulering av rotcertifikat kan problem åtgärdas med programuppdateringar där otillförlitliga certifikat raderas. Programuppdateringar kan dock dröja avsevärt både vad gäller publiceringen av dem och installationen av dem i systemen. I praktiken hinner gärningsmannen utnyttja falska certifikat rätt länge. Riskerna med certifikatsystemet var allmänt kända bland informationssäkerhetsaktörerna redan före fallet Comodo. Det fanns emellertid inga alternativ för systemet i praktiken. Såsom i fråga om flera andra tekniker har användningen av X.509-certifikat och protokollet SSL/TLS (Secure Sockets Layer, nyare beteckning Transport Layer Security) blivit mycket vanligare än vad man föreställde sig när standarderna skapades. Protokoll har införts i flera nya applikationer. Nuvarande betydande hot har inte beaktats tillräckligt i planeringen. KPN-operatörens certifikattjänst avbröt temporärt försäljningen av certifikat den 4 november 2011, då man i samband med en revision upptäckte ett verktyg för blockeringsattacker i företagets wwwserver. Intrånget kan ha inträffat rentav fyra år tidigare. Enligt nuvarande uppgifter har man inte kommit åt själva certifikatsystemen. Åtgärder till följd av fallen I fallet Comodo och DigiNotar publicerade största delen av webbläsar- och operativsystemtillverkarna snabbt uppdateringar där de otillförlitliga rotcertifikaten raderats. I fallet DigiNotar åtgärdades problemen något snabbare än i fallet Comodo. Uppdateringarna var klara 2 8 dagar efter att dataintrången kommit till allmän kännedom. Även om det inte finns egentliga 4
Hur används certifikat? Med hjälp av certifikat kan användaren försäkra sig om att webbtjänsterna tillhandahålls av den instans som den påstår sig vara. Certifikat används också för att verifiera programvarans äkthet och för att identifiera användare. Certifikat beviljas av tillförlitliga certifierare (Certificate Authority, CA). Normalt bildar man en hierarki av certifikaten där man med rotcertifikat på den högsta nivån signerar undercertifierarnas certifikat, som i sin tur signerar de beviljade certifikaten. Grenarna i certifikatträdet är separata, och makuleringen av en förgrening, dvs. undercertifieraren och nedanstående certifikat inverkar således inte på de andra förgreningarna. Till exempel certifikat för www-sidor innehåller information om den certifierade webbplatsens domännamn, olika slags uppgifter om den instans för vilken certifikatet beviljats, certifikatets certifierarspecifika serienummer, giltighetstid, information om spärrlistan över certifierarens certifikat (CRL, Certificate Revocation List) och kontrolltjänsten för certifikatets status (Online Certificate Status Protocol, OCSP), certifikatets beviljare, offentliga nyckel och olika användningssyften för certifikatet. Användningssyften för certifikaten kan förutom enskilda domännamn också bland annat vara subdomäner, e-postadresser eller programvaruutvecklare. Operativsystem och även i vissa fall webbläsare har inbyggda listor över tillförlitliga rotcertifikat. Webbläsaren uppfattar sidspecifika certifikat som beviljats av dessa instanser som tillförlitliga. Certifikaten används i bland annat krypterade SSL/TLSdatakommunikationsförbindelser (HTTPS). Om webbplatsens certifikat inte finns på listan över rotcertifierare eller om det inte signerats med nyckeln till detta certifikat varnar webbläsaren användaren om sidan. Vad möjliggjorde attackerna? Varje rotcertifikat duger som signerare av certifikaten för alla webbplatser: rotcertifikaten har ingen inbördes hierarki. Även om tjänsteleverantören skaffat certifikatet från en viss certifierare, är vilket som helst certifikat som beviljats av en tillförlitlig certifierare likvärt med det rätta certifikatet. Den mest sårbara certifikatbeviljarens informationssäkerhet är avgörande. Ändringen av certifikat följs inte i allmänhet upp i webbläsarna eller centraliserat. DigiNotar-fallet upptäcktes endast med Googles webbläsare Chrome, där endast vissa certifierare godkändes som certifikatbeviljare för Googles egna webbplatser. I planeringen av hierarkin har man inte beaktat situationer där den högsta nivån i hierarkin, dvs. rotcertifieraren blir otillförlitlig. Till exempel funktionen med spärrlistor kan endast användas för att makulera certifikat som signerats av rotcertifieraren. I praktiken omfattar beviljandet av certifikat förutom certifikatbeviljare dessutom registrerare (Registration Authority, RA) samt certifikatåterförsäljare och - underleverantörer, vilket gör situationen mer komplicerad. I praktiken finns det inga begränsningar för vilka certifikat registrerarna och underleverantörerna får publicera, även om detta enligt definitionerna vore möjligt. I till exempel fallet Comodo som togs upp i inledningen beviljades de otillåtna certifikaten av en underleverantör. Attackerarnas motiv Med ett falskt certifikat kan man utföra en attack av typen man-in-the-middle (MiTM) och överta förbindelsen mellan en tjänst och dess användare. Ett annat sätt där förfalskade certifikat används i bedrägerier är att utnyttja en webbplats som attackeraren skapat för att till exempel komma över användarnamn och lösenord. Användare av webbtjänster kan även utsättas för attacker genom att förvränga namntjänstuppgifter om en del av webbplatsen laddas ner från en tredje parts webbplats. Många webbplatser laddar ner material från tredje parters webbplatser såsom annonser eller användarnas statistiktjänster, till exempel Googles Analytics-tjänst (https://googleanalytics.com/). Genomförandet av en MitM-attack förutsätter att attackeraren kontrollerar antingen hela webbinfrastrukturen eller namnservern, eller att attackeraren är i samma lokalnät som offret. Till exempel öppna WLAN-nät medför många möjlighe- 5
ter att genomföra MitM-attacker. I både Comodo- och DigiNotar-fallet har man spekulerat om att de beviljade certifikaten skulle ha använts för att spionera på iranska användares e-post. Utmaningar för certifikatsystemen För närvarande finns det sådana gamla rotcertifikat i behållare av rotcertifikat i vilka man använder korta nycklar och osäkra algoritmer samt certifikat med en mycket lång giltighetstid. Rotcertifikat som upptagits på listor över tillförlitliga certifikat och HSM-säkerhetsmoduler (High Security Module) som innehåller certifierares hemliga nycklar är eftertraktade handelsvaror bland certifierare eftersom det är svårt att komma med på listorna. Leverantörer av webbläsare och operativsystem har fastställt exakta kriterier för certifierare som vill komma med på listorna över rotcertifierare. Enligt kraven ska man försäkra sig om de använda systemens säkerhet bland annat med hjälp av säkerhetsrevisioner. Detta hjälpte dock inte i fallet DigiNotar. Enligt rapporterna om intrånget var företagets säkerhetsarrangemang helt klart otillräckliga även om företaget fick godkänt i revisionen. Största delen av certifikaten för webbplatser är signerade av cirka tjugo certifierare. Antalet rotcertifikat som finns i webbläsare och operativsystem är mångfaldigt. Här finns bland annat lokalt utnyttjade certifierare som merparten av användarna aldrig antagligen behöver. Certifikaten i den så kallade omfattande valideringen (Extended Validation, EV) har aldrig uppnått större popularitet. Enligt certifierarna är EV-certifikaten mycket säkra, eftersom man vid beviljandet av dem strävar efter att kontrollera sökandens rätt till certifikatet extra noga. Användarna är emellertid inte medvetna om skillnaden mellan EV-certifikat och vanliga certifikat. I applikationer är det inte möjligt att rata icke EV-certifikat, och detta vore inte heller förnuftigt med tanke på marknadsläget. I praktiken är det bara en marknadsföringsmetod för dyrare certifikat. Även DigiNotar och Comodo sålde EVcertifikat. Försäljning av EV-certifikat är 6 således ingen garanti för att certifierarens informationssäkerhet är i skick. Att förstå sig på X.509-certifikatens funktion kräver en hel del även av experter. I applikationer för allmänheten, såsom webbläsare, har man gjort uppenbara misstag i hanteringen av certifikaten. Dessa misstag har man för att garantera kompabiliteten varit tvungen att upprepa även i nya applikationer och certifikat. Dessutom lagras certifikat i webbläsarnas cacheminne för att applikationen ska fungera snabbare, vilket kan förlänga användningen av makulerade certifikat. Rekommendationer för dataadministrationen Gå igenom de rotcertifikat som användarna i din organisation behöver. Ta inte automatiskt i bruk alla de certifikat som följer med operativsystem och webbläsare. Lägg endast till de rotcertifikat som behövs i objekt som kräver särskilt skydd. Informera användarna då certifikat för särskilt skyddade webbplatser ändras. Försäkra dig om att osäkra algoritmer som enligt rekommendationer borde raderas från listan över godkända algoritmer inte används. Bedöm certifierarens tillförlitlighet när du skaffar certifikat. Det billigaste certifikatet kan orsaka extra kostnader i framtiden. Det kostar att upprätthålla ett informationssäkert och tillförlitligt eget certifikatsystem. Använd inte certifikat vars certifierare inte hör till de tillförlitliga i användarnas system. Förnya certifikaten innan de går ut. På detta sätt undviker du att dina användare lär sig kringgå meddelanden om certifikatfel. Fundera ut i förväg vad du ska göra om beviljaren av certifikat för dina webbplatser blir offer för data-
intrång så att dess rotcertifikat makuleras. Rekommendationer för användare Använd webbläsarens avancerade säkerhetsegenskaper. Kringgå inte felmeddelanden om certifikat utan att reda ut orsaken. Uppdatera operativsystemet och webbläsaren. Var alert och notera om du plötsligt förflyttas till exempel till en okrypterad webbplats. Rekommendationer för applikationsutvecklare Applikationen får inte fungera så att aktiviteten fortsätter utan att underrätta användaren om kontrollen av certifikatet misslyckas. Bekanta dig med certifikatens funktionsprinciper innan du förverkligar applikationen. Kontrollera att certifikatens certifikatkedjor är korrekt kopplade ända till rotcertifieraren. Kontrollera i synnerhet Basic Constraintsexpansionen för alla certifikat i kedjan. Aktivera funktionerna för spärrlistan. Sträva efter en bra balans mellan informationssäkerheten och de meddelanden om certifikatfel som visas för användaren. Fäst särskild uppmärksamhet vid att webbläsarnas användargränssnitt visar fel och observationer i anslutning till certifikat för användaren på ett tydligt sätt. Förhindra att användaren luras med hjälp av fel i webbläsaren. I flera applikationer kan användaren inte själv påverka tillförlitliga rotcertifikat. En medveten användare erbjuds inte möjlighet att förbättra sin informationssäkerhet. I uppdateringsmekanismer borde man överväga att definiera godkända certifierare inom applikationen. Användningssyftena för certifikaten ska beaktas i praktiken. Utvecklingsutsikter Användarna litar på applikationstillverkarnas och operativsystemens bedömningar av säkra rotcertifierare. Raderandet av rotcertifikat som förlorat förtroendet måste ske snabbare än i dag. Det vore bra om webbläsarna använde det centraliserade certifikatregistret i operativsystemet, eftersom användaren då skulle klara sig med en uppdatering. Användarna borde erbjudas verktyg med vilka de lätt kan undersöka, jämföra och redigera rotcertifikatlistor för olika applikationer och operativsystemet. Hela certifikatsystemet bygger på förtroende, och därför är det viktigt att certifierare agerar ansvarsfullt vid misstankar om intrång och att de aktivt informerar om attacker och deras konsekvenser. I sista hand minskar detta också de ekonomiska förluster som företagen orsakas. Comodo, som agerade ansvarsfullt, fortsätter verksamheten medan DigiNotar försattes i konkurs. Skyldigheten att informera kunderna om dataintrång skulle vara en sporre för att förbättra säkerheten. En ökning av själv signerade certifikat skulle leda till att användarna tröttnade på meddelandena om certifikatfel. Organisationer med stora system kan ha resurser för att skapa egna säkra certifikat och säkerställa att användarna lägger till organisationens rotcertifikat på listan över tillförlitliga certifierare. Mindre aktörer saknar ofta resurser och kompetens för att upprätthålla ett informationssäkert certifikatsystem. I framtiden kommer man att i allt högre grad använda certifikat även för att säkerställa tillförlitligheten hos körbara applikationer. Utöver i operativsystemen Windows Vista och Windows 7 används validering i alla plattformar för datormobiler. Då måste även programvaruleverantörerna satsa på informationssäkerheten hos certifikat 7
som används för att signera applikationerna. Signerade skadliga program har redan använts i flera attacker, bland annat i fallet Stuxnet som fått stor publicitet. I skadliga program som stjäl information har man hittat komponenter som söker efter certifikat och därmed anslutna krypteringsnycklar i systemet. Det har också förekommit fall där skadliga program lagt till skadlig programkod i programutvecklarnas system. Nya informationssäkerhetsegenskaper i anslutning till certifikat lanseras för webbläsare åtminstone som tilläggsdelar. Google har lanserat nya informationssäkerhetsegenskaper för bland annat webbläsaren Chrome, vilket sätter press på andra leverantörer av webbläsare. SSL/TLSkrypterade webbplatser används i allt högre grad även med mobiltelefoner. Att uppdatera mobilutrustning är mycket besvärligare för användaren än att uppdatera datorn, och uppdateringar lanseras inte tillräckligt snabbt. Den vanligaste versionen av SSL/TLSprotokollet är i dag version TLS 1.0, vars informationssäkerhetsnivå ifrågasatts under de senaste åren. Inte ens säkra certifikat kan skydda ett osäkert överföringsprotokoll. Att ta i bruk nyare TLSversioner blir antagligen nödvändigt förr eller senare, men lanseringen av krypteringsbibliotek som stöder dem kräver investeringar av leverantörer av både server- och klientprogram. Utvecklare som aktiverats av problemen i certifikatsystemet har föreslagit flera nya informationssäkerhetslösningar. En del av dem har ännu inte fått etablerade namn. Sannolikt kommer man att ta i bruk flera lösningar eftersom de inte ger skydd mot samma hot. Det är önskvärt att lösningarna inte kräver stor sakkännedom av användarna utan att de också ska skydda så kallade vanliga användare. Risken är att lösningarna gör det redan nu komplicerade certifikatsystemet ännu mer komplicerat. Lösningar som baserar sig på namnserveruppgifter: Namntjänstposten DNS Certification Authority Authorization (CAA) för anslutning av information om de rotcertifikat som får bevilja certifikat för ifrågavarande webbadress till DNS. Anslutning av DNSSEC-kedjan till webbplatsens certifikat Namntjänstposten DNS TLSA för inkludering av koden för servercertifikatet i webbadressens namntjänstuppgifter De två senare lösningarna som bygger på namnserveruppgifter förutsätter säkerhetsexpansionen DNSSEC för DNSnamntjänsten. En strikt integration endast med DNSSEC-certifikat är inte helt problemfri, eftersom makten att besluta om tillförlitliga certifierare övergår från tjänstens administratör och användare till beviljaren av domännamn. Lösningar för tjänsteleverantörer: HTTP Strict Transport Security (HSTS): en rutin där webbtjänsten kan meddela servern att endast krypterad trafik ska tillåtas till den. OCSP Pinning eller Certificate Status Request: en rutin där webbtjänsten kontrollerar status för sitt eget certifikat och returnerar den till webbläsaren med den övriga responsen. Lösningar för applikationsleverantörer: Certificate pinning eller domain pinning: endast vissa certifierare godkänns som beviljare av certifikat för en viss tjänst. Lokalisering av listor över rotcertifikat: listan över rotcertifikat innehåller endast de vanligaste och mest använda lokala rotcertifikaten. Centraliserade lösningar: Convergence: en teknologi som utvecklats av SSL/TLS-forskare Moxie Marlinspike där certifikatets tillförlitlighet kontrolleras med pålitliga instanser, dvs. så kallade 8
notarier. Det är fritt fram att grunda ett notariat: användarna av systemet avgör vilka notarier de litar på. Meta CA: ett meta-ca som ersätter webbläsar- och operativsystemtillverkarnas listor över rotcertifikat och som dessa litar på. Centraliserat certifikatregister: olika slags centraliserade certifikatregister med vilka man kan jämföra det certifikat som webbtjänsten använder, till exempel Google, Tor och EFF SSL Observatory. Funktionerna i olika scenarier jämförs i tabell 1. Scenarierna omfattar inte fall där användarens terminal smittats av ett skadligt program. I tabellen beaktas inte heller sådana situationer där attackeraren kan mata in eget innehåll i SSLförbindelsen, till exempel genom att utnyttja XSS-sårbarheter på webbplatsen eller genom intrång på den använda webbtjänsten. 9
Tabell 1. Skydd som existerande och föreslagna säkerhetsfunktioner erbjuder i olika situationer. Teknologi Vilseledande av certifikatbeviljare med felaktig information Besök på httpskrypterad webbplats för första gången Besök på httpskrypterad webbplats för andra gången Ändring av httpsprotokoll till httpprotokoll Annan man-inthemiddleattack Nätfiske med hjälp av SSLskyddad webbplats 1) Avslöjande av certifikatets nyckelpar för utomstående Intrång i certifierarens system Spärrlistor (CRL) Nej Ja Ja Nej Nej Nej Ja Nej Nej OSCP Nej Ja Ja Nej Nej Nej Ja Nej Nej EV-certifikat Ja Nej Nej Nej Nej Nej Nej Nej Nej DNS CAA RR a) Ja Nej Nej Nej Nej Nej Nej Nej Nej HSTS OSCP Pinning DNS CAA RR a) Nej 2) DNSSEC-kedja i certifikat a) Certificate pinning Bedräglig certifierare Observationer Nej Nej Nej Ja Nej Nej Nej Nej Nej Denna gång endast genomförd i webbläsaren Firefox Nej Ja Ja Nej Ja Nej Ja Nej Nej Möjligt att återanvända respons. 2) Nej Ja Ja Nej Ja Ja Nej 2) Nej 2) Nej 2) En del av säkerhetsgarantierna genomförs av DNSSEC Ja Ja Nej Ja Ja Nej 2) Nej 2) Nej 2) En del av säkerhetsgarantierna genomförs av DNSSEC Nej Ja Ja Nej Ja Ja Nej Ja Nej Icke skalbar, används i webbläsarna Windows Update, Googles webbplatser Convergence Nej Ja Ja Nej Ja Ja Nej Nej Ja Meta CA a) behöver inte längre Nej Ja Ja Nej Nej Ja Nej Ja Nej Webbläsartillverkarna upprätthålla listor Centraliserat certifikatregister Nej Ja Ja Nej Ja Ja Nej Ja Ja a) Inte ännu i bruk 1) Webbplatsen försöker vilseleda användaren med hjälp av en adress som påminner om den riktiga webbplatsens adress. 2) Å andra sidan kan DNSSEC hjälpa 10
Information om fallen Diginotar: http://www.cert.fi/tietoturvanyt/2011/08/ttn201108301049.html 30.8.2011 http://www.cert.fi/tietoturvanyt/2011/09/ttn201109060736.html 6.9.2011 http://www.cert.fi/tietoturvanyt/2011/09/ttn201109081615.html 8.9.2011 http://www.cert.fi/tietoturvanyt/2011/09/ttn201109141445.html 14.9.2011 Comodo: http://www.cert.fi/tietoturvanyt/2011/03/ttn201103241059.html 24.3.2011 Andra dokument om ämnet Informationssäkerhetskrav på certifikatbeviljare: Mozilla: http://www.mozilla.org/projects/security/certs/policy/inclusionpolicy.html Microsoft: http://technet.microsoft.com/en-us/library/cc751157.aspx Apple: http://www.apple.com/certificateauthority/ca_program.html Opera: http://www.opera.com/docs/ca/ Cabforums dokument "Baseline Requirements for the Issuance and Management of Publicly- Trusted Certificates": http://www.cabforum.org/baseline_requirements_draft_35.pdf Hollands myndigheter har publicerat information om fallet DigiNotar: http://www.govcert.nl/english/service-provision/knowledge-andpublications/factsheets/factsheet-fraudulently-issued-security-certificatediscovered.html http://www.rijksoverheid.nl/onderwerpen/cybercrime/documenten-enpublicaties/rapporten/2011/09/05/fox-it-operation-black-tulip.html Österrikes CERT-enhet har tagit fram en bedömning av inverkan av fallet DigiNotar på Österrike: http://www.cert.at/static/downloads/specials/cert.at_report_diginotar_breach_publ ic.pdf Jarno Niemeläs presentation om missbruk av programvarusignaturer: http://www.f-secure.com/weblog/archives/jarno_niemela_its_signed.pdf 11