Abo
  • Services:
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...



Anzeige

Stellenmarkt
  1. MBtech Group GmbH & Co. KGaA, Regensburg / Neutraubling
  2. afb Application Services AG, München
  3. Haufe Akademie GmbH & Co. KG, Freiburg im Breisgau
  4. Hanse Orga AG, Hamburg


Anzeige
Top-Angebote
  1. 49,97€
  2. 110,00€

Folgen Sie uns
       

Anzeige
Whitepaper
  1. Mit digitalen Workflows Geschäftsprozesse agiler machen
  2. Kritische Bereiche der IT-Sicherheit in Unternehmen
  3. Tipps für IT-Engagement in Fernost


  1. Autonomes Fahren

    Suchmaschinenkonzern Yandex baut fahrerlosen Bus

  2. No Man's Sky

    Steam wehrt sich gegen Erstattungen

  3. Electronic Arts

    Battlefield 1 setzt Gold, aber nicht Plus voraus

  4. Kaby Lake

    Intel stellt neue Chips für Mini-PCs und Ultrabooks vor

  5. Telefonnummern für Facebook

    Threema profitiert von Whatsapp-Datenaustausch

  6. Browser

    Google Cast ist nativ in Chrome eingebaut

  7. Master of Orion im Kurztest

    Geradlinig wie der Himmelsäquator

  8. EU-Kommission

    Apple soll 13 Milliarden Euro an Steuern nachzahlen

  9. Videocodec

    Für Netflix ist H.265 besser als VP9

  10. Weltraumforschung

    DFKI-Roboter soll auf dem Jupitermond Europa abtauchen



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Avegant Glyph aufgesetzt: Echtes Kopfkino
Avegant Glyph aufgesetzt
Echtes Kopfkino

Next Gen Memory: So soll der Speicher der nahen Zukunft aussehen
Next Gen Memory
So soll der Speicher der nahen Zukunft aussehen
  1. Arbeitsspeicher DDR5 nähert sich langsam der Marktreife
  2. SK Hynix HBM2-Stacks mit 4 GByte ab dem dritten Quartal verfügbar
  3. Arbeitsspeicher Crucial liefert erste NVDIMMs mit DDR4 aus

Wiper Blitz 2.0 im Test: Kein spießiges Rasenmähen mehr am Samstag (Teil 2)
Wiper Blitz 2.0 im Test
Kein spießiges Rasenmähen mehr am Samstag (Teil 2)
  1. Softrobotik Oktopus-Roboter wird mit Gas angetrieben
  2. Warenzustellung Schweizer Post testet autonome Lieferroboter
  3. Lockheed Martin Roboter Spider repariert Luftschiffe

  1. Re: Wie bescheuert muss man eigentlich sein

    NaruHina | 22:39

  2. Re: Warum berichtet ihr eigentlich nicht von Wire?

    Wallbreaker | 22:38

  3. Re: Wann kommt die Marktbereinigung?

    bplhkp | 22:36

  4. Re: Dumpingpreise

    Mingfu | 22:32

  5. Re: Energieversorgung?

    Snooozel | 22:31


  1. 17:39

  2. 17:19

  3. 15:32

  4. 15:01

  5. 14:57

  6. 14:24

  7. 14:00

  8. 12:59


  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