Anzeige
Webseiten können Schlüssel künftig mittels Key Pinning festnageln.
Webseiten können Schlüssel künftig mittels Key Pinning festnageln. (Bild: Schumi4ever, WikimediaCommons, CC by-sa 3.0)

HTTPS-Zertifikate: Key Pinning schützt vor bösartigen Zertifizierungsstellen

Eine bislang wenig beachtete HTTPS-Erweiterung mit dem Namen HTTP Public Key Pinning (HPKP) steht kurz vor ihrer Standardisierung. Durch Public Key Pinning könnten viele Probleme mit den Zertifizierungsstellen gelöst werden.

Anzeige

Im Moment ist es noch ein Entwurf, in Kürze wird es wohl ein offizieller Standard der Internet Engineering Task Force (IETF): Mit HTTP Public Key Pinning, abgekürzt HPKP, steht dann eine Technologie zur Verfügung, die viele Probleme mit dem System der Zertifizierungsstellen lösen könnte.

Zertifizierungsstellen oder CAs (Certificate Authorities) stellen kryptographische Zertifikate aus, mit denen anschließend Webseiten oder andere Netzverbindungen mittels TLS abgesichert werden können. Ein Zertifikat gewährleistet, dass der Nutzer bei einer Verbindung zu einer bestimmten Domain - etwa www.google.com - auch tatsächlich mit der richtigen Adresse verbunden ist und nicht mit einer Fälschung.

System der Zertifizierungsstellen in Verruf geraten

Doch das CA-System ist in Verruf geraten. Zuletzt hatte die Firma India CCA zahlreiche gefälschte Zertifikate ausgestellt. India CCA war kein Einzelfall. In den vergangenen Jahren haben zahlreiche Zertifizierungsstellen gefälschte Zertifikate ausgestellt: So beispielsweise die niederländische Firma Diginotar, die daraufhin Konkurs anmelden musste. Comodo, eine der größten Netz-Zertifizierungsstellen, musste 2011 ebenfalls eingestehen, dass die Firma zahlreiche illegitime Zertifikate ausgestellt hatte. Sie wurden vermutlich von der iranischen Regierung für Man-in-the-Middle-Angriffe eingesetzt. Während Diginotar Konkurs ging, hatte der Vorfall für Comodo keinerlei negativen Konsequenzen.

Das Grundproblem des gesamten Systems der Zertifizierungsstellen: Gängige Browser vertrauen automatisch mehreren hundert Zertifizierungsstellen. Jede einzelne davon kann theoretisch nach Belieben gefälschte Zertifikate für fremde Webseiten ausstellen. Jede Zertifizierungsstelle ist zudem in der Lage, Unterzertifizierungsstellen zu ernennen. Auch diese werden anschließend von Browsern automatisch erkannt.

Vorschläge für Alternativen zum System der Zertifizierungsstellen oder Ansätze, die Situation zu verbessern, gab es bereits einige. Convergence, Sovereign Keys oder TACK sind derartige Projekte, die jedoch alle eines gemeinsam haben: Sie konnten sich nicht bislang durchsetzen.

Google akzeptiert seit einiger Zeit im Chrome-Browser für bestimmte Webseiten nicht mehr jedes Zertifikat. Der Browser greift auf eine Liste von Seiten zu, bei denen ein Zertifikat oder eine bestimmte Zertifizierungsstelle voreingestellt ist. Mozilla hat dies mit der jüngsten Version ebenfalls eingeführt. Doch während diese Methode für große Webseiten eine mögliche Lösung darstellt, sind kleinere Webseitenbetreiber davon bislang ausgeschlossen. Hier setzt HTTP Public Key Pinning an.

HTTP Public Key Pinning schafft Abhilfe

Die HTTP-Erweiterung Public Key Pinning wurde federführend von Google-Mitarbeitern entwickelt und nutzt einen relativ simplen Mechanismus, um die Sicherheit von HTTPS-Zertifikaten zu verbessern: Mittels eines HTTP-Headers kann der Betreiber einer Webseite einen Pin mitschicken. Dabei handelt es sich um Hashes von kryptographischen Schlüsseln und einen Zeitwert. Wenn der Browser das Pinning unterstützt, speichert er diese Information und akzeptiert fortan nur noch Verbindungen, bei denen das Zertifikat einen der gepinnten Schlüssel nutzt. Alternativ kann eine Webseite auch einen Pin für den Schlüssel einer Zertifizierungsstelle setzen. Es muss lediglich ein verwendetes Zertifikat in der Vertrauenskette mit dem Pin übereinstimmen.

Ein Beispiel für einen derartigen Pin ist folgende Headerzeile: Public-Key-Pins:

Public-Key-Pins: max-age=5184000; pin-sha256="jYEKhFo1FULVqIk/Nph3hu1SDWhifZamgYGxnk3Zuys="; pin-sha256="h0h88SscIXy94RvNI7O2CDUpuCwXL1WvX1jH8Hb1/9A="; includeSubdomains; report-uri="https://example.com/hpkp.php"

Die Angabe "max-age" definiert in Sekunden, wie lange ein Pin gültig ist, empfohlen wird ein Wert von 60 Tagen. Bei den beiden Pin-Werten handelt es sich um eine BASE64-codierung des entsprechenden SHA256-Hashes über den verwendeten öffentlichen Schlüssel. Mit dem Befehl "includeSubdomains" lässt sich angeben, dass der Pin auch für Subdomains gelten soll.

Die Erstellung der passenden SHA256-Hashes ist unter Linux mit einigen simplen Kommandozeilenbefehlen möglich, der Autor dieses Artikels hat auf Github ein entsprechendes Skript bereitgestellt, mit dem sich Pins für die öffentlichen Schlüssel von Zertifikaten erstellen lassen.

Eine weitere interessante Funktion ist die Möglichkeit, eine URL anzugeben, an die im Falle eines fehlerhaften Zertifikats eine Meldung geschickt wird. Falls ein Browser eine HTTPS-Verbindung bekommt, für die ein Pin existiert und die kein mit dem Pin übereinstimmendes Zertifikat ausliefert, wird an die über report-uri angegebene Adresse ein JSON-codierter Fehlerbericht gesendet. Der Vorteil für den Webseitenbetreiber: Sollte ein Angriff auf die Besucher der eigenen Webseite stattfinden, bestehen gute Chancen, dass man davon erfährt. Zuverlässig ist das Feature allerdings nicht: Bei Man-in-the-Middle-Angriffen kann der Angreifer verhindern, dass ein entsprechender Fehlerbericht versendet wird.

Angriff nur noch beim ersten Seitenaufruf 

eye home zur Startseite
Vanger 10. Nov 2014

Jede Stelle im DNS-Baum hat bei DNSSEC grundsätzlich Kontrolle über alle ihm...

nudel 17. Okt 2014

Außerdem fallen so, durch Mitteilung des aktuellen Zertifikats und der zukünftigen...

hannob (golem.de) 14. Okt 2014

Ja, werden sie, im Prinzip überall wo TLS/SSL genutzt wird. Beispielsweise für POP3...

heutger 14. Okt 2014

Diginotar hat das Ausmaß der Fehlausstellungen stets heruntergespielt, Comodo wurde...

nicoledos 14. Okt 2014

Wenn die Zertifizierungsstellen diese Ausgeben sind diese möglicherweise Falsch, aber...

Kommentieren



Anzeige

  1. Software Engineer - Javascript Entwickler (m/w)
    Mindlab Solutions GmbH, Stuttgart
  2. ITK-Administrator/in
    Stadt Soltau, Soltau
  3. Softwareentwickler (m/w) (JavaEE)
    XClinical GmbH, München
  4. Entwickler (m/w) für mobile Applikationen
    ckc group, Region Wolfsburg/Braunschweig

Detailsuche



Anzeige

Folgen Sie uns
       


  1. Java-Rechtsstreit

    Oracle verliert gegen Google

  2. Photoshop Content Aware Crop

    Schiefe Fotos geraderücken

  3. HP Omen

    4K-Gaming-Notebooks und ein wassergekühlter Desktop-Rechner

  4. 100 MBit/s

    Telekom stattet zwei Städte mit Vectoring aus

  5. Sprachassistent

    Voßhoff will nicht mit Siri sprechen

  6. Sailfish OS

    Jolla bringt exklusives Smartphone nur für Entwickler

  7. Projektkommunikation

    Tausende Github-Nutzer haben Kontaktprobleme

  8. Lebensmittel-Lieferdienst

    Amazon Fresh soll doch in Deutschland starten

  9. Buglas

    Verband kritisiert Rückzug der Telekom bei Fiber To The Home

  10. Apple Store

    Apple darf keine Geschäfte in Indien eröffnen



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Doom im Test: Die beste blöde Ballerorgie
Doom im Test
Die beste blöde Ballerorgie
  1. id Software Doom wird Vulkan unterstützen
  2. Id Software PC-Spieler müssen 45 GByte von Steam laden
  3. id Software Dauertod in Doom

Darknet: Die gefährlichen Anonymitätstipps der Drogenhändler
Darknet
Die gefährlichen Anonymitätstipps der Drogenhändler
  1. Privatsphäre 1 Million Menschen nutzen Facebook über Tor
  2. Security Tor-Nutzer über Mausrad identifizieren

Privacy-Boxen im Test: Trügerische Privatheit
Privacy-Boxen im Test
Trügerische Privatheit
  1. Hack von Rüstungskonzern Schweizer Cert gibt Security-Tipps für Unternehmen
  2. APT28 Hackergruppe soll CDU angegriffen haben
  3. Veröffentlichung privater Daten AfD sucht mit Kopfgeld nach "Datendieb"

  1. Re: Liebe Redaktion

    oxybenzol | 08:19

  2. Re: Preisfrage

    GrandmasterA | 08:17

  3. Re: Schönes Strohfeuer

    Ach | 08:15

  4. Re: Wirklich, ja?

    RicoBrassers | 08:13

  5. Wer USB-Ladegeräte immer drin stecken lässt...

    Lala Satalin... | 08:12


  1. 08:25

  2. 07:43

  3. 07:15

  4. 19:05

  5. 17:50

  6. 17:01

  7. 14:53

  8. 13:39


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel