Certificate Transparency – Transparenz im Zertifikatsdschungel

Certificate Trans­pa­rency (kurz CT) ist ein Sys­tem zur Prüfung und Überwa­chung digi­taler Zertifikate. Es wurde von den Goog­le-Mit­arbeitern Ben Laurie und Adam Lang­ley ent­wickelt und als IETF-Stan­dard vor­ge­schla­gen. Goog­le selbst treibt das Pro­jekt stark voran: ab Oktober 2017 wird der Goog­le-Brow­ser Chro­me Zertifikate, die nicht im CT-Log regis­triert sind, als nicht vertrau­enswürdig ein­stu­fen. Damit wer­den Zertifizierungs­stel­len gezwun­gen an Certificate Trans­pa­rency teilzu­nehmen. Certificate Trans­pa­rency verhindert kei­ne unzulässig aus­ge­stell­ten Zertifikate, wird aber zu ei­ner ra­schen Ent­deckung von sol­chen füh­ren, indem folgen­den Ziele an­ge­strebt wer­den:

• Für ei­ne Zertifizierungs­stel­le soll es qua­si unmöglich sein ein Zertifikat für ei­ne Domain aus­zu­stel­len, ohne dass die­ser Vor­gang vom Inhaber der Domain bemerkt wird.
• Domain-Besitzer und Zertifizierungs­stel­len sol­len über­prüfen können, ob Zertifikate irrtümlich oder bös­wil­lig aus­ge­stellt wur­den.
• Nutzer sol­len möglichst gut vor irrtümlich oder bös­wil­lig aus­ge­stell­ten Zertifika­ten ge­schützt wer­den.

Logs, Moni­tore und Au­di­to­ren

Certificate Trans­pa­rency fügt drei neue Komponen­ten zum be­stehen­den Zertifikatssys­tem hinzu: Logs, Moni­tore und Au­di­to­ren. Benötigte ein Domain­inhaber bisher ein neues Zertifikat, be­an­tragte er dies bei sei­ner Zertifizierungs­stel­le, die nach ei­ner Prüfung das Zertifikat aus­stel­len konnte. Mit Certificate Trans­pa­rency kommen nun weite­re Schritte hinzu, die im Folgen­den blau-kursiv hervor­geho­ben und in Ab­bildung 1 in ei­ner Übersicht dar­ge­stellt sind:

1. Der Domain­inhaber von example.com erwirbt ein neues Zertifikat bei sei­ner Zertifizierungs­stel­le.
2. Die Zertifizierungs­stel­le über­prüft die Au­thentizität des Domain­inhabers, also ob die­ser be­rechtigt ist das Zertifikat zu be­an­tra­gen.
3. Die Zertifizierungs­stel­le erzeugt ein Vor­abzertifikat.
4. Die Zertifizierungs­stel­le sendet das Vor­abzertifikat an ein CT-Log, das mit ei­nem si­gnier­ten Zeitstempel (eng­lisch si­gned certificate timestamp, kurz SCT) antwortet.
5. Die Zertifizierungs­stel­le übergibt das Zertifikat mit der SCT an den Domain­inhaber, der damit sei­ne Systeme konfiguriert.
6. Bei ei­nem Ver­bindungs­aufbau mit example.com validiert der Brow­ser das Zertifikat und die Si­gnatur der SCT.
7. Sind Zertifikat und SCT in Ord­nung, wird ei­ne verschlüsselte Ver­bindung mit dem Server herge­stellt und dar­über kommuniziert.

Anmerkung: Dieser Ablauf und Abbildung 1 beschreiben die Ausstellung von Zertifikaten mit SCT als x.509-Erweiterung. Andere Möglichkeiten werden im Abschnitt Logs beschrieben.

Logs

Das zen­trale Element von Certificate Trans­pa­rency sind demnach Logs. In die­se wer­den neue Zertifikate zu ei­nem stetig wach­sen­den Hash-Baum angehängt. Der Hash-Baum (eng­lisch Merk­le Tree) schützt zudem vor nach­träg­li­cher Manipu­lati­on des Logs, das von jedermann auf irrtümlich oder bös­wil­lig aus­ge­stellte Zertifikate hin über­prüft wer­den kann.
Wird ein Zertifikat an ein Log ge­schickt, antwortet dieses mit ei­ner SCT, was ei­nem Ver­spre­chen gleichkommt das Zertifikat spä­tes­tens bis zu diesem Zeitpunkt in das Log einzu­tra­gen. Beim späte­ren Ver­bindungs­aufbau zwi­schen Client und Server wird auch die SCT über­prüft. Sie kann über drei Wege an den Client kommuniziert wer­den:

1. als x.509-Para­me­ter des Zertifikats: die Zertifizierungs­stel­le fügt die SCT kurz vor dem Si­gniervor­gang zum Zertifikat hinzu. Der Domain­inhaber bzw. Web­seitenbe­treiber muss kei­ne Ände­run­gen an sei­ner Konfigurati­on vornehmen.
2. als TLS-Para­me­ter beim Ver­bindungs­aufbau: der Web­seitenbe­treiber muss den Ver­bindungs­aufbau so konfigurie­ren, dass die SCT an den Client kommuniziert wird. Die Zertifizierungs­stel­le muss hingegen kei­ne Ände­run­gen bei der Aus­stellung von Zertifika­ten vornehmen.
3. per OCSP Stapling: ne­ben In­formationen zur Revokati­on von Zertifika­ten können auch SCTs übermit­telt wer­den. Auch hier muss der Web­seitenbe­treiber Ände­run­gen vornehmen und OCSP-Handling implementie­ren.

Wel­cher die­ser drei Möglichkei­ten sich schließlich durch­set­zen wird, ist noch un­klar. Es gibt gu­te Grün­de für den 1. Weg die SCT als x.509-Erweiterung zu über­tra­gen. Dadurch müs­sen Web­seitenbe­treiber kei­ne Ände­run­gen vornehmen. Dafür sind Zertifizierungs­stel­len in der Pf­licht ih­ren Aus­stellungs­prozess zu übe­r­arbei­ten. Sie müs­sen Vor­abzertifikate an Logs sen­den und auf die SCT-Antwort war­ten. Dass es bei diesem syn­chronen Pro­zess gelegentlich zu Verzögerun­gen kommen kann, ist zu erwar­ten: Ab­bildung 2 zeigt den Verlauf der Anzahl von aus­ge­stell­ten Let's Encrypt-Zertifika­ten pro Tag. Wenn an Spitzenta­gen mehr als 1,3 Mil­lionen Zertifikate nur für Let's Encrypt in Logs ein­ge­tra­gen wer­den müs­sen (der RFC-Stan­dard empfiehlt ein Zertifikat gleichzeitig in meh­re­re Logs einzu­tra­gen), müs­sen für schnel­le Antwortzei­ten umfang­rei­che Ressourcen vor­ge­hal­ten wer­den.

Moni­tore

Ne­ben Logs existie­ren Moni­tore (deutsch Wäch­ter), die über ver­dächtige Vor­gänge in Logs wa­chen. Moni­tore können bei­spielsweise von größe­ren Dienst­anbietern im In­ternet (Facebook, etc.) oder Zertifizierungs­stel­len (COMODO und an­de­re) betrie­ben wer­den. Es steht aber grundsätzlich jedem frei sei­nen ei­genen Monitoring-Dienst zu be­trei­ben oder das Dienst­angebot ei­nes Drit­ten zu nut­zen. Sslmate bietet ei­nen sol­chen Dienst für bis zu fünf Domains kosten­los an.

Da zukünftig alle aus­ge­stell­ten Zertifikate an Logs ge­meldet wer­den müs­sen und jeder ei­nen Monitoring-Dienst be­trei­ben kann, wer­den un­ter Umstän­den auch "geheime" Domains und Subdomains öff­entlich bekannt, auch wenn der Be­treiber dies gerne verheimli­chen würde.

Au­di­to­ren

Auditoren überprüfen, ob Logs untereinander konsistent sind. Außerdem sollen sie sicherstellen, dass alle Zertifikate zu mindestens einem Log hinzugefügt wurden. Schließlich wird durch Log Proofs auditiert, ob ein Log manipuliert wurde, beispielsweise durch nachträgliches Hinzufügen, Bearbeiten oder Löschen von Zertifikatsinformationen.

Browser werden zukünftig eine Softwarekomponente enthalten, die als Auditor fungiert: sol­len verschlüsselte Ver­bindun­gen herge­stellt wer­den, über­prüfen die­se Module die SCT und fra­gen Logs nach dem Zertifikat ab. Ebenso kann ein Au­di­tors ein ei­genständi­ger Dienst oder ein sekundäre Funkti­on ei­nes Moni­tors sein.

Certificate Trans­pa­rency: Ein Schritt in die richtige Rich­tung

Certificate Trans­pa­rency wird in Zukunft nicht verhindern, dass Zertifikate irrtümlich oder bös­wil­lig aus­ge­stellt wer­den. Allerdings ist es durch CT möglich solch ei­nen Ver­stoß schnell zu bemerken und Gegenmaßnah­men zu ergrei­fen. Ei­ne Gegenmaßnah­me, in der Regel die Revokati­on von Zertifika­ten, ist ein weite­res, komple­xes Themenfeld, das bisher nur unzurei­chend gelöst ist. Dennoch ist Certificate Trans­pa­rency ein Schritt in die richtige Rich­tung, der Dienstbe­treibern mehr Kontrolle über ihre Domain gibt.