Abo
  • IT-Karriere:

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. Dataport, verschiedene Einsatzorte
  2. acarda GmbH, Frankfurt am Main

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.



Anzeige
Top-Angebote
  1. (u. a. Tropico 6 für 24,99€, PSN Card 10€ für 9,49€, PSN Card 20€ für 18,99€)
  2. (u. a. Switch-Spiele: Daemon X Machina für 49,99€, The Legend of Zelda: Link's Awakening; PS4...
  3. GRATIS im Ubisoft-Sale
  4. 329,00€

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
       


Linux für Gaming installieren - Tutorial

Die Linux-Distribution Manjaro eignet sich gut für Spiele - wir erklären im Video wie man sie installiert.

Linux für Gaming installieren - Tutorial Video aufrufen
Indiegames-Rundschau: Epische ASCII-Abenteuer und erlebnishungrige Astronauten
Indiegames-Rundschau
Epische ASCII-Abenteuer und erlebnishungrige Astronauten

In Stone Story RPG erwacht ASCII-Art zum Leben, die Astronauten in Oxygen Not Included erleben tragikomische Slapstick-Abenteuer, dazu kommen Aufbaustrategie plus Action und Sammelkartenspiele: Golem.de stellt neue Indiegames vor.
Von Rainer Sigl

  1. Indiegames-Rundschau Von Bananen und Astronauten
  2. Indiegames-Rundschau Verloren im Sonnensystem und im Mittelalter
  3. Indiegames-Rundschau Drogen, Schwerter, Roboter-Ritter

Smarte Wecker im Test: Unter den Blinden ist der Einäugige König
Smarte Wecker im Test
Unter den Blinden ist der Einäugige König

Einen guten smarten Wecker zu bauen, ist offenbar gar nicht so einfach. Bei Amazons Echo Show 5 und Lenovos Smart Clock fehlen uns viele Basisfunktionen. Dafür ist einer der beiden ein besonders preisgünstiges und leistungsfähiges smartes Display.
Ein Test von Ingo Pakalski

  1. Nest Hub im Test Google vermasselt es 1A

Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

    •  /