Sichere Über­tra­gungs­ka­nä­le sind eine wichtige Vor­aus­set­zung für die Arbeit mit digitalen Daten. Ins­be­son­de­re, wenn Sie Da­ten­pa­ke­te von unterwegs oder per Remote ver­schi­cken und erhalten, ist es von ele­men­ta­rer Bedeutung, dass der komplette Über­tra­gungs­weg gesichert ist. Nicht von ungefähr gehört es zur gängigen Praxis, ver­trau­li­che In­for­ma­tio­nen aus­schließ­lich über VPN- oder SSL/TLS-Ver­bin­dun­gen zu über­tra­gen. Un­ter­neh­men und Ein­rich­tun­gen sorgen mit eigenen DNS-Servern und aus­ge­wähl­ten Zer­ti­fi­zie­rungs­stel­len dafür, dass diese Protokoll-Tech­no­lo­gien nahezu un­an­tast­bar sind. Nutzer, die außerhalb dieser Struk­tu­ren aktiv sind, un­ter­lie­gen jedoch der öf­fent­li­chen DNS- und Zer­ti­fi­kats­stel­len-Hier­ar­chie, was die Wahr­schein­lich­keit eines Man-in-the-Middle-Angriffs auf die Daten deutlich anhebt.

Haupt­ur­sa­che für das erhöhte Si­cher­heits­ri­si­ko sind ge­fälsch­te Zer­ti­fi­ka­te, die von un­se­riö­sen oder in­fil­trier­ten Zer­ti­fi­kats­stel­len aus­ge­stellt werden. Der Nutzer vertraut also darauf, dass die Ver­bin­dung und alle Daten sicher sind, während die Vertrauen schaf­fen­de Instanz pa­ra­do­xer­wei­se dafür ver­ant­wort­lich ist, dass das Gegenteil der Fall ist. Mit dem so­ge­nann­ten HTTP Public Key Pinning (HPKP) brachte Google 2011 eine Lösung ins Spiel, die mitt­ler­wei­le im RFC 7469 als Standard spe­zi­fi­ziert ist.

Was ist HPKP?

Beim Public Key Pinning handelt es sich um eine Er­wei­te­rung für das Über­tra­gungs­pro­to­koll HTTP (Hypertext Transfer Protocol), die es erlaubt, das Public-Key-Set für künftige SSL/TLS-Ver­bin­dun­gen zu einem Host fest­zu­le­gen. Auf diese Weise erfährt ein zu­grei­fen­der Client bei der ersten Kon­takt­auf­nah­me, welchen öf­fent­li­chen Schlüs­seln er beim Ver­bin­dungs­auf­bau zu diesem Host vertrauen kann. Man spricht daher auch von einem „Trust on First Use“-Verfahren (dt. „Vertrauen bei der ersten Anwendung“). Jeder Eintrag eines ve­ri­fi­zier­ten Schlüs­sels wird als Pin be­zeich­net, woher der Me­cha­nis­mus auch seinen Namen hat. Alle er­stell­ten Pins werden dem Client im HTTP-Header über­mit­telt und daraufhin für den an­ge­ge­be­nen Zeitraum ge­spei­chert.

Bei einem erneuten Ver­bin­dungs­ge­such überprüft der Client, ob die für die SSL/TLS-Über­tra­gung vor­ge­schla­ge­ne Zer­ti­fi­zie­rungs­ket­te einen öf­fent­li­chen Key enthält, der ihm zuvor via HPKP zu­ge­spielt wurde. Ist dies nicht der Fall, bei­spiels­wei­se bei einem ge­fälsch­ten Zer­ti­fi­kat, kommt es zu einer Feh­ler­mel­dung und die Ver­bin­dung wird nicht aufgebaut. Diesen Über­prü­fungs­pro­zess be­zeich­net man auch als Pin-Va­li­die­rung. Die Einträge der Pins im HTTP-Header sehen dabei in etwa fol­gen­der­ma­ßen aus:

Public-Key-Pins:
    pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
    pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
    pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
    max-age=2592000; includeSubDomains; report-uri="http://example.com/pkp-report"

Das Beispiel zeigt alle vier Di­rek­ti­ven, die ein Pin-Eintrag im HTTP-Header enthalten kann:

  • pin: Die pin-Direktive ist der wich­tigs­te Be­stand­teil des Eintrags. Als solcher setzt sich die Direktive aus einem Namen und einem Wert zusammen. Der Name gibt Rück­schlüs­se auf den Al­go­rith­mus, der für die Ver­schlüs­se­lung verwendet wurde. Bis dato ist hier einzig SHA256 möglich. Bei dem Hashwert, der sich innerhalb der An­füh­rungs­zei­chen befindet, handelt es sich um eine Base64-kodierte Zei­chen­fol­ge, die auch als Fin­ger­print be­zeich­net wird. Für jeden Schlüssel (auch Back-ups) muss immer eine eigene pin-Direktive gesetzt werden.
  • max-age: Die Direktive max-age gibt die Gül­tig­keits­dau­er eines Pins in Sekunden an. Sie teilt dem Client also mit, wie lange er einen aus­ge­zeich­ne­ten Public Key als sicheren Schlüssel werten soll. Im hier ver­wen­de­ten Beispiel werden die auf­ge­lis­te­ten Pins nach 30 Tagen (2.592.000 Sekunden) verworfen.
  • in­clude­Sub­Do­mains: Die Anweisung in­clude­Sub­Do­mains ist optional und erfordert keinen Wert. Sie si­gna­li­siert dem Client, dass die de­fi­nier­ten Zer­ti­fi­zie­rungs­re­geln nicht nur für die auf­ge­ru­fe­ne Domain gelten, sondern auch für alle Sub­do­mains, die zu dem Host gehören.
  • report-uri: Wenn die Direktive report-uri gesetzt ist, werden jegliche Fehl­ver­su­che bei der Pin-Va­li­die­rung an die an­ge­ge­be­ne URL gesendet. Diese muss sich nicht not­wen­di­ger­wei­se auf derselben In­ter­net­do­main befinden wie der kon­tak­tier­te Host, der so über die fehl­ge­schla­ge­nen Auf­bau­ver­su­che in­for­miert wird.

Wie funk­tio­niert Cer­ti­fi­ca­te Pinning auf dem eigenen Server?

Um von den Mög­lich­kei­ten von HPKP Gebrauch zu machen, müssen Sie sich zunächst überlegen, welchen Public Key bzw. welche Public Keys Sie „pinnen“ möchten. Prin­zi­pi­ell können Sie hierbei jeden öf­fent­li­chen Schlüssel auswählen, der in der Zer­ti­fi­zie­rungs­ket­te enthalten ist – egal ob Root-, Zwischen- oder das eigene Server-Zer­ti­fi­kat. Wählt man externe Zer­ti­fi­zie­rungs­stel­len aus, sollte man jedoch immer bedenken, dass in der Folge alle Zer­ti­fi­ka­te dieser Stelle von den Clients als gültig angesehen werden und zu einer er­folg­rei­chen Pin-Va­li­die­rung führen.

Wird der eigene Server-Key gepinnt, wiegt es dafür umso schwerer, wenn der Schlüssel un­brauch­bar wird oder aufgrund eines Hardware-Defekts verloren geht. Da die Clients den Pin nämlich beim ersten Zugriff für die an­ge­ge­be­ne Gül­tig­keits­dau­er ge­spei­chert haben, ak­zep­tie­ren sie vor Ablauf dieses Zeit­rah­mens auch keinen neuen Pin. Für die Nutzer wäre Ihr Server in der Folge nicht mehr er­reich­bar. Um diesem Szenario vor­zu­beu­gen, sieht der HPKP-Standard (RFC 7569) die zu­sätz­li­che Ver­wen­dung eines Back-up-Pins vor. Dieser wird ebenfalls über den HTTP-Header aus­ge­lie­fert und kann im Pro­blem­fall dazu genutzt werden, ein neues Zer­ti­fi­kat für die ent­spre­chen­de Domain aus­stel­len zu lassen. Dieser Vorgang wird als Cer­ti­fi­ca­te Signing Request (CSR; dt. „Zer­ti­fi­kat­si­gnie­rungs­an­for­de­rung“) be­zeich­net.

Tipp

Browser wie Mozilla Firefox und Google Chrome richten sich nach dem RFC-7469-Standard und igno­rie­ren daher HPKP-Header oder zeigen Feh­ler­mel­dun­gen, wenn nur ein einziger Pin gesetzt wird. Für den optimalen HPKP-Browser-Support ist es also immer notwendig, min­des­tens zwei gültige Public Keys bzw. einen Back-up-Pin anzugeben, damit die Pin-Va­li­die­rung funk­tio­niert.

Pins der Public Keys berechnen

Soll HTTP Public Key Pinning auf Ihrem Server funk­tio­niert, ist es notwendig, dass HTTPS bereits kon­fi­gu­riert ist. Da min­des­tens zwei öf­fent­li­che Schlüssel gepinnt werden müssen, steht die Ge­ne­rie­rung dieser Pins im ersten Schritt auf dem Programm. Die einfache Lösung, um die Hashwerte exis­tie­ren­der Public Keys zu errechnen, ist die Open-Source-Anwendung openssl, die Sie über die Kom­man­do­zei­le Ihres Systems nutzen können. Als Stan­dard­be­fehl für X.509-Zer­ti­fi­ka­te gibt RFC 7469 vor:

openssl x509 -noout -in certificate.pem -pubkey | \
    openssl asn1parse -noout -inform pem -out public.key
openssl dgst -sha256 -binary public.key | openssl enc -base64

Auf diese Weise erzeugen Sie für das Beispiel-Zer­ti­fi­kat cer­ti­fi­ca­te.pem die Base64-Sequenz für den Schlüssel public.key. Diese wird auf der Stan­dard­aus­ga­be aus­ge­ge­ben und endet immer auf dem Gleich­heits­zei­chen („=“).

Im nächsten Schritt richten Sie den Cer­ti­fi­ca­te Signing Request (hier: backup.csr) für Ihren Back-up-Key (hier: backup.key) ein:

openssl genrsa -out backup.key 2048
openssl req -new -key backup.key -out backup.csr

An­schlie­ßend lassen Sie sich mithilfe von openssl auch den Hashwert dieses Schlüs­sels errechnen:

openssl req -noout -in backup.csr -pubkey | \
    openssl asn1parse -noout -inform pem -out backup.key
openssl dgst -sha256 -binary backup.key | openssl enc -base64

Sicherung des Back-up-Pins

Da der HPKP-Back-up-Key den Stan­dard­schlüs­sel bei einem Ausfall ersetzen soll, ist es sinnvoll, diesen separat auf­zu­be­wah­ren. Im besten Fall wählen Sie hierfür eine externe Spei­cher­platt­form, die Sie jederzeit und von überall aus erreichen können. Ferner ist die Nutzung eines Passwort-Managers zu empfehlen: Wenn Sie den Cer­ti­fi­ca­te Signing Request und den da­zu­ge­hö­ri­gen Schlüssel mithilfe einer solchen Software zu­sätz­lich in einer eigenen Datenbank absichern, sind Sie auf der sicheren Seite – und der bzw. die Back-up-Schlüssel im ent­schei­den­den Moment zum Einsatz bereit.

Kritik an Public Key Pinning

Dank dem „Trust on First Use“-Ansatz greift HPKP bereits im Anschluss an die erste Kon­takt­auf­nah­me durch den Client. Der erste Besuch, bei dem der Server die gepinnten Keys über­mit­telt, ist jedoch durch das Verfahren selbst nicht geschützt. Diese kleine Lücke führt aber nur in Ein­zel­fäl­len zu Problemen, während eine größere Zahl un­be­merk­ter Angriffe auf die SSL/TLS-Ver­bin­dun­gen Ihres Web­pro­jekts nahezu aus­ge­schlos­sen ist. Der Haupt­kri­tik­punkt, der gegen das Public Key Pinning her­vor­ge­bracht wird, betrifft folgendes An­griffs­sze­na­rio, das erst durch den Einsatz der Pinning-Technik möglich wird:

  1. Ein Angreifer ver­schafft sich Zugriff zu Ihrem Server.
  2. Er in­stal­liert ein neues SSL/TLS-Zer­ti­fi­kat und erstellt im Anschluss ein eigenes Schlüs­sel­paar.
  3. Für den Public Key generiert er nun außerdem den passenden Hash-Wert und trägt diesen anstelle Ihrer Pins in den ent­spre­chen­den Bereich im Cer­ti­fi­ca­te-Pinning-Header ein.
  4. Anwender bzw. Clients, die Ihr Web­pro­jekt zum ersten Mal aufrufen, erhalten nun den falschen Pin und können in der Folge keine ge­si­cher­te Ver­bin­dung zu Ihrem Server aufbauen.
  5. Löscht der Angreifer das Zer­ti­fi­kat nun wieder von Ihrem Server, bleibt diesen Nutzern der Zutritt zu Ihrer Seite verwehrt, bis die Gül­tig­keits­dau­er des falschen Pins ab­ge­lau­fen ist.
  6. Außer Ihnen auf diese Weise bloßen Schaden durch den ent­ste­hen­den Traffic-Verlust zuzufügen, hat der Angreifer in der Theorie auch die Mög­lich­keit, Geld für die Freigabe des falschen Zer­ti­fi­kats zu verlangen und Sie auf diesem Weg zu erpressen.

Auch wenn dieses Szenario theo­re­tisch möglich ist, ist es noch lange kein Argument gegen den Einsatz von HTTP Public Key Pinning. Denn der Angreifer könnte die Er­wei­te­rung des HTTP-Pro­to­kolls ebenso gut selbst ein­rich­ten, sobald er sich Zugriff zum Server ver­schafft hat. Das Problem stellt letztlich nur unter Beweis, wie wichtig es ist, das Sie Ihr Projekt gegen Ha­cker­an­grif­fe schützen. Wenn Sie Pins einsetzen, sollten Sie darüber hinaus auch Ihre Mo­ni­to­ring-Software da­hin­ge­hend sen­si­bi­li­sie­ren, dass Sie bei Ver­än­de­run­gen in den HPKP-Headern umgehend in­for­miert werden, um recht­zei­tig ein­schrei­ten zu können. Ein denkbarer Lö­sungs­an­satz auf Seiten der Clients wären Pin-Reset-Me­cha­nis­men, die bekannte „bösartige“ Pins re­gel­mä­ßig löschen.

Andere negative Kri­tik­punk­te sind zumeist die geringe Ver­brei­tung und die Kom­ple­xi­tät, die mit der Kon­fi­gu­ra­ti­on des Public Key Pinnings verbunden ist. Die Ursachen hierfür liegen ver­mut­lich vor allem darin, dass der Standard häufig nur schlecht bzw. gar nicht bekannt ist.

Zum Hauptmenü