HPKP är ett föråldrat webbsäkerhetssvarshuvud, akronymen står för HTTP Public Key Pins. Det var avsett att förhindra en komprometterad eller oseriös certifikatmyndighet från att utfärda ett offentligt pålitligt, men hackerkontrollerat, HTTPS-certifikat för en webbplats. I det här scenariot skulle hackarna kunna dekryptera all avlyssnad HTTPS-trafik till den berörda webbplatsen.
Tips: Webbsvarsrubriker är bitar av metadata som servern tar med när den svarar på förfrågningar. En liten delmängd av dessa kallas säkerhetsrubriker, eftersom de aktiverar och konfigurerar olika säkerhetsfunktioner.
HTTPS-certifikatinfrastruktur
Certifikatinfrastrukturen som HTTPS bygger på är baserad på en webb av förtroende. Ett antal företag fungerar som Certificate Authorities (CA) som publicerar ett eller flera rotcertifikat. En uppsättning rotcertifikat ingår i alla enheter i en förtroendebutik. När en webbplats begär ett eget HTTPS-certifikat från en CA, signeras certifikatet av ett rotcertifikat. När din dator ser ett HTTPS-certifikat kontrollerar den signaturen. Om certifikatet är signerat av ett rotcertifikat som det litar på, litar din dator också på HTTPS-certifikatet.
Tips: En CA kan också ha mellanliggande certifikat signerade av rotcertifikatet. Dessa mellanliggande certifikat kan också användas för att signera HTTPS-certifikat för webbplatser.
En certifikatutfärdares uppgift är att endast utfärda ett certifikat när de har verifierat att personen som begär dem är den verkliga ägaren till webbplatsen. Tanken med den här strukturen är att om en hackare skapar sitt eget certifikat för en webbplats, kommer det inte att signeras av en CA som din dator litar på, och du kommer därför att se en varning.
Vad gjorde HPP?
Hela certifikatsystemet är beroende av certifikatutfärdarnas tillförlitlighet. Ursprungligen fanns det dock inga skydd mot att en certifikatutfärdare komprometterades av hackare eller blev skurk och valde att felaktigt utfärda certifikat.
HPKP utformades för att vara ett skydd mot denna möjlighet. Det tillåter webbplatser att ange en exklusiv lista över certifikat som kan litas på för webbplatsen i en process som kallas pinning. Det var möjligt att fästa rot- eller mellancertifikatet, vilket i huvudsak gjorde det möjligt för en enda CA att utfärda certifikat för webbplatsen. Det var också möjligt att fästa certifikatet för själva webbplatsen, vilket hindrade till och med rätt CA från att utfärda ett annat giltigt certifikat.
Tekniskt sett är det inte själva certifikatet som är fäst, utan en hash av certifikatets nyckel. En hash är en enkelriktad kryptografisk funktion. Detta innebär att det är möjligt att verifiera att certifikatet som presenteras för webbläsaren av webbplatsen matchar ett fäst certifikat, men det är inte möjligt att använda hashen för att skapa ett giltigt certifikat.
HPKP krävde att minst två nycklar var fästa, varav minst en måste vara en säkerhetskopia och inte i den aktuella certifikatkedjan. Denna säkerhetskopia låter dig konfigurera en smidig överlämning till ett nytt certifikat som inte hindrar användare från att kunna ansluta.
Om HTTPS-certifikatet som presenteras för webbläsaren av webbplatsen inte stämmer överens med något av de fästa certifikat, måste webbläsaren avvisa det och hindra användaren från att kringgå certifikatet felmeddelande.
Struktur för HPKP
HPKP-huvudet har tre obligatoriska delar och två valfria. Rubriken måste ha titeln "Public-Key-Pins", nästa två eller fler certifikat måste ha en base64-kodad SHA256-hash fäst i formatet 'pin-sha256='
Tips: SHA256 är hashalgoritmen som används av HPKP. Base64 är en teckenuppsättning med 64 tecken: 0-9, a-z, A-Z och specialtecknen "+" och "/". "=" används för att fylla ut upp till de två sista tecknen om det behövs.
De valfria inställningarna är "includeSubDomains" och "report-uri". "includeSubDomains instruerar webbläsaren att tillämpa HPKP-skydden på alla underdomäner på den aktuella webbplatsen under tiden för "max-age"-timern. "report-uri" är en funktion som gör att en webbplats kan specificeras dit felrapporter kan skickas, och är utformad för att hjälpa till att identifiera och lösa problem.
Det finns en andra variant av rubriken med titeln "Public-Key-Pins-Report-Only". Allt är sig likt, men om ett fel hittas vidtas ingen åtgärd utöver att returnera ett felmeddelande till webbläsaren och till "report-uri" om en sådan är konfigurerad. Den enda rapportens variant var utformad för att möjliggöra fullskalig testning av rubriken före implementering, där fel inte skulle orsaka problem för användarna.
Problem med HPKP
HPKP fasades ut av två huvudsakliga skäl. Det fanns två sätt på vilka rubriken kunde orsaka allvarliga problem för webbplatsen som använder den, dessa hette HPKP Suicide och Ransom PKP.
HPKP-självmord är ett problem där de legitima ägarna av webbplatsen förlorar åtkomst till alla de fastnade nycklarna. Detta kan hända genom oavsiktlig radering, hacking, virus, datakorruption eller av många andra skäl. På grund av komplexiteten i att implementera HPKP korrekt, och speciellt att hålla den uppdaterad under certifikatrotationer, är det relativt lätt att göra ett konfigurationsfel. Men med HPKP, om du missför dig, kommer alla nya besökare på din webbplats att förhindras från att kunna komma åt din webbplats så länge som "max-age"-timern. Webbplatsen smashingmagazine.com publicerade en artikel beskriver sin erfarenhet av exakt det här problemet, som i princip tog webbplatsen offline för de flesta besökare i fyra dagar innan en fix implementerades.
Ransom PKP är en teoretisk attack där en hackare får tillgång till en webbserver, sedan stjäl alla betrodda certifikat och nycklar och sedan kräver en lösensumma för att de ska återlämnas. I en normal installation kan du bara generera nya nycklar och certifikat och få webbplatsen igång igen på mindre än en timme. Med HPKP aktiverat är dock dessa nycklar fästa, om du inte kan skicka ett fäst certifikat till användare kommer de inte att kunna komma åt webbplatsen under tiden för "max-age"-timern. Beroende på konfigurationen och om det finns säkerhetskopior kan det vara omöjligt att lösa problemet.
Med båda dessa problem skulle nya användare kunna komma åt webbplatsen som vanligt, som de skulle har aldrig sett det gamla HPKP-huvudet som instruerar deras webbläsare att bara lita på de nu saknade certifikat. Alla nya besökare, såsom vanliga kunder och läsare, skulle dock behöva vänta under hela tiden för "max-age"-timern.
Med tanke på svårighetsgraden av dessa problem och komplexiteten i konfigurationen och underhållet var användningen av HPKP-huvudet mycket låg. Så småningom gick stora webbläsare överens om att helt avskaffa stödet för det och inom ett par år var HPKP-huvudet universellt utfasat.