Beskrivning
HTTPS (via SSL /TLS) använder kryptering av offentlig nyckel för att skydda webbläsarkommunikation från att läsas eller ändras i transit via Internet. Servrar ger besökande webbläsare en offentlig nyckel som används för att upprätta en krypterad anslutning för alla efterföljande datautbyten.
Men bara att få en arbetssätt offentlig nyckel ensam garanterar inte att den (och i serverns förlängning) ägs av rätt fjärrkontroll ämne (dvs. person, företag eller organisation). Man-in-the-middle angripare kan manipulera nätverk för att tjäna sina egna nycklar och därigenom äventyra all kommunikation.
Webbläsare förhindrar detta genom autentiserande HTTPS-servrar som använder certifikat, som är digitala dokument som binda en offentlig nyckel till ett enskilt ämne. Bindningen hävdas genom att ha en betrodd Certifieringsmyndighet (CA) som SSL.com verifiera identiteten för potentiella certifikatägare, via automatiserade och manuella kontroller mot kvalificerade databaser.
Detta förtroendeförhållande innebär att webbanvändarsäkerhet inte är absolut; snarare kräver det att användare litar på webbläsare och certifikatutfärdare för att skydda deras säkerhet. Därför tror vi att det ligger i varje användares intresse att ha en grundläggande förståelse för hur certifikatvalidering fungerar.
Observera att certifikatvalideringsprocessen (beskrivs i detalj i standarddokumentet RFC 5280) är ganska invecklad. I den här artikeln kommer vi att försöka gå dig längs en väg (en webbläsare som validerar värdens SSL /TLS certifikat) och navigera förbi komplexa detaljer som är opåverkade för de flesta användare.
Certifikat och X.509-format
Certifikat är digitala filer i alla avseenden, vilket innebär att de måste följa ett filformat för att lagra information (t.ex. signaturer, nycklar, emittenter etc.). Medan privat PKI konfigurationer kan implementera vilket format som helst för sina certifikat, betrodda offentligt PKIs (dvs. de som är tillförlitliga av webbläsarna) måste överensstämma med RFC 5280, vilket kräver användning av X.509 v3 format.
X.509 v3 tillåter certifikat att inkludera ytterligare data, till exempel användningsbegränsningar eller policyinformation, som förlängningar, där varje tillägg är antingen kritisk or icke kritisk. Webbläsare kan ignorera ogiltiga eller okända icke-kritiska tillägg, men de måste bearbeta och validera alla kritiska.
Certifieringsvägar och vägbearbetning
CA använder en privat nyckel för att kryptografiskt signera alla utfärdade certifikat. Sådana signaturer kan oåterkalleligt bevisa att ett certifikat utfärdades av en specifik CA och att det inte ändrades efter det att det undertecknades.
CA: s fastställer ägande av sin signeringsnyckel genom att inneha ett självutgivet certifikat (kallat rot) för motsvarande offentlig nyckel. CAs måste följa tätt kontrollerade och granskade rutiner för att skapa, hantera och använda en rot, och för att minimera exponeringen använder man normalt en rot för att utfärda mellanliggande certifikat. Dessa mellanprodukter kan sedan användas för att utfärda sina kundcertifikat.
Webbläsare levereras med en inbyggd lista över pålitliga rötter. (Dessa är rötter från certifikatutfärdare som har passerat webbläsarens stränga kriterier för införande.) För att verifiera ett certifikat kommer en webbläsare att få en sekvens av certifikat, var och en har undertecknat nästa certifikat i sekvensen, som kopplar den signerande CA: s rot till servern certifikat.
Denna sekvens av certifikat kallas a certifieringsväg. Banans rot kallas a förtroendeankare och serverns certifikat kallas blad or slutenhet certifikat.
Sökvägskonstruktion
Ofta måste webbläsare överväga flera certifieringsvägar tills de kan hitta en giltig för ett visst certifikat. Även om en sökväg kan innehålla certifikat som "kedjer" sig ordentligt till ett känt ankare, kan själva sökvägen avvisas på grund av begränsningar av sökvägslängd, domännamn, certifikatanvändning eller policy.
Att konstruera och utvärdera alla möjliga vägar är en dyr process som utförs för varje nytt certifikat som en webbläsare stöter på. Webbläsare har implementerat olika optimeringar för att minimera antalet avvisade kandidatvägar, men att gå in i sådana detaljer ligger långt utanför denna artikel.
Vägvalidering
Efter att en kandidatcertifieringsväg har konstruerats validerar webbläsare den med informationen i certifikaten. En sökväg är giltig om webbläsare kan kryptografiskt bevisa att, med utgångspunkt från ett certifikat som direkt undertecknats av ett förtroendeankare, användes varje certifikats motsvarande privata nyckel för att utfärda nästa i sökvägen, hela vägen ner till bladcertifikatet.
Certifieringsväg Valideringsalgoritm
RFC 5280 beskriver a standardalgoritm som webbläsare följer för att validera en certifieringsväg för X.509-certifikat.
I grund och botten går webbläsare igenom alla certifikat i sökvägen som börjar med förtroendeankaret (dvs. rotcertifikatet), vilket validerar varje certifikats grundläggande information och kritiska tillägg.
Om proceduren avslutas med det sista certifikatet i sökvägen utan fel accepteras sökvägen som giltig. Om fel produceras markeras sökvägen som ogiltig.
Grundläggande certifikatbehandling
Oavsett tillägg måste webbläsare alltid verifiera grundläggande certifikatinformation som signatur eller emittent. Följande avsnitt visar sekvensen av kontroller som webbläsare utför.
1. Webbläsaren verifierar certifikatets integritet
Smakämnen namnteckning på certifikatet kan verifieras med normal offentlig nyckelkryptografi. Om signaturen är ogiltig, anses certifikatet vara ändrat efter dess utfärdande och avvisas därför.
2. Webbläsaren verifierar certifikatets giltighet
Ett certifikat giltighetsperiod är det tidsintervall under vilket undertecknande CA garanterar att den kommer att behålla information om dess status. Webbläsare avvisar alla certifikat med en giltighetsperiod som slutar före eller börjar efter datum och tid för valideringskontrollen.
3. Webbläsaren kontrollerar certifikatets återkallningsstatus
När ett certifikat utfärdas förväntas det vara i bruk under hela giltighetsperioden. Naturligtvis kan olika omständigheter göra att ett certifikat blir ogiltigt innan det naturligtvis löper ut.
Sådana omständigheter kan innefatta ett ämne som byter namn eller en misstänkt kompromiss med sin privata nyckel. I fall som detta måste en CA återkalla motsvarande certifikat, och användare litar också på en CA för att meddela webbläsare om deras certifikats återkallningsstatus.
RFC 5280 rekommenderar att CA: er använder återkallningslistor för detta ändamål.
Certifikatåterkallande listor (CRL)
CA: er utfärdar regelbundet en signerad, tidsstemplerad lista över återkallade certifikat som kallas a certifikat återkallande lista (CRL). CRL: er distribueras i offentligt tillgängliga arkiv, och webbläsare kan skaffa och konsultera CA: s senaste CRL när de validerar ett certifikat.
En brist i denna metod är att tidsgränsen för återkallande är begränsad till CRL-utfärdandeperioden. En webbläsare kommer att meddelas om återkallelse efter att alla för närvarande utfärdade CRL: er planeras att uppdateras. Beroende på den undertecknande CA: s policy kan det ta en timme, dag eller till och med upp till en vecka.
Online -certifikatstatusprotokoll (OCSP)
Det finns andra alternativa metoder för att få information om återkallelse av status, varav de mest populära är Online-certifikatstatusprotokoll (OCSP).
Beskrivs i standarddokument RFC6960, Låter OCSP en webbläsare begära ett specifikt certifikats återkallningsstatus från en online OCSP-server (även kallad ompröva). När den är korrekt konfigurerad är OCSP mycket mer omedelbar och undviker problemet med CRL-uppdateringstiden som nämns ovan. För övrigt, OCSP häftning förbättrar prestanda och hastighet.
4. Webbläsaren verifierar emittenten
Certifikat är normalt kopplade till två enheter:
- Smakämnen utfärdare, som är den enhet som äger signeringsnyckeln och
- Smakämnen ämne, som hänvisar till ägaren till den offentliga nyckeln som certifikatet verifierar.
Webbläsare kontrollerar att ett certifikat är utfärdare fältet är samma som ämne fältet för det tidigare certifikatet i sökvägen. För ökad säkerhet, mest PKI implementeringar verifierar också att utfärdarens nyckel är densamma som nyckeln som undertecknade det aktuella certifikatet. (Observera att detta inte är sant för förtroendeankaren, eftersom rötterna är självutgivna - dvs. de har samma emittent och ämne.)
Behandling av begränsningar
X.509 v3-formatet låter en CA definiera begränsningar eller begränsningar för hur varje certifikat valideras och används som kritiska tillägg. Varje certifikat i sökvägen kan införa ytterligare begränsningar som alla efterföljande certifikat måste följa.
Certifikatbegränsningar påverkar sällan den genomsnittliga Internetanvändaren, även om de är ganska vanliga i företagets SSL-lösningar. Funktionella begränsningar kan tjäna flera operativa syften, men deras mest betydande användning är att mildra kända säkerhetsproblem.
5. Webbläsaren kontrollerar namnbegränsningar
En privatägd (men allmänt betrodd) mellanliggande CA med lämplig namn begränsningar kan ge en organisation finkornig kontroll över certifikathantering och utfärdande. Certifikat kan begränsas till en viss domän eller ett domänträd (dvs. inklusive underdomäner) för ett företags eller organisations domännamn. Namnbegränsningar används ofta för mellanliggande CA-certifikat som köps från en offentligt betrodd CA för att förhindra att den mellanliggande CA utfärdar helt giltiga certifikat för tredjepartsdomäner (t.ex. google.com).
6. Webbläsaren kontrollerar policybegränsningar
En certifikatpolicy är ett juridiskt dokument som publiceras av en CA, som officiellt beskriver de förfaranden de följer för att utfärda och hantera sina certifikat. CA kan utfärda ett certifikat enligt en eller flera policyer, och länkar till dessa ingår i varje certifikat som utfärdas så att pålitliga parter kan utvärdera dessa policyer innan de beslutar att lita på certifikatet.
Av juridiska och operativa skäl kan certifikat införa begränsningar för vilken policy de kan vara föremål för. Om ett certifikat visar sig innehålla kritiska policybegränsningar måste webbläsare validera dem innan de fortsätter. (Men kritiska politikbegränsningar uppträder emellertid sällan i den verkliga världen och det kommer inte att ses bort från resten av denna artikel.)
7. Webbläsaren kontrollerar grundläggande begränsningar (aka väglängd)
X.509 v3-formatet tillåter utgivare att definiera den maximala söklängd som ett certifikat kan stödja. Detta ger kontroll över hur långt varje certifikat kan placeras i en certifieringsväg. Detta är faktiskt viktigt - webbläsare brukade bortse från certifieringsvägens längd tills en forskare visade, 2009 presentation, hur han använde sin webbplats bladcertifikat för att skapa ett giltigt certifikat för en stor e-handelswebbplats.
8. Webbläsaren verifierar nyckelanvändning
Tillägget "nyckelanvändning" anger syftet med nyckeln i certifikatet. Exempel på sådana ändamål inkluderar kryptering, signaturer, certifikatsignering och så vidare. Webbläsare avvisar certifikat som bryter mot deras begränsningar för nyckelanvändning, till exempel att stöta på ett servercertifikat med en nyckel som endast är avsedd för CRL-signering.
9. Webbläsaren fortsätter att behandla alla återstående kritiska tillägg
Efter att ha bearbetat tilläggen som nämns ovan fortsätter webbläsarna att validera alla återstående tillägg som det aktuella certifikatet anger som kritiska innan de går vidare till nästa. Om en webbläsare når en stigs bladcertifikat utan fel accepteras sökvägen som giltig. Om några fel uppstår markeras sökvägen som ogiltig och en säker anslutning upprättas inte.
Slutsats
World Wide Web är ett komplext system av sammankopplade och ständigt utvecklande rörliga delar. Webbläsarsäkerhet är alltså inte ett löst problem, och vi hoppas att den här artikeln har gett viss inblick i komplexiteten hos till och med den komponenten vi har tittat på här. Förtroende spelar en viktig roll för att skydda dig online och därför uppmanar vi dig att fråga mer om din CA: s certifikatpolicy. (Känn dig fri att granska SSL.coms policyer här, faktiskt.)
Tack för att du valde SSL.com, där vi tror a säkrare Internet är en bättre Internet.
