Teaserbild Certificate Transparency

Certificate Transparency ÔÇô Transparenz im Zertifikatsdschungel

Die­ser Artikel ist Teil der Se­rie zum The­ma "Wa­rum vertrau­en wir Zertifizierungs­stel­len". Nach­dem der Leit­artikel das Vertrau­ens­problem von SSL-/TLS-Zertifika­ten beschrie­ben hat, stellt die­ser Artikel ei­nen L├Âsungs­vorschlag vor.

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.

Certificate Transparency
Ab­bildung 1ÔÇâCertificate Trans­pa­rency hilft unzul├Ąssige oder nicht korrekt aus­ge­stellte Zertifikate rasch zu ent­de­cken.

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.

Ausgestellte Let's Encrypt Zertifikate pro Tag
Abbildung 2 Ausgestellte Let's Encrypt Zertifikate pro Tag, Quelle: letsencrypt.org.

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.

Wir begleiten Sie gerne auf dem Weg der sicheren IT. Bitte senden Sie uns eine Anfrage per E-Mail. Wir rufen Sie zeitnah zur├╝ck und kl├Ąren mit Ihnen die Details f├╝r ein verbindliches Angebot ab.