Abo
  • Services:
Anzeige
Chrome warnt vor einer Verbindung - allerdings nicht in der Standardeinstellung.
Chrome warnt vor einer Verbindung - allerdings nicht in der Standardeinstellung. (Bild: Screenshot Golem.de)

Revocation: Zurückziehen von Zertifikaten bringt wenig

Im Zuge von Heartbleed sollen Serverbetreiber ihre Zertifikate erneuern und die alten zurückziehen. Das Problem dabei: Das bringt fast nichts, denn kein einziger Browser prüft die Gültigkeit der Zertifikate auf sichere Weise.

Anzeige

Seit kurzem ist klar: Das Auslesen der privaten Schlüssel von Servern mit Hilfe von Heartbleed ist nicht nur ein theoretisches Problem. Deshalb sollte zumindest bei sicherheitskritischen Serverdiensten, die mit TLS geschützt sind, ein Austausch der Zertifikate stattfinden und die alten Zertifikate sollten zurückgezogen ("revoked") werden. Doch die Sache hat einen Haken: Es gibt im Moment kein funktionierendes System, mit dem die Gültigkeit von X.509-Zertifikaten geprüft werden kann.

Zwar prüfen einige Browser die Gültigkeit von Zertifikaten mit dem OCSP-Protokoll. Doch ein Angreifer, der mit Hilfe des zurückgezogenen Zertifikats und einem geklauten privaten Schlüssel eine Man-in-the-Middle-Attacke durchführt, kann diese Prüfung einfach unterbinden, indem er die Verbindung zum Server der Zertifizierungsstelle blockiert.

Für die Gültigkeitsprüfung von Zertifikaten gibt es zwei Technologien: CRL (Certificate Revocation List) und OCSP (Online Certificate Status Protocol). Das Vorgehen bei CRL ist relativ simpel: Zertifizierungsstellen halten eine Liste von zurückgezogenen und damit ungültigen Zertifikaten vor, eine Client-Anwendung - beispielsweise ein Browser - kann diese Liste herunterladen und prüfen. Die CRL-Listen sind dabei mit dem Zertifikat der Zertifizierungsstelle signiert. Dabei besteht ein naheliegendes Problem: Bei großen Zertifizierungsstellen kann so eine CRL schnell Tausende oder gar Millionen von Einträgen umfassen. Eine Prüfung der Listen ist schon aus Performancegründen schwierig.

Deshalb wurde das OCSP-Protokoll eingeführt. Die Idee dabei: Ein Client fragt beim Verbindungsaufbau bei einem speziellen OCSP-Server nach, ob ein Zertifikat noch gültig ist und erhält eine signierte Antwort. Daraus ergibt sich zunächst naheliegenderweise ein Datenschutzproblem: Die Zertifizierungsstelle erfährt, von welcher IP-Adresse aus welche TLS-geschützten Webseiten zu welchem Zeitpunkt angesurft werden.

Doch es gibt sowohl bei CRL als auch bei OCSP ein viel gravierenderes Problem: Die Server der Zertifizierungsstellen müssen jederzeit zuverlässig auf Anfragen antworten. Ausfälle darf es kaum geben. Ein Browser müsste dann, falls er den OCSP- oder CRL-Server nicht erreicht, das entsprechende Zertifikat als ungültig ansehen und einen Verbindungsaufbau via HTTPS verweigern.

Doch es gibt auch Situationen, in denen die Gültigkeitsprüfung überhaupt nicht stattfinden kann. Ein Beispiel sind die Login-Portale von vielen WLAN-Zugängen, die sich etwa in Hotels und auf Bahnhöfen oft finden. Man wird zunächst auf eine Login-Seite des Anbieters weitergeleitet und kann sich dort entweder mit seinen Zugangsdaten einloggen oder einen zeitweisen Netzzugang kaufen. Diese Login-Seiten sind sinnigerweise oft ebenfalls mit HTTPS geschützt, doch zum Zeitpunkt, zu dem diese aufgerufen werden, besteht noch kein Zugang zum Internet und die Gültigkeitsprüfung schlägt immer fehl.

In der Praxis hat sich daher erwiesen, dass eine strenge Gültigkeitsprüfung zu viele Probleme verursacht. Alle Browser haben daher OCSP nur auf unsichere Weise implementiert: Wenn der Check keine Antwort vom Server erhält, wird das Zertifikat weiterhin als gültig angesehen. Doch damit ist die Sicherheit von OCSP komplett untergraben. Denn OCSP soll ja davor schützen, dass ein Angreifer mit einem zurückgezogenen Zertifikat, zu dem er den privaten Schlüssel geklaut hat, einem Nutzer eine falsche Webseite vorgaukeln kann - ein klassischer Man-in-the-Middle-Angriff. Ein Angreifer kann natürlich auch die Verbindungen zum OCSP-Server schlicht verhindern und ins Leere laufen lassen.

Die Entwickler von Google haben daher vor einiger Zeit schon eine pragmatische Lösung gewählt: Wenn OCSP sowieso keine Sicherheit bietet, kann man es auch abschalten. Die Prüfung lässt sich manuell wieder aktivieren ("Serverzertifikate auf Sperrung prüfen" unter den erweiterten Einstellungen). Wir haben allerdings keine Möglichkeit gefunden, OCSP in Chrome so zu konfigurieren, dass bei Nichterreichbarkeit der OCSP-Server ein Zertifikat als ungültig angesehen wird.

In Firefox ist der OCSP-Check standardmäßig auf unsichere Weise aktiviert. Firefox lässt sich aber auch so konfigurieren, dass bei einem Fehlschlagen der Verbindung ein Zertifikat abgelehnt wird (unter "Erweitert", "Zertifikate", "Validierung"). Microsoft hat im Internet Explorer ebenfalls eine unsichere OCSP-Prüfung aktiviert. Ursprünglich wurden Nutzer gewarnt, wenn die Verbindung zum OCSP-Server fehlschlägt. In einem Blogeintrag von 2011 schreibt Microsoft dazu, dass man dies wieder deaktiviert hat, weil zu viele Warnungen auftraten und man Nutzern keine sinnvollen Ratschläge geben konnte, was sie in so einem Fall tun sollten. Die Warnung lässt sich manuell wieder aktivieren.

Fazit bleibt also, dass einige Browser zwar die Gültigkeit der Zertifikate prüfen, aber die Prüfung weitgehend nutzlos ist, weil sie bei einem gezielten Angriff verhindert werden kann und das Zertifikat dann trotzdem akzeptiert wird.

Etwas Abhilfe schaffen könnte ein Protokoll namens OCSP Stapling. Die Idee dabei: Nicht der Nutzer fragt bei der Zertifizierungsstelle an, sondern der Server selbst. Die signierte Antwort der Zertifizierungsstelle gilt dabei nur für einen kurzen Zeitraum, beispielsweise zwei Stunden. Sie wird vom Server gespeichert und dem Nutzer beim TLS-Handshake mitgeliefert. OCSP Stapling löst dabei mehrere Probleme: Zum einen ist das Protokoll deutlich datenschutzfreundlicher, da keine Verbindung vom Nutzer zur Zertifizierungsstelle mehr stattfindet. Zum anderen sind kurze Ausfälle des OCSP-Servers seltener ein Problem. Außerdem funktioniert OCSP Stapling auch, wenn keine direkte Verbindung vom Nutzer zur Zertifizierungsstelle möglich ist, wie beim oben genannten Beispiel der WLAN-Loginseiten.

Würden viele Server OCSP Stapling einsetzen, wäre es möglicherweise realistisch, dass die Browser eine strengere Zertifikatsprüfung aktivieren. Doch die Verbreitung ist gering. Der meistverwendete Webserver Apache unterstützt OCSP Stapling erst mit der bislang noch wenig verbreiteten Version 2.4 und auch dort muss es manuell aktiviert werden. Laut einer Erhebung von Netcraft im vergangenen Jahr nutzen die meisten Server, die OCSP Stapling aktivieren, IIS von Microsoft, denn dort ist es seit Windows 2008 standardmäßig aktiviert.

Eine Möglichkeit zur besseren Prüfung von Zertifikaten wäre auch, wenn das Zertifikat dem Client signalisiert, dass OCSP Stapling genutzt werden muss. Der Browser könnte diese Information dann auswerten und eine Verbindung verweigern, wenn keine OCSP-Stapling-Information mitgeschickt wurde. Für ein entsprechendes Protokoll existiert jedoch bislang nur ein Entwurf.


eye home zur Startseite
MrCrankHank 22. Apr 2014

Ich bin zwar kein Experte auf dem Gebiet, aber hat das neue Zertifikat nicht einen...

Dopeusk18 14. Apr 2014

Ich frag mich jedesmal wenn ich ein SSL cert kaufe wie dieser preis zu stande kommt, da...

hannob (golem.de) 14. Apr 2014

DNSSEC hat ein paar Probleme die man erstmal lösen müsste. 1. Es benutzt keiner. Finde...

hannob (golem.de) 14. Apr 2014

Ich hab die Erklärung im Artikel jetzt etwas ausführlicher gemacht, hoffe es wird so...

Mingfu 14. Apr 2014

Was soll das bringen? OCSP kann man auch ohne Addon im Firefox einfach in den...



Anzeige

Stellenmarkt
  1. Bundesdruckerei GmbH, Berlin
  2. Winkelmann Group GmbH + Co. KG, Ahlen
  3. Fresenius Medical Care Deutschland GmbH, Bad Homburg
  4. Rohde & Schwarz Cybersecurity GmbH, Leipzig


Anzeige
Spiele-Angebote
  1. 64,97€/69,97€
  2. (-78%) 8,99€
  3. 29,99€

Folgen Sie uns
       


  1. VLC, Kodi, Popcorn Time

    Mediaplayer können über Untertitel gehackt werden

  2. Engine

    Unity bekommt 400 Millionen US-Dollar Investorengeld

  3. Neuauflage

    Neues Nokia 3310 soll bei Defekt komplett ersetzt werden

  4. Surface Studio

    Microsofts Grafikerstation kommt nach Deutschland

  5. Polar

    Fitnesstracker A370 mit Tiefschlaf- und Pulsmessung

  6. Schutz

    Amazon rechtfertigt Sperrungen von Marketplace-Händlern

  7. CPU-Architektur

    RISC-V-Patches für Linux erstmals eingereicht

  8. FSP Hydro PTM+

    Wassergekühltes PC-Netzteil liefert 1.400 Watt

  9. Matebook X und E im Hands on

    Huawei kann auch Notebooks

  10. Celsius-Workstations

    Fujitsu bringt sichere Notebooks und kabellose Desktops



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Quantencomputer: Nano-Kühlung für Qubits
Quantencomputer
Nano-Kühlung für Qubits
  1. IBM Q Mehr Qubits von IBM
  2. Quantencomputer Was sind diese Qubits?
  3. Verschlüsselung Kryptographie im Quantenzeitalter

Tado im Langzeittest: Am Ende der Heizperiode
Tado im Langzeittest
Am Ende der Heizperiode
  1. Speedport Smart Telekom bringt Smart-Home-Funktionen auf den Speedport
  2. Tapdo Das Smart Home mit Fingerabdrücken steuern
  3. Mehr Möbel als Gadget Eine Holzfernbedienung für das Smart Home

Blackberry Keyone im Test: Tolles Tastatur-Smartphone hat zu kurze Akkulaufzeit
Blackberry Keyone im Test
Tolles Tastatur-Smartphone hat zu kurze Akkulaufzeit
  1. Blackberry Keyone kommt Mitte Mai
  2. Keyone Blackberrys neues Tastatur-Smartphone kommt später
  3. Blackberry Keyone im Hands on Android-Smartphone mit toller Hardware-Tastatur

  1. Re: Unity ist auch eine vergleichsweise gute Engine

    Hakuro | 07:18

  2. Schon bezeichnend das illegale Addons in Kodi...

    StefanGrossmann | 07:09

  3. Re: sehr interessant

    nille02 | 07:08

  4. Re: Unix, das Betriebssystem von Entwicklern, für...

    ML82 | 07:06

  5. Re: Marketing scheint bei Unity ein besonders...

    Hakuro | 06:57


  1. 18:58

  2. 18:20

  3. 17:59

  4. 17:44

  5. 17:20

  6. 16:59

  7. 16:30

  8. 15:40


  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