• IT-Karriere:
  • Services:

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.

Artikel veröffentlicht am , Hanno Böck
Chrome warnt vor einer Verbindung - allerdings nicht in der Standardeinstellung.
Chrome warnt vor einer Verbindung - allerdings nicht in der Standardeinstellung. (Bild: Screenshot Golem.de)

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.

Stellenmarkt
  1. Schoeller Technocell GmbH & Co. KG, Osnabrück
  2. ABENA GmbH, Zörbig

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.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed


Anzeige
Spiele-Angebote
  1. 1,07€
  2. 1,99€
  3. (-70%) 4,80€
  4. 47,49€

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...


Folgen Sie uns
       


Apples Airpods 2 und Samsungs Galaxy Buds im Test

Wir haben die neuen Airpods von Apple mit den Galaxy Buds von Samsung verglichen. Beim Klang schneiden die Airpods 2 wieder sehr gut ab. Es bleibt der Nachteil, dass Android-Nutzer die Airpods nur eingeschränkt nutzen können. Umgekehrt können iPhone-Nutzer die Galaxy Buds nur mit Beschränkungen verwenden. Die Galaxy Buds haben eine ungewöhnlich lange Akkulaufzeit.

Apples Airpods 2 und Samsungs Galaxy Buds im Test Video aufrufen
Starlink: SpaceX steht zwischen Flaute und Rekordjagd
Starlink
SpaceX steht zwischen Flaute und Rekordjagd

Die nächsten 60 Starlink-Satelliten stehen zum Start bereit, nachdem in diesem Jahr ungewöhnlich wenige Raketen gestartet sind - nicht nur von SpaceX. Die Flaute hat SpaceX selbst verursacht und einen Paradigmenwechsel in der Raumfahrt eingeläutet.
Von Frank Wunderlich-Pfeiffer

  1. Raumfahrt SpaceX testet Notfalltriebwerke des Crew Dragon
  2. Starship Mit viel Glück nur 6 Monate bis zum ersten Flug ins All
  3. SpaceX Das Starship nimmt Form an

Bosch-Parkplatzsensor im Test: Ein Knöllchen von LoRa
Bosch-Parkplatzsensor im Test
Ein Knöllchen von LoRa

Immer häufiger übernehmen Sensoren die Überwachung von Parkplätzen. Doch wie zuverlässig ist die Technik auf Basis von LoRa inzwischen? Golem.de hat einen Sensor von Bosch getestet und erläutert die Unterschiede zum Parking Pilot von Smart City System.
Ein Test von Friedhelm Greis

  1. Automated Valet Parking Daimler und Bosch dürfen autonom parken
  2. Enhanced Summon Teslas sollen künftig ausparken und vorfahren

Autonomes Fahren: Wenn der Wagen das Volk nicht versteht
Autonomes Fahren
Wenn der Wagen das Volk nicht versteht

VW testet in Hamburg das vollautonome Fahren in der Stadt - und das recht erfolgreich, wie eine Probefahrt zeigt. Als größtes Problem erweist sich ausgerechnet die Höflichkeit der Fußgänger.
Ein Bericht von Werner Pluta

  1. Volkswagen ID. Space Vizzion als Elektrokombi vorgestellt
  2. Elektroauto von VW Es hat sich bald ausgegolft
  3. ID.3 kommt Volkswagen verkauft den E-Golf zum Schnäppchenpreis

    •  /