1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
---
title: Certificate Transparency
slug: Web/Bezpieczeństwo/Certificate_Transparency
tags:
- Bezpieczeństwo
- Web
- bezpieczeństwo aplikacji WWW
translation_of: Web/Security/Certificate_Transparency
---
<p><span class="seoSummary"><strong>Certyfikat Przejrzystości (Certificate Transparency)</strong></span> to otwarta platforma programistyczna (framework) stworzona do ochrony oraz monitorowania braków w certyfikacji. Świeżo wydane certyfikaty dostają się do obiegu publicznego, często niezależne logi CT zostają wpisane do rejestru, przez co zachowany zostaje zabezpieczony kryptograficznie rekord certyfikatów TLS.</p>
<p>W ten sposób organy certyfikujące (CA) mogą podlegać znacznie większemu, publicznemu nadzorowi i kontroli. Potencjalnie szkodliwe certyfikaty, jak te, które naruszają <em>Podstawowe Wymogi </em>CA/B Forum mogą zostać znacznie sprawniej wykryte i cofnięte. Podmioty zajmujące się sprzedażą przeglądarek oraz opiekuni certyfikatów zaufanych są również uprawnieni do podejmowania gruntowniej popartych decyzji dot. problematycznych organów certyfikujących, którym mogą odmowić zaufania.</p>
<h2 id="Kontekst">Kontekst</h2>
<p>Logi CT są budowane w ramach struktury danych drzewa Merkla (Merkle tree). Węzły są oznaczane hashami kryptograficznymi ich węzłów potomnych. Liście (leaf nodes) zawierają hashe aktualnych części danych. Oznaczenie węzła głównego (root node) zależy jednakże od wszystkich pozostałych węzłów w drzewie.</p>
<p>W kontekście przejrzystości certyfikacji dane hashowane przez liście są certyfikatami wydawanymi obecnie przez różne CA. Obecność certyfikatu może zostać zweryfikowana przez <em>dowód kontroli </em>skutecznie generowany i weryfikowany w czasie działania logarytmicznego - logarithmic O(log n) time.</p>
<p>Pierwotnie, w 2013 roku przejrzystość certyfikacji służyła przeciwdziałaniu narażania CA (naruszenia DigiNotar w 2011 roku), wątpliwym decyzjom (incydent Trustwave subordinate root w 2012 roku) oraz technicznym problemom wydawniczym (emisja słabego, 512-bitowego certyfikatu przez Digicert Sdn Bhd w Malezji)</p>
<h2 class="western" id="Wdrożenie">Wdrożenie</h2>
<p>Gdy certyfikaty zostają dostarczone do rejestru CT, <em>znacznik SCT</em> (<em>signed certificate timestamp</em>) zostaje wygenerowany i zwrócony. Służy to jako dowód, że certyfikat został dostarczony i zostanie dodany do rejestru.</p>
<p>Wg specyfikacji podczas komunikacji serwery zgodne muszą dostarczać numery tych SCTów do klientów TLS. Może do tego dojść na kilka różnych sposobów:</p>
<ul>
<li>rozszerzenie certyfikatu X.509v3, które umieszczają znaczniki SCT bezpośrednio do certyfikatów liści</li>
<li>rozszerzenie TLS typu <code>signed_certificate_timestamp</code> wysyłane podczas uzgadniania (handshake)</li>
<li>"zszywanie" OCSP (rozszerzenie TLS <code>status_request</code>) i dostarczanie <code>SignedCertificateTimestampList</code> z jednym lub większą liczbą SCTsów</li>
</ul>
<p>Przy rozszerzeniu certyfikatu X.509 o włączonych SCTsach decydują organy certyfikujące. Przy stosowaniu tego typu mechanizmu nie powinna istnieć potrzeba modyfikacji serwerów webowych.</p>
<p>W przypadku ostatnich metod serwery powinny być aktualizowane, aby móc wysyłać żądane dane. Korzyść stanowi fakt, że operator serwera może modyfikować źródła rejestru CT dostarczając SCTsy wysyłane przez rozszerzenie TLS/"zszytą" odpowiedź OCSP.</p>
<h2 id="Wymagania_przeglądarki">Wymagania przeglądarki</h2>
<p>Google Chrome wymaga umieszczania rejestru CT dla wszystkich kwestii związanych z emisjami certyfkatów z datą notBefore po 30 kwietnia 2018 roku. Użytkownicy zostaną uchronieni przed odwiedzaniem stron używających niezgodnych certyfikatów TLS. Wcześniej Chrome wymagało umieszczania <em>Rozszerzonej Walidacji</em> (EV) oraz certyfikatów wydawanych przez Symantec.</p>
<p>Apple <a href="https://support.apple.com/en-gb/HT205280">wymaga</a> zróżnicowanej liczby SCTsów dla Safari i innych serwerów celem zaufania certyfikatom.</p>
<p>Firefox aktualnie ani <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1281469">nie sprawdza</a> ani nie wymaga stosowania rejestru CT dla stron odwiedzanych przez użytkowników.</p>
<p>Nagłówek <a href="/en-US/docs/Web/HTTP/Headers/Expect-CT">Expect-CT </a>może zostać użyty do żądania, by przeglądarka zawsze wymuszała wymóg przejrzystości certyfikacji (np. w Chrome nawet, jeśli certyfikat został wydany z datą notBefore, przed kwietniem)</p>
<h2 id="Specyfikacje">Specyfikacje</h2>
<table class="standard-table">
<tbody>
<tr>
<th scope="col">Specyfikacja</th>
<th scope="col">Status</th>
<th scope="col">Komentarz</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>
|
