Vad är certifikatfästning?

Vad är certifikatfästning?

Chrome föråldrade HTTP Public Key Pinning (HPKP), webbstandarden som tillät webbplatser att definiera PIN-koder för offentliga nycklar, år 2018 och tog bort stödet helt med Chrome 72 år 2019. Certifikatfästning har fortsatt att användas i mobilappar och API-klienter, och kortare certifikatlivslängder gör det valet mer operativt krävande, särskilt för team som fäster enskilda certifikat. Med den maximala livslängden för offentligt betrodda TLS certifikaten är nu 200 dagar, och förväntas minska till 100 dagar år 2027 och 47 dagar år 2029, men fastlåsning på certifikatnivå kommer att kräva allt tätare uppdateringar och noggrann samordning.

Certifikatfästing är en säkerhetsteknik som knyter en klient, vanligtvis en mobilapp eller API-klient, till ett specifikt certifikat, en offentlig nyckel eller en certifikatutfärdare snarare än att enbart förlita sig på certifikat som är betrodda av operativsystemets certifikatarkiv. Under en standardiserad TLS Med en handskakning validerar en klient serverns certifikat, inklusive att verifiera att det är kopplat till en lämplig betrodd rot, är giltigt för det begärda värdnamnet, är inom sin giltighetstid och uppfyller tillämpliga certifikatstatus- och policykontroller.

Fästning lägger till ytterligare en kontroll utöver det vanliga TLS certifikatvalidering: certifikatet, den publika nyckeln eller annat fäst värde som presenteras av servern måste matcha ett värde som klienten förväntar sig. Om det inte matchar avvisas anslutningen även om certifikatet annars skulle klara normala processer. TLS godkännande.

Hur fungerar certifikatfästning?

1. Standardcertifikatvalidering: I en typisk TLS handskakning, när en klient ansluter till en server, presenterar servern sitt digitala certifikat för klienten. Klienten kontrollerar sedan certifikatets äkthet genom att verifiera att det har signerats av en betrodd certifikatutfärdare (CA) och att det inte har löpt ut eller återkallats. Om kontrollerna går igenom fortsätter klienten med den säkra anslutningen.
2. Fäst förtroende: Certifikatfästning tar förtroendeverifieringen ett steg längre. Istället för att enbart förlita sig på CA-systemet har klientens applikation eller enhet en förkonfigurerad lista med publika nycklar eller certifikat som den uttryckligen litar på

Webbläsarfästning kontra appnivåfästning: Vad som har ändrats

Certifikatfästningen försvann inte. Den flyttades.

Google introducerade statisk nyckelfästning i Chrome 2011, och byggde in en lista över betrodda offentliga nycklar för Googles egna domäner. Samma år hjälpte dessa pins till att avslöja bedrägliga google.com-certifikat som utfärdats via den komprometterade DigiNotar CA. Chrome och Firefox lät senare webbplatser välja att delta via HTTP Public Key Pinning (HPKP)-svarsrubriker. HPKP visade sig vara en belastning: en webbplats som förlorade åtkomst till sin fästa nyckel, eller fick en skadlig pin inställd under en kompromiss, kunde spärra användare under pinens konfigurerade livslängd. Chrome avfärdade HPKP 2018 och tog bort stödet i början av 2019, medan Firefox slutade respektera HPKP-rubriker 2020. Stora webbläsare stöder inte längre HPKP som ett sätt för webbplatser att skapa sina egna pins. Webbläsare kan fortfarande ha inbyggda pins för en begränsad uppsättning domäner, men webbplatser kan inte längre be en webbläsare att skapa pins åt dem via HPKP.

Mobil och IoT-pinning följde en annan väg. Apputvecklare har större kontroll över klienten och de servrar den kommunicerar med, vilket gör det möjligt för dem att distribuera uppdaterade pins via applikationsuppdateringar eller andra säkert utformade pinhanteringsmekanismer och underhålla säkerhetskopior av pins för att hantera nyckeländringar. Nuvarande OWASP Mobile Application Security Verification Standard (MASVS)-riktlinjer inkluderar identitetspinning för fjärrslutpunkter under utvecklarens kontroll, och anslutna enheter som kommunicerar med en fast uppsättning backend-servrar kan använda pinning av liknande skäl. OWASP rekommenderar också att man pinnar offentliga nycklar snarare än hela certifikat där det är lämpligt, vilket kan minska problem som orsakas av att certifikat löper ut och förnyas.

Det är därför ”certifikatfästning” idag generellt hänvisar till appnivå, enhetsnivå eller API-klientfästning snarare än något som en vanlig webbplats kan be en webbläsare att tillämpa.

Vilka är nackdelarna med att fästa certifikat?

De fyra operativa problemen som pinning skapar har inte förändrats, och branschkonsensusen om dem har hårdnat. Microsoft, Google, AWS, Cloudflare och OWASP avråder nu i stor utsträckning från statisk fastlåsning av offentligt betrodda certifikat, inte för att fastlåsning inte fungerar, utan för att på den offentliga webben PKI det tenderar att skapa mer operativ risk än det eliminerar.

1. 1.  Underhållskomplexitet: Certifikatnålning kräver att klienter upprätthåller en lista över betrodda certifikat eller publika nycklar. Denna lista måste dock uppdateras kontinuerligt för att återspegla ändringar i servercertifikat. Eftersom certifikat har utgångsdatum och förnyas regelbundet, kan processen att hålla fastnade certifikat uppdaterade vara besvärlig, utsatt för mänskliga fel och kan leda till avbrott i tjänsten.
   2. Minskad flexibilitet: I dynamiska och molnbaserade miljöer där servercertifikat ändras ofta (t.ex. innehållsleveransnätverk eller mikrotjänster), kan certifikatfästning innebära operativa utmaningar. Oflexibiliteten hos fästa certifikat kan hindra smidiga övergångar under serveruppdateringar och komplicera certifikathanteringen.
   3. Risk för att bryta anslutningar: Att fästa ett certifikat till ett program medför risk för anslutningsförlust om det fästa certifikatet äventyras eller förfaller. Detta kan resultera i tjänstavbrott för användare tills klientapplikationen uppdateras med det nya fästa certifikatet.
   4. Brist på skalbarhet: Att fästa certifikat kan vara opraktiskt för storskaliga applikationer eller tjänster som behöver kommunicera med många servrar, var och en med sitt eget certifikat. Att hantera en mängd fästade certifikat blir svårhanterligt och kan undergräva fördelarna med att fästa certifikat.

Kortare certifikatlivstid ökar insatserna

Vart och ett av de fyra problemen ovan förvärras i takt med att certifikatens giltighetstid krymper. När ett lövcertifikat är fäst direkt i en applikations kod eller konfiguration kan certifikatrotation kräva att en uppdaterad PIN-kod distribueras till klienter innan certifikatet ändras. Utrullningar i appbutiker, stegvisa uppdateringar och användare som helt enkelt inte uppdaterar enligt schemat kan alla komplicera den processen. Den processen var mer förlåtande när certifikat varade i över ett år. Enligt CA/Browser Forum Ballot SC-081, den maximala giltighetsperioden för offentligt betrodda TLS Certifikat minskade till 200 dagar den 15 mars 2026 och kommer att minska till 100 dagar den 15 mars 2027 och 47 dagar den 15 mars 2029. Team som direkt fäster lövcertifikat behöver därför en rotationsstrategi som kan hålla jämna steg med allt tätare certifikatförnyelser.

Fästa den offentliga nyckeln, vanligtvis dess Subject Public Key Info (S)PKI), istället för det fullständiga certifikatet kan minska en del av den pressen eftersom ett förnyat certifikat kan behålla samma offentliga nyckel och därför fortsätta att matcha den befintliga PIN-koden. Att rutinmässigt återanvända ett nyckelpar enbart för att bevara en PIN-kod anses dock inte vara god nyckelhanteringspraxis, så applikationer bör istället planera för nyckelrotation med hjälp av reservpinnar eller pinsets. Att fästa en mellanliggande CA:s nyckel kan ge större flexibilitet vid förnyelser av lövcertifikat, men det breddar också applikationens förtroende och eliminerar inte rotationsrisken. Mellanliggande CA:er och deras nycklar kan ändras, så denna metod kräver fortfarande en noggrant utformad rotations- och reservstrategi.

Utforska bättre alternativ till certifikatfästning

Flera alternativa tillvägagångssätt kan stärka säkerheten för klient-server-anslutningar utan de tillhörande utmaningarna:

1. Certificate Transparency (CT): Certifikattransparens är en offentlig logg över alla utfärdade certifikat, vilket ger transparens och ansvarighet i utfärdandeprocessen. Genom att övervaka CT-loggar kan klienter upptäcka obehöriga eller bedrägliga certifikat. Det här tillvägagångssättet förlitar sig inte enbart på pinning utan lägger till ett lager av förtroendeverifiering, vilket gör att klienter kan identifiera oseriösa certifikat utan pinningsspecifikt underhåll.
2. Online Certificate Status Protocol (OCSP) Häftning: OCSP-häftning tillåter servrar att förse klienter med ett digitalt signerat påstående om statusen för deras SSL/TLS certifikat. Genom att använda OCSP-häftning kan klienter verifiera giltigheten av en servers certifikat utan att enbart förlita sig på CA-förtroende. Det är ett mer dynamiskt tillvägagångssätt som inte kräver fästning och minskar risken förknippad med föråldrade certifikat.

3. Publik nyckel (SPKI) FästningFör organisationer vars hotmodell fortfarande motiverar fastlåsning, fastlåsning av ämnets publika nyckelinformation (SPKI) snarare än hela certifikatet kan ge större flexibilitet vid certifikatförnyelse. Ett förnyat certifikat kan fortsätta att matcha ett befintligt SPKI PIN-kod om den använder samma nyckelpar. Att rutinmässigt återanvända ett nyckelpar bara för att bevara en PIN-kod anses dock inte vara god nyckelhanteringspraxis. Program som kräver fästning bör istället planera för nyckelrotation och använda PIN-uppsättningar som inkluderar säkerhetskopior eller framtida nycklar så att certifikat och nycklar kan ändras utan att avbryta anslutningen.

Slutsats

Sammanfattningsvis, även om certifikatfästning kan förbättra säkerheten för klient-server-anslutningar genom att minska risken för man-in-the-midten-attacker, är det inte utan sina nackdelar. Komplexiteten i att underhålla och uppdatera fästade certifikat, minskad flexibilitet i dynamiska miljöer, risken för anslutningsavbrott och bristen på skalbarhet kan göra det till ett mindre praktiskt val för många applikationer. Överväg istället att utforska alternativa tillvägagångssätt som Certificate Transparency (CT) och Online Certificate Status Protocol (OCSP) Stapling, som erbjuder robusta säkerhetsåtgärder utan de inneboende begränsningarna av certifikatstiftning. Genom att välja rätt säkerhetsmekanism för ditt specifika användningsfall kan du säkerställa en säkrare och effektivare kommunikation mellan klienter och servrar.

Få hjälp idag. Fyll i formuläret nedan för att komma i kontakt med vårt säljteam.