Falsche Zertifikate: Schutz gegen künftige "Diginotare"

Eine Erweiterung des http-Headers um einen Fingerprint ihrer Zertifikate soll Inhalteanbieter künftig besser gegen die Verbreitung falscher Zertifikate schützen.

In Pocket speichern vorlesen Druckansicht 42 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Monika Ermert
  • Daniel Bachfeld

Eine Erweiterung des http-Headers um einen Fingerprint ihrer Zertifikate soll Inhalteanbieter künftig besser gegen die Verbreitung falscher Zertifikate schützen. Beim Treffen der Internet Engineering Task Force (IETF) in Taipei stellte Google Entwickler Ian Fette die in Chrome erprobte Maßnahme vor. Weil Chrome den Hash der für Google gültigen Zertifikate fest eingebaut hatte, flogen beispielsweise die falschen DigiNotar-Zertifikate bei Chrome-Nutzern auf. Bei der gehackten und inzwischen liquidierten Zertifizierungsstelle waren im Juli diesen Jahres über fünfhundert falsche Zertfikate für Unternehmen wie Google und verschiedene Geheimdienste ausgestellt worden.

Nach der Affäre seien andere Unternehmen mit der Bitte nach einem Schutz vor falschen Zertifikaten auf Google zugekommen, erzählte Fette. Da es Zertifikatsstellen wie Sand am Meer gibt, seien ähnliche Falschausstellungen immer wieder möglich. Der feste Einbau der Zertifizierungpolitik aller möglichen Seiten in die Browser skaliere aber nicht, sagte Fette. Daher werben er und seine Kollegen Chris Evans und Chris Palmer für ein „dynamisches Pinning öffentlicher Schlüssel“.

Bei der http-Header Lösung wird laut dem Entwurf ein Hash des „SubjectPublicKeyInfo“-Felds eines X509-Zertifikats als Header-PIN an die Nutzer ausgegeben. Denkbar sind laut Fette nicht nur Hashes der für die jeweiligen Seite geltenden Zertifikate, sondern auch Hashes der Root-Zertifikate der für die Seite aktiven Zertifizierungsstellen. Für eine eingetragene Gültigkeitsdauer werden Anfragen dann jeweils darauf geprüft, ob mindestens ein korrekter „Pin“ und ein „Back-up Pin“ vorhanden ist. Eine reibungsfreie TLS-Verbindung ist Grundbedingung, erst danach soll gepinnt werden.

Je nachdem wie häufig ein Anbieter an seiner Zertifikatspolitik etwas ändern will, wählt er eine kürzere oder längere Geltungszeit für seine Pins. Sehr kurze Gültigkeitsdauern von nur wenigen Stunden machen laut Experten wenig Sinn, zumal das erste Abfragen der Pins ein kritischer Punkt ist. Das ganze sei aber, so Fette, von den Administratoren der jeweiligen Seiten relativ leicht zu implementieren. Endnutzer würden abgesehen von einem Browserupdate erst dann etwas von der Funktionalität bemerken, wenn sie eine Warnmeldung über einen falschen oder fehlenden PIN bekommen. Fette versicherte, das Pinning verlangsame die Antworten praktisch nicht. Das Risiko, dass sich Server durch die Ausgabe falscher Pins komplett unerreichbar machen, ist allerdings nicht völlig auszuschließen.

Der Hauptkritikpunkt der Websec-Arbeitsgruppe der IETF, die die Arbeiten am Entwurf nun weiter verfolgen will, bleibt die erste Anfrage vom Nutzer. Wenn diese bei einem kompromittierten Server landet, hat es sich ausgepinnt, im Extremfall ist die richtige Google-Seite dann nicht mehr erreichbar. Wie das so genannte Bootstrapping-Problem zu lösen ist, dazu gibt es laut Fette noch keine echte Lösung. Bei der Diskussion in der IETF wurden sofort auch mögliche Angriffsszenarien diskutiert, mittels derer Regierungen PIN-geschützte Seiten ausschalten könnten. Schließlich hilft das Pinning auch nicht, wenn die eigene Zertifzierungsstelle gehackt wurde.

In der Websec-Arbeitsgruppe wurde rasch auf die parallel laufende Arbeit der DANE-Arbeitsgruppe hingewiesen, die Zertifikate gerne im mittels DNSSEC gesicherten DNS hinterlegen will. Ein Bootstrapping-Problem gibt es dort wegen der geschlossenen Vertrauenskette nicht, zudem geht die Absicherung über http-Anfragen hinaus. Allerdings ist DNSSEC derzeit noch wenig verbreitet. (dab)