HPKP er en forældet websikkerhedssvarheader, akronymet står for HTTP Public Key Pins. Det var beregnet til at forhindre en kompromitteret eller useriøs certifikatmyndighed i at udstede et offentligt betroet, men hackerkontrolleret, HTTPS-certifikat til et websted. I dette scenarie ville hackerne være i stand til at dekryptere enhver opsnappet HTTPS-trafik til det berørte websted.
Tip: Websvar-headere er stykker metadata, som serveren inkluderer, når den besvarer anmodninger. En lille delmængde af disse kaldes sikkerhedsheadere, da de aktiverer og konfigurerer forskellige sikkerhedsfunktioner.
HTTPS-certifikatinfrastruktur
Certifikatinfrastrukturen, som HTTPS er bygget på, er baseret på et tillidsnet. En række virksomheder fungerer som Certificate Authorities (CA), som udgiver et eller flere rodcertifikater. Et sæt rodcertifikater er inkluderet i alle enheder i en tillidsbutik. Når et websted anmoder om sit eget HTTPS-certifikat fra en CA, signeres certifikatet af et rodcertifikat. Når din computer ser et HTTPS-certifikat, tjekker den signaturen. Hvis certifikatet er signeret af et rodcertifikat, det har tillid til, stoler din computer også på HTTPS-certifikatet.
Tip: Et CA kan også have mellemliggende certifikater, der er signeret af rodcertifikatet. Disse mellemliggende certifikater kan også bruges til at signere HTTPS-certifikater til websteder.
En certifikatmyndigheds opgave er kun at udstede et certifikat, når de har bekræftet, at den person, der anmoder om dem, er den ægte ejer af webstedet. Ideen med denne struktur er, at hvis en hacker opretter deres eget certifikat til et websted, vil det ikke blive underskrevet af en CA, som din computer har tillid til, og du vil derfor se en advarsel.
Hvad gjorde HPP?
Hele certifikatsystemet er afhængigt af certifikatmyndighedernes troværdighed. Oprindeligt var der dog ingen beskyttelse mod, at en CA blev kompromitteret af hackere eller blev useriøs og valgte at udstede certifikater forkert.
HPKP er designet til at være en beskyttelse mod denne mulighed. Det giver websteder mulighed for at angive en eksklusiv liste over certifikater, der kan stoles på for webstedet i en proces, der kaldes pinning. Det var muligt at fastgøre rod- eller mellemcertifikatet, hvilket i det væsentlige tillod en enkelt CA at udstede certifikater til webstedet. Det var også muligt at fastgøre certifikatet for selve webstedet, hvilket forhindrede selv den rigtige CA i at udstede et andet gyldigt certifikat.
Teknisk set er det ikke selve certifikatet, der er fastgjort, men en hash af certifikatets nøgle. En hash er en envejs kryptografisk funktion. Dette betyder, at det er muligt at verificere, at det certifikat, der præsenteres for browseren af webstedet, matcher et fastgjort certifikat, men det er ikke muligt at bruge hashen til at lave et gyldigt certifikat.
HPKP krævede, at mindst to nøgler blev fastgjort, hvoraf mindst én skal være en backup og ikke i den aktuelle certifikatkæde. Denne backup giver dig mulighed for at konfigurere en jævn overdragelse til et nyt certifikat, der ikke forhindrer brugere i at kunne oprette forbindelse.
Hvis HTTPS-certifikatet, der præsenteres for browseren af webstedet, ikke matcher en af de fastgjorte certifikater, så skal browseren afvise det og forhindre brugeren i at omgå certifikatet fejl besked.
Struktur af HPKP
HPKP-headeren har tre obligatoriske dele og to valgfrie. Overskriften skal have titlen "Public-Key-Pins", de næste to eller flere certifikater skal have en base64-kodet SHA256-hash fastgjort i formatet 'pin-sha256='
Tip: SHA256 er hashing-algoritmen, der bruges af HPKP. Base64 er et tegnsæt med 64 tegn: 0-9, a-z, A-Z og specialtegnene "+" og "/". "=" bruges til at udfylde op til de sidste to tegn, hvis det er nødvendigt.
De valgfrie indstillinger er "includeSubDomains" og "report-uri". "includeSubDomains instruerer browseren om at anvende HPKP-beskyttelsen på et hvilket som helst underdomæne på det aktuelle websted i varigheden af "max-age"-timeren. "report-uri" er en funktion, der gør det muligt at specificere et websted, hvor fejlrapporter kan sendes, og er designet til at hjælpe med at identificere og løse problemer.
Der er en anden variant af overskriften med titlen "Public-Key-Pins-Report-Only". Alt er det samme, men hvis der findes en fejl, foretages der ingen handling ud over at returnere en fejlmeddelelse til browseren og til "report-uri", hvis en er konfigureret. Den eneste rapportvariant blev designet til at muliggøre fuldskala-test af headeren før implementering, hvor fejl ikke ville forårsage problemer for brugerne.
Problemer med HPKP
HPKP blev forældet af to hovedårsager. Der var to måder, hvorpå overskriften kunne forårsage alvorlige problemer for webstedet, der brugte det, disse blev navngivet HPKP Selvmord og Ransom PKP.
HPKP Selvmord er et problem, hvor de legitime ejere af webstedet mister adgangen til alle de fastgjorte nøgler. Dette kan ske ved utilsigtet sletning, hacking, virus, datakorruption eller af mange andre årsager. På grund af kompleksiteten i at implementere HPKP korrekt, og især at holde det opdateret under certifikatrotationer, er det relativt nemt at lave en konfigurationsfejl. Men med HPKP, hvis du tager fejl, vil alle nylige besøgende på din hjemmeside blive forhindret i at få adgang til din hjemmeside i længden af "max-age" timeren. Hjemmesiden smashingmagazine.com postede en artikel beskriver sin oplevelse med netop dette problem, som i det væsentlige gjorde webstedet offline for de fleste besøgende i fire dage, før en rettelse blev implementeret.
Ransom PKP er et teoretisk angreb, hvor en hacker får adgang til en webserver, derefter stjæler alle betroede certifikater og nøgler og derefter kræver løsesum for deres returnering. I en normal opsætning kunne du bare generere nye nøgler og certifikater og få hjemmesiden op at køre igen på mindre end en time. Med HPKP aktiveret er disse nøgler imidlertid fastgjort, hvis du ikke kan levere et fastgjort certifikat til brugere, vil de ikke være i stand til at få adgang til webstedet i varigheden af "max-age"-timeren. Afhængigt af konfigurationen, og hvis der findes sikkerhedskopier, kan det være umuligt at løse dette problem.
Med begge disse problemer ville nye brugere kunne få adgang til hjemmesiden som normalt, som de ville aldrig har set den gamle HPKP-header instruere deres browser til kun at stole på de nu forsvundne certifikater. Alle nylige besøgende, såsom faste kunder og læsere, skulle dog vente i hele varigheden af "max-age"-timeren.
I betragtning af alvoren af disse problemer og kompleksiteten af konfigurationen og vedligeholdelsen var brugen af HPKP-headeren meget lav. Til sidst blev store browsere enige om at droppe støtten til det helt, og inden for et par år blev HPKP-headeren universelt forældet.