Chrome: Strengere Regeln für TLS-Zertifikate

Googles Browser wird künftig Nutzer bei Zertifikaten mit kurzen Schlüsseln und anderen Problemen warnen. Auch eine neue Technologie namens Certificate Transparency, die betrügerische Zertifizierungsstellen identifiziert, soll bald genutzt werden.

Artikel veröffentlicht am 27. September 2013, 13:23 Uhr, Hanno Böck

Chrome ist künftig strenger bei TLS-Zertifikaten. (Bild: Google)

Google hat angekündigt, einige Veränderungen im Browser Chrome vorzunehmen, die die Sicherheit von SSL-/TLS-Zertifikaten erhöhen sollen. Das kündigte Google-Mitarbeiter Ryan Sleevi auf der Mailingliste des CA/Browser-Forums an. Das CA/Browser-Forum ist ein Gremium, in dem sich fast alle relevanten Browserhersteller und die in den Browsern mitgelieferten Zertifizierungsstellen (CAs) koordinieren.

Demnach will Google künftig prüfen, ob Zertifikate von HTTPS-Seiten die sogenannten Baseline Requirements des CA/Browser-Forums erfüllen. Eine der wichtigsten Änderungen ist vermutlich die Länge der RSA-Schlüssel. Ab 2014 wird Chrome eine Warnung anzeigen, wenn Zertifikate mit einer Schlüssellänge unter 2.048 Bit genutzt werden.

Warnungen vor RSA-Schlüssellängen mit einer Länge von 1.024 Bit gibt es schon seit etwa zehn Jahren. Die US-Behörde Nist hatte bereits seit Jahren empfohlen, die Nutzung von solch kurzen Schlüsseln spätestens 2010 zu beenden. Doch das hielt die Zertifizierungsstellen nicht davon ab, noch lange Zeit deutlich kürzere Schlüssel einzusetzen. 2010 fand ein Forschungsprojekt der Electronic Frontier Foundation sogar noch zahlreiche Schlüssel mit 512 oder 768 Bit.

Eine Ausnahme gibt es allerdings: Bei den Root-Zertifikaten wird Google 1.024 Bit weiterhin akzeptieren. Die Root-Zertifikate gelten üblicherweise deutlich länger als gewöhnliche Webseitenzertifikate. Insofern gestaltet sich dort die Umstellung als langwierig und einige Zertifizierungsstellen haben ihre Root-Zertifikate noch nicht auf längere Schlüssel umgestellt. Sonderlich glücklich ist man bei Google damit allerdings nicht. Vorsorglich kündigt Sleevi bereits an, dass Zertifizierungsstellen, die weiterhin auf kurze Schlüssel setzen, damit rechnen müssen, in Zukunft aus dem Chrome-Browser entfernt zu werden.

Eine weitere Änderung: Die Baseline Requirements beschränken die maximale Gültigkeitsdauer von Zertifikaten auf fünf Jahre. Außerdem werden Zertifikate, bei denen keine Möglichkeit der Gültigkeitsprüfung über das Protokoll OCSP bestehen, nicht mehr akzeptiert.

Die Baseline Requirements gelten eigentlich für alle im CA/Browser-Forum zusammengeschlossenen Zertifizierungsstellen seit Juli 2013. Jedoch listet die Webseite Netcraft eine ganze Reihe von Fällen auf, in denen Zertifizierungsstellen die Baseline Requirements seitdem verletzt haben. Ironisch dabei: Selbst Google hat noch in jüngster Zeit Zertifikate genutzt, die keine OCSP-Gültigkeitsprüfung ermöglichten und damit genau die Regeln verletzt, die man jetzt strenger durchsetzen möchte.

Weiterhin kündigt Google an, die Unterstützung des Protokolls Certificate Transparency in Zukunft vorauszusetzen. Allerdings gibt es hierfür noch keinen festen Zeitplan, zunächst soll sich die Überprüfung auch auf sogenannte Extended-Validation-Zertifikate beschränken. Certificate Transparency soll dazu dienen, Zertifizierungsstellen zu identifizieren, die böswillig Zertifikate ausstellen.

Die Idee dabei: In einem für jeden einsehbaren Log-System sollen alle Zertifikate registriert werden. Diese werden von Log-Servern verwaltet. Nur öffentlich registrierte Zertifikate sind auch gültig. Es soll dabei insbesondere unmöglich sein, Zertifikate nachträglich aus dem Log zu entfernen oder welche einzufügen. Wenn eine Zertifizierungsstelle nun böswillig ein Zertifikat ausstellt, welches etwa zur Überwachung von Nutzern eingesetzt wird, lässt sich dies zwar nicht direkt verhindern, es lässt sich jedoch auch nicht geheim halten.

Das Konzept der Certificate Transparency mit einem öffentlich einsehbaren Log hat gewisse Ähnlichkeiten mit einem früheren Vorschlag der Electronic Frontier Foundation namens Sovereign Keys, der jedoch nie umgesetzt wurde.