diff options
Diffstat (limited to 'files/de/web/security/certificate_transparency/index.html')
| -rw-r--r-- | files/de/web/security/certificate_transparency/index.html | 64 |
1 files changed, 64 insertions, 0 deletions
diff --git a/files/de/web/security/certificate_transparency/index.html b/files/de/web/security/certificate_transparency/index.html new file mode 100644 index 0000000000..14d180f9ea --- /dev/null +++ b/files/de/web/security/certificate_transparency/index.html @@ -0,0 +1,64 @@ +--- +title: Certificate Transparency +slug: Web/Security/Certificate_Transparency +tags: + - Security + - Sicherheit + - Web + - Zertifikate +translation_of: Web/Security/Certificate_Transparency +--- +<p><span class="seoSummary"><strong>Certificate Transparency</strong> (kurz; CT) ist ein offenes Framework, das entwickelt wurde, um vor Zertifikatsfehlausstellungen schützen und diese Überwachung zu können. Neu ausgestellte Zertifikate werden dabei in öffentlich geführten, oft unabhängigen CT-Protokollen "protokolliert". An diese Protokolle werden immer nur neue Datensätze angefügt, die jeweils kryptografisch gesichert sind und die einzelnen ausgestellten TLS-Zertifikate dokumentieren.</span></p> + +<p>Auf diese Weise können die Zertifizierungsstellen (CAs) einer viel stärkeren öffentlichen Kontrolle und Aufsicht unterliegen. Potenziell böswillige Zertifikate, z.B. solche, die gegen die <em>Grundanforderungen</em> des CA/B-Forums verstoßen, können viel schneller entdeckt und widerrufen werden. Browser-Hersteller und Root-Store-Betreuer sind auch in der Lage, fundiertere Entscheidungen über problematische CAs zu treffen, denen sie möglicherweise misstrauen.</p> + +<h2 id="Hintergrund">Hintergrund</h2> + +<p>CT-Protokolle bauen auf dem Fundament der <em>Merkle</em>-<em>Baum</em>-Datenstruktur auf. Die Knoten sind mit den <em>kryptographischen Hashes</em> ihrer Kindknoten gekennzeichnet. Blattknoten enthalten Hashes von tatsächlichen Datenstücken. Die Beschriftung des Wurzelknotens hängt daher von allen anderen Knoten im Baum ab.</p> + +<p>Im Zusammenhang mit der Transparenz von Zertifikaten sind die von den Blattknoten gehashten Daten die Zertifikate, die von den verschiedenen heute tätigen CAs ausgestellt wurden. Die Einbeziehung von Zertifikaten kann über einen Audit-Beweis verifiziert werden, der effizient in logarithmischer O(log n)-Zeit generiert und verifiziert werden kann.</p> + +<p>Certificate Transparency kam ursprünglich im Jahr 2013 vor dem Hintergrund kompromittierter Zertifizeirungsstellen (DigiNotar breach, 2011), fragwürdiger Entscheidungen (Trustwave subordinate root incident, 2012) und technischer Probleme beim Ausstellen von Zertifikaten (schwache<span class="entry-content">, 512 bit Zertifikate von Digicert Sdn Bhd aus </span>Malaysia).</p> + +<h2 id="Implementation">Implementation</h2> + +<p>Wenn Zertifikate an ein CT-Protokoll übermittelt werden, wird ein signierter Zertifikat-Zeitstempel (<em>signed certificate timestamp</em>, SCT) erzeugt und zurückgeschickt. Dieser wird dem Protokoll hinzugefügt und dient als Nachweis, dass das Zertifikat eingereicht wurde.</p> + +<p>Die Spezifikation besagt, dass konforme Server den TLS-Clients beim Verbindungsaufabeu eine Reihe dieser SCTs zur Verfügung stellen müssen. Dies kann über eine Reihe verschiedener Mechanismen erfolgen:</p> + +<ul> + <li>X.509v3 certificate extension: signierte SCTs werden direkt in das Zertifikat einbettet</li> + <li>Eine TLS-Erweiterung des Typs <code>signed_certificate_timestamp</code> wird während des handshakes gesendet</li> + <li>OCSP stapling (über die <code>status_request</code> TLS-Erweiterung) und das Bereitstellen einer <code>SignedCertificateTimestampList</code> mit einem oder mehreren SCTs</li> +</ul> + +<p>Mit der oben genannten X.509 certificate extension entscheidet die Zertifizierungsstelle darüber, welche SCTs eingebunden werden. Dieser Mechanismus kann verwendet werden, ohne eine Anpassung am Webserver vornehmen zu müssen.</p> + +<p>Bei den anderen beiden Methoden hingegen müssen die Server aktualisiert werden, um die erforderlichen Daten zu senden. Der Vorteil der Methoden besteht darin, dass der Serverbetreiber die CT-Protokollquellen für die bereitgestellten SCTs selbst auswählen und definieren kann.</p> + +<h2 id="Browser_Anforderungen">Browser Anforderungen</h2> + +<p>Google Chrome erfordert die Einbeziehung des CT-Protokolls für alle Zertifikatsausgaben mit einem nicht vor dem 30. April 2018 liegenden Datum. Nutzer werden daran gehindert, Websites zu besuchen, die nicht konforme TLS-Zertifikate verwenden. Chrome hatte zuvor die CT-Einbeziehung für <em>Extended Validation</em> (EV) und von Symantec ausgestellte Zertifikate verlangt.</p> + +<p>Apple <a href="https://support.apple.com/en-gb/HT205280">verlangt</a> eine unterschiedliche Anzahl von SCTs, damit Safari und andere Server den einzelnen Serverzertifikaten vertrauen können.</p> + +<p>Firefox <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1281469">prüft aktuell nicht</a> bzw. erfordert nicht, dass CT-Protokolle verwendet werden, wenn Nutzer die Webseiten besuchen.</p> + +<p>Der <a href="/en-US/docs/Web/HTTP/Headers/Expect-CT">Expect-CT header </a>kann verwendet werden, um vom Browser zu verlangen, dass dieser <em>immer</em> die<em> </em>Certificate Transparency erfordert (z.B. in Chrome, selbst wenn das Zertifikat ausgestellt wurde mit einem <em>notBefore Datum</em> vor April).</p> + +<h2 id="Spezifikationen">Spezifikationen</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td><a class="external external-icon" href="https://tools.ietf.org/html/rfc6962" hreflang="en" lang="en" rel="noopener">Certificate Transparency</a></td> + <td><span class="spec-RFC">IETF RFC</span></td> + <td></td> + </tr> + </tbody> +</table> |