Zuk\u00fcnftig soll es wieder m\u00f6glich sein, kompromittierte SSL-Zertifikate einfach zu sperren. Apple und Mozilla preschen vor und die CA Let’s Encrypt ist mit dabei. In unserem Blogbeitrag besch\u00e4ftigen wir uns heute mit dem Thema der Zertifikatsperrlisten und dem Vorschlag der beiden Browser-Hersteller. Au\u00dferdem werfen wir einen Blick auf die Vergangenheit, zeigen fr\u00fchere L\u00f6sungsans\u00e4tze auf und erkl\u00e4ren, warum diese scheiterten.<\/p>\n
<\/p>\n
Kaum zu glauben, aber es gibt auch in der IT-Sicherheit ein Thema, das fast in Vergessenheit geraten ist: Die Verwaltung von SSL-Zertifikaten. Denn bislang gibt es keine allgemeing\u00fcltige Methode, nach der ein kompromittiertes SSL-Zertifikat gesperrt und damit aus dem Verkehr gezogen werden kann. Und so ist beispielsweise die Verk\u00fcrzung der Laufzeit von SSL-Zertifikaten<\/a> auch \u201enur\u201c die Bestrebung, damit wenigstens die Zeitspanne zu verk\u00fcrzen, in der ein kompromittiertes Zertifikat im Umlauf ist, umso weniger Zeit f\u00fcr dessen Missbrauch und f\u00fcr etwaige Angriffe zu geben \u2013 dem damit einhergehenden Administrationsaufwand f\u00fcr Zertifizierungsstellen und Endnutzende inklusive.<\/p>\n Einen wirklich zufriedenstellenden L\u00f6sungsvorschlag f\u00fcr das Verwaltungsproblem bei SSL-Zertifikaten hatte jedoch niemand. Doch es gibt Neuigkeiten: Jetzt fordern Apple und Mozilla ein Revival der Zertifikatsperrlisten \u2013 und haben mit der weltgr\u00f6\u00dften Zertifizierungsstelle Let\u00b4s Encrypt auch ein Schwergewicht an Bord.<\/p>\n Wir alle wissen, dass ein SSL-Zertifikat<\/a> die Identit\u00e4t einer Webseite sicherstellt und den Datenverkehr verschl\u00fcsselt. F\u00fcr die Verschl\u00fcsselung von Daten wird logischerweise ein Schl\u00fcssel ben\u00f6tigt \u2013 sowie ein weiterer f\u00fcr deren Entschl\u00fcsselung. Es wird also exakt ein Schl\u00fcsselpaar, bestehend aus einem \u00f6ffentlichen und einem privaten Schl\u00fcssel, ben\u00f6tigt. W\u00e4hrend der \u00f6ffentliche Schl\u00fcssel eine Nachricht verschl\u00fcsselt, kann diese nur mit dem dazu passenden privaten Schl\u00fcssel wieder dechiffriert werden.<\/p>\n Wenn dieser private, geheime Schl\u00fcssel aber gestohlen und\/ oder ver\u00f6ffentlicht wurde, damit das gesamte SSL-Zertifikat kompromittiert und muss beim Herausgeber, der Certification Authority (CA) bzw. Zertifizierungsstelle<\/a>, gesperrt werden.<\/p>\n In der Vergangenheit gab es zwei Mechanismen, welche SSL-Zertifikate als gesperrt kennzeichneten, falls diese kompromittiert wurden: CRLs und OCSP.<\/p>\n Die Abfrage \u00fcber Certificate Revocation Lists<\/strong><\/p>\n Hat eine CA ein SSL-Zertifikat gesperrt, tr\u00e4gt sie dieses Zertifikat in eine Certificate Revocation List (CRL) ein. Das Problem dabei: Diese Listen k\u00f6nnen schnell mehrere Mbytes gro\u00df werden. Da diese Listen obendrein auch erst vom Client heruntergeladen werden m\u00fcssen, sind sie f\u00fcr eine schnelle \u00dcberpr\u00fcfung, ob sich ein gesperrtes Zertifikat darin befindet oder nicht, ungeeignet: Die \u00dcbermittlung an den Client und die eigentliche \u00dcberpr\u00fcfung nehmen einfach viel zu viel Zeit in Anspruch. Hinzu kommt, dass Sperrlisten nicht immer ganz aktuell sind, da sie nur in bestimmten Intervallen erstellt werden.<\/p>\n Die Alternative: Online Certificate Status Protocols<\/strong><\/p>\n Die Alternative zu CRLs sollte in der weiteren Entwicklung das Online Certificate Status Protocol sein. Mit Hilfe des Online Certificate Status Protocols, kurz OCSP, l\u00e4sst sich durch Anfrage bei einem Server (ein so genannter OCSP-Responder) feststellen, ob ein SSL-Zertifikat gesperrt wurde bzw. noch g\u00fcltig ist.<\/p>\n Ob ein SSL-Zertifikat gesperrt ist, erf\u00e4hrt ein Client oder Browser folglich, wenn er bei einem Server (OCSP-Responder \u2013 \u201eOCSP-Antwortdienst\u201c) eine erfolgreiche Anfrage durchf\u00fchrt: Lautet die Antwort \u201egood\u201c ist das SSL-Zertifikat nicht gesperrt, lautet sie \u201erevoked\u201c ist das SSL-Zertifikat gesperrt. Sollte die Antwort \u201eunknown\u201c lauten, bedeutet dies, dass der Status nicht ermittelt werden konnte.<\/p>\n Kritik an OCSP<\/strong><\/p>\n OCSP hat drei gro\u00dfe Probleme: Zun\u00e4chst w\u00e4re da die Sache mit dem Datenschutz. Der OCSP-Responder bekommt n\u00e4mlich jede Website-Anfrage mit und erh\u00e4lt damit auch die gesamte Suchhistorie einer Person, mit all ihrer vertraulichen Daten, serviert.<\/p>\n Obendrein k\u00f6nnen Angreifende mittels einer Man-in-the-Middle Attacke eine verschl\u00fcsselte Verbindung umleiten und \u00fcbernehmen, dazu ein gesperrtes SSL-Zertifikat verwenden und so die OCSP-Abfragen blockieren. Der Browser oder Client w\u00fcrde in diesem Fall keine Antwort vom Server bekommen und davon ausgehen, dass das SSL-Zertifikat in Ordnung sei. Experten sprechen in diesem Fall von einem \u201efail open\u201c oder einem \u201esoft fail\u201c. Hilfreicher w\u00e4re, bei ausbleibender Antwort eine Fehlermeldung zu erhalten, also ein \u201efail close\u201c oder \u201ehard fail\u201c.<\/p>\n Tats\u00e4chlich braucht es nicht einmal einen Angriff. Denn wenn ein Browser nach einer OCSP-Anfrage nicht innerhalb einer bestimmten Zeit eine Antwort erh\u00e4lt, ignoriert er diesen Zustand einfach und akzeptiert ein Zertifikat als g\u00fcltig \u2013 auch wenn es zwischenzeitlich vielleicht gesperrt wurde. Versuche der Browser-Hersteller, daran etwas zu \u00e4ndern, haben jedoch gezeigt, dass das nicht praktikabel w\u00e4re: Es gebe eine zu hohe Anzahl an Fehlalarmen, da die OCSP-Infrastruktur einfach nicht in der Qualit\u00e4t vorhanden ist, die f\u00fcr einen reibungslosen Ablauf n\u00f6tig w\u00e4re.<\/p>\n Ein dritter Kritikpunkt: Die OCSP-Antwort erfordert h\u00e4ufig das Abrufen der verteilten Seitenbestandteile \u00fcber mehrere Server, was zu deutlich l\u00e4ngeren Ladezeiten bei Website-Aufrufen f\u00fchren kann.<\/p>\n Diese drei Gr\u00fcnde gen\u00fcgten Browser-Herstellern, OCSP nicht zur Pflicht zu machen. Eigene Zertifikats-Sperrlisten f\u00fcr Notf\u00e4lle und k\u00fcrzere Laufzeiten der Zertifikate sollten das damit entstehende Risiko begrenzen. Alles in allem eine sehr unbefriedigende Situation.<\/p>\n Nun fordern Apple und Mozilla von CA-Zertifikaten vollst\u00e4ndige Sperrlisten bereitzustellen. Diese Sperrlisten wollen die Hersteller in den Truststore ihrer Browser aufnehmen.<\/p>\n Neu dabei: Zwischenstation Truststore<\/strong><\/p>\n Die Truststores sollen dabei wie eine Art Zwischenstation funktionieren: Sie sollen die Zertifikatsperrlisten zentral einsammeln und dann als eine kompakte Liste an ihre Browser weitergeben. Diese Zwischenstation erlaubt anscheinend ausreichend viele Optimierungen, dass man die Skalierungs- und Performance-Probleme der herk\u00f6mmlichen CRLs gel\u00f6st werden k\u00f6nnen.<\/p>\n Und was ist mit Google?<\/strong><\/p>\n Google hat sich schon lange vom Online Certificate Status Protocol verabschiedet und arbeitet bei seinem Browser Chrome mit so genannten CRLSets. Bei denen erh\u00e4lt der Browser \u00fcber den Update-Mechanismus die wichtigsten Eintr\u00e4ge der Sperrlisten. Durch den Heartbleed-Bug (OpenSSL) wurde jedoch offenbar, dass das bei Massensperrungen nicht zuverl\u00e4ssig funktioniert.<\/p>\n W\u00e4hrend nun mit Let\u2019s Encrypt zumindest die gr\u00f6\u00dfte CA hellauf von Mozillas und Apples Vorschlag begeistert scheint und bereits die neuen CRLs in Betrieb genommen hat, hat ausgerechnet Google, der mit seinem Chrome-Browser immerhin eine marktbeherrschenden Position einnimmt, sich (noch) nicht zu den neuen CRLs zu Wort gemeldet. Dabei ist Google recht aktiv, wenn es um Richtlinien f\u00fcr digitale Zertifikate geht. Sollte der Konzern etwas gegen den Vorsto\u00df von Apple und Mozilla haben, d\u00fcrfte es den beiden schwer fallen, sich gegen den Platzhirsch durchzusetzen. Allerdings bedeutet keine Antwort nicht gleich eine Ablehnung \u2013 wir d\u00fcrfen also gespannt bleiben.<\/p>\n Es scheint nun bei diesem lange bekannten Verwaltungsproblem von SSL-Zertifikaten endlich etwas voranzugehen. Auch wenn derzeit noch unklar ist, ob die anderen Browserhersteller, geschweige denn die CAs selbst direkt mit einsteigen werden, d\u00fcrfte das \u201eVorpreschen\u201c von Mozilla und Apple immerhin einen gewissen Druck aufbauen. Wir bleiben f\u00fcr Sie auf jeden Fall am Ball \u2013 und wer wei\u00df, vielleicht k\u00f6nnen wie schon bald von einem ersten Test hier bei uns im Blog berichten. Haben Sie weitere Fragen zu SSL-Zertifikaten<\/a> und Zertifikatsperrlisten? Nehmen Sie Kontakt<\/a> zu uns auf! Wir beraten Sie gerne.<\/p>\nSSL-Zertifikat und Schl\u00fcssel ultrakurz zusammengefasst<\/h3>\n
R\u00fcckblick: CRLs und OCSP<\/h3>\n
Apple und Mozilla fordern vollst\u00e4ndige Sperrlisten<\/h2>\n
Fazit zu Zertifikatsperrlisten<\/h2>\n