Beskrivning
När en användare besöker din HTTPS-webbplats måste den svara med ett fungerande offentlig nyckel, och ett giltigt SSL-certifikat som kopplar nyckeln till din identitet, antingen som person, företag eller organisation. Certifikat utfärdas alltid med ett fördefinierat utgångsdatum som ingår i själva det undertecknade certifikatet, och webbläsare kontrollerar alltid utgångsdatumet och avvisar alla giltiga certifikat.
I vissa fall måste emellertid ett certifikat markeras som ogiltigt (och förtroendet för dessa certifikat måste vara återkallats) innan det går ut. Vanliga exempel inkluderar en serverägare som har bevis (eller helt enkelt misstänker) att deras privata nyckel komprometterades (dvs. att den förlorades, stulits eller förstördes), eftersom en tredje part som innehar denna privata nyckel i huvudsak kan kringgå alla säkerhetskontroller i webbläsarens nätverk.
Som en konsekvens krävde webbläsarsäljare offentligt betrodda certifikatmyndigheter (CA) att implementera minst en metod för att både återkalla problematiska certifikat och för att meddela webbläsare att avvisa dessa återkallade certifikat.
En kort historik över (problemen med) återkallningskontroll
Under de första dagarna av SSL var den metod som CA använde för att publicera sin certifikatåterkallningsstatus i allmänt tillgängliga dokument som kallades listor över återkallande av certifikat (CRL). En CRL är helt enkelt en lista över alla certifikat som en CA någonsin har återkallat före utgången. CA: er publicerade regelbundet den senaste versionen av sina CRL: er, som webbläsare var skyldiga att konsultera med innan varje HTTPS-anslutning.
Naturligtvis som HTTPS (och SSL /TLS) antagandet ökade under åren, så ökade storleken på de publicerade CRL: erna. Kravet på att behöva ladda ner och analysera en stor CRL före varje anslutning införde ett ständigt ökande nätverkskostnad. Det blev snabbt uppenbart att CRL-metoden inte skalades bra.
För att mildra dessa skalningsfrågor, designade och implementerade webbläsare och CA: er Online-certifikatstatusprotokoll (OCSP). Offentligt betrodda certifikatutfärdare, t.ex. SSL.com, underhåll nu enkla HTTP-servrar som heter OCSP-svarare. Webbläsare kan nu kontakta en responder för att begära återkallningsstatus för ett enda certifikat som utfärdats av CA, istället för att behöva förvärva och bearbeta hela CRL.
OCSP-svarare signerar sina svar med CA: s privata signeringsnyckel, och webbläsare kan verifiera att återkallelsestatusen de fick genererades av den faktiska CA.
Tyvärr, även om OCSP verkade som en effektiv lösning till en början, har det nya protokollet visat sig ha några praktiska problem med säkerhet och integritet.
Prestationsproblem
Att kontakta en responder för varje certifikat som webbläsaren stöter på innebär att webbläsare måste utföra en extra HTTP-begäran för varje ny HTTPS-anslutning. Detta nätverkskostnad var synligt för användare, särskilt på sidor som innehåller tredjepartsinnehåll lagrat i fjärrinnehållsdistribueringsservrar (som var och en kan ha ett eller flera certifikat på plats).
lyhördhet är en viktig princip för god användargränssnittsdesign. Långa förseningar kan vara en viktig orsak till användarfrustration och kan leda till att användare tror att din webbplats inte fungerar eller att deras input gest har ignorerats.
Vad mer, många studier Tidigare har kopplat snabb sidhastighet och lyhördhet med förbättrad SEO och ökade konverteringsgrader. Faktum är att Amazon har beräknat att en försening på bara en sekund kan kosta dem ungefär $1.6 miljard årlig.
(För mer information om hur sidhastigheten påverkar din webbplats och föreslagna optimeringar, ta en titt på vår Artikeln beskriva hur du tar bort blandat innehåll från din webbplats kommer att förbättra dess prestanda.)
Säkerhetsfrågor
Det finns också viktiga säkerhetsproblem med OCSP. Det faktum att majoriteten av praktiska OCSP-implementationer inte var tillräckligt tillförlitliga (antingen på grund av nätverksfördröjning, eller konfigurations- eller applikationsfel) motiverade webbläsare och annan klientprogramvara för att implementera OCSP-incheckning mjuk-fail läge.
Detta innebär att om en OCSP-server inte kan nås eller avbrytas när den ger sitt svar, kommer webbläsare att göra det anser att certifikatet är giltigt och fortsätt med HTTPS-anslutningen ändå.
Motiveringen bakom detta är att eftersom en OCSP-server potentiellt kan tjäna miljontals webbplatser och det är möjligt för en OCSP-server att misslyckas när som helst, skulle det att stänga anslutningen på varje OCSP-fel störa surfupplevelsen för miljoner användare. Även om OCSP-servern fungerar men det tar lång tid att svara, bidrar detta till den upplevda förseningen och användarfrustrationen.
Man-i-mitten (MITM) attackerare har varit kända för att utnyttja detta beteende genom att blockera alla anslutningar till OCSP-svarare, vilket effektivt innebär att de kan använda ett stulet certifikat och nyckelpar för en skadlig webbplats, oavsett certifikatets återkallningsstatus.
Sekretessfrågor
Slutligen, eftersom ett certifikat är länkat med en nyckel och ett domännamn, och webbläsare begär återkallningsstatus före varje ny HTTPS-anslutning, betyder detta att webbläsare läcker en betydande del av sina användares webbhistorik till OCSP-svarare.
Naturligtvis är offentlig betrodda CA inte skadliga organisationer som vill äventyra användarens integritet. (Ansebara CA: er försöker alltid aktivt skydda deras användares säkerhet och integritet.) I händelse av kompromiss mellan en CA: s OCSP-svarare kan data som utbyts med den icke-betrodda servern leda till avslöjande av känslig och privat information.
OCSP häftning till undsättning
För att mildra dessa problem kom webbläsare och certifikatutfärdare med en ny metod för att bestämma ett certifikats status, kallad OCSP häftning. OCSP-häftning tillåter webbservrar (istället för webbläsare) att få signerade OCSP-svar för sina certifikat, som kan cachelagras i upp till sju dagar.
Servrar inkluderar (eller häfta) det cachade OCSP-svaret i sina HTTPS-svar bredvid själva SSL-certifikatet. På detta sätt kan webbläsare verifiera CA: s signatur på OCSP-svaret och vara säkra på att certifikatet inte har återkallats, innan den säkra anslutningen upprättas och utan att behöva utföra den dyra ytterligare begäran till själva OCSP-servern.
OCSP-häftning är en enkel men mycket effektiv lösning på ovan nämnda problem. Servrar kan hämta de cachade OCSP-svaren på sin egen tid, vilket tar bort den prestandakostnad som CRL: er och OCSP har samt de åtföljande integritetsproblemen.
OCSP-häftning i sig själv löser dock inte helt OCSP: s säkerhetsproblem med soft-fail. Eftersom häftning implementeras på servern kan webbläsare inte veta om en server faktiskt stöder häftning eller inte.
Som en konsekvens kan MITM-angripare med ett stulet (men återkallat) certifikat utföra en nedgraderingsattack genom att betjäna certifikatet utan OCSP-häftning. En offres webbläsare kan inte bekräfta om servern faktiskt stöder häftning och fortsätta att fråga OCSP-svararen som de normalt skulle göra.
MITM-angripare kan sedan helt enkelt blockera denna OCSP-fråga och effektivt tvinga webbläsare att acceptera certifikatet som giltigt.
OCSP måste häftning
Denna attack motiverade CA: er och webbläsarleverantörer att införa en tillägg för SSL-certifikat, definierade i RFC 7633, allmänt kallad OCSP Måste-Staple (även om RFC själv inte nämner detta namn, vilket kan orsaka viss förvirring.) Detta kräver helt enkelt OCSP-häftning för certifikatet. Om en webbläsare stöter på ett certifikat med detta tillägg som används utan OCSP-häftning kommer det att avvisas. OCSP Must-Staple lindrar ovannämnda nedgraderingsattack och det minskar också onödig trafik till CA: s OCSP-svarare, vilket också kan bidra till att förbättra den totala OCSP-prestandan.
Om du är intresserad av att aktivera OCSP Must-Staple-tillägget i dina certifikat, kontakta en av våra supportagenter på support@ssl.com för mer detaljer.
Aktivera OCSP-häftning på din server
Följande avsnitt innehåller instruktioner om hur du aktiverar OCSP-häftapparater i din spara problem Apache och nginx miljöer:
Apache
För att aktivera OCSP-häftning i din Apache server, lägg till följande rader i serverns konfigurationsfil.
# OCSP Stapling, endast i httpd 2.3.3 och senare SSLUseStapling på SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
nginx
För att aktivera OCSP-häftning i din nginx server, lägg till följande text i din servers konfigurationsfil.
# OCSP häftning --- # hämta OCSP-poster från URL i ssl_certificate och cache dem ssl_stapling på; ssl_stapling_verify on;
Slutsats
Webben är ett intrikat nätverk av beroende av varandra beroende komponenter, alla (vanligtvis) som arbetar i harmoni för att ge en sömlös surfupplevelse. Systemets ständigt ökande komplexitet skapar emellertid en ständigt ökande attackyta och gör det möjligt att utforma och utföra nya nätattacker.
Det stora antalet komponenter ökar naturligtvis latensen och medför förseningar, vilket innebär att företag måste hitta sätt att förbättra säkerheten utan att påverka användarupplevelsen. Aktivering av OCSP-häftning ger dig den sällsynta möjligheten att förbättra säkerheten och prestanda för din webbplats samtidigt.
Som alltid svarar vi gärna på dina frågor angående häftning av OCSP eller andra frågor - släpp bara e-post till oss support@ssl.com.
