Certificate Transparency (CT) – przejrzystość certyfikatów TLS od środka

Certificate Transparency (CT) to mechanizm bezpieczeństwa zaprojektowany, aby zapobiegać nadużyciom związanym z certyfikatami TLS.

Jego główny cel:

Umożliwić publiczne wykrywanie wszystkich certyfikatów wydanych dla danej domeny.

Problem, który rozwiązuje:

Co jeśli urząd certyfikacji (CA) wyda fałszywy certyfikat dla Twojej domeny?

Bez CT:

 id="ct01"
Attacker

        |
        v

Fake Certificate

        |
        v

Browser trusts CA

        |
        v

MITM Attack

Certificate Transparency sprawia, że taki certyfikat zostaje publicznie widoczny.

Problem z systemem CA

HTTPS opiera się na zaufanych urzędach certyfikacji:

Przykład:

 id="ct02"
Browser

    |
    |
Trust Store

    |
    |
Certificate Authority

    |
    |
Website Certificate

Przeglądarka ufa setkom CA.

Problem:

Jeżeli jeden CA zostanie:

• zhakowany,
• błędnie skonfigurowany,
• zmanipulowany,

może wydać certyfikat dla cudzej domeny.

Przykład ataku

Normalnie:

 id="ct03"
example.com

Certificate:

example.com
      |
      |
Trusted CA

Atak:

 id="ct04"
example.com

Fake Certificate

      |
      |
Compromised CA

Przeglądarka może zaakceptować taki certyfikat.

Idea Certificate Transparency

CT wprowadza:

publiczne, audytowalne logi certyfikatów.

Schemat:

 id="ct05"

Certificate Authority

        |
        |
        v

CT Log Server

        |
        |
        v

Public Record

Każdy może sprawdzić:

• jakie certyfikaty wydano,
• komu,
• kiedy,
• przez jaki CA.

Jak działa Certificate Transparency?

Proces:

 id="ct06"

1. CA wystawia certyfikat

        |
        v

2. CA wysyła certyfikat do CT Log

        |
        v

3. Log zwraca SCT

        |
        v

4. Certyfikat trafia do użytkownika

SCT – Signed Certificate Timestamp

Najważniejszy element CT.

SCT oznacza:

Signed Certificate Timestamp

Jest dowodem:

„Ten certyfikat został zgłoszony do publicznego logu CT.”

Schemat:

 id="ct07"

Certificate

      +

SCT

      |

      v

Browser

Co zawiera SCT?

Między innymi:

 id="ct08"

Timestamp

Certificate Hash

Log ID

Digital Signature

Log podpisuje informację:

 id="ct09"

CT Log Private Key

        |

        v

Signed Timestamp

CT Log – publiczny dziennik

Log CT działa jak append-only database.

Czyli:

Można:

 id="ct10"

ADD Certificate

Nie można:

 id="ct11"

DELETE Certificate

ani:

 id="ct12"

MODIFY Old Entry

Merkle Tree

Certificate Transparency wykorzystuje drzewa Merkle’a.

Podobna technologia występuje w:

• blockchain,
• systemach audytowych,
• systemach integralności danych.

Schemat:

 id="ct13"

          Root Hash

              |
       +------+------+

       |             |

    Hash AB       Hash CD

      |             |

   Cert A        Cert B

Każdy wpis wpływa na końcowy hash.

Dlaczego Merkle Tree?

Ponieważ pozwala szybko sprawdzić:

• czy certyfikat istnieje,
• czy log nie został zmieniony,
• czy wpis nadal jest częścią drzewa.

Proof of Inclusion

Log może udowodnić:

 id="ct14"

Certificate X

      |

      v

Exists in CT Log

bez wysyłania całej bazy.

CT Monitor

Firmy mogą monitorować logi CT.

Przykład:

Firma:

example.com

ustawia monitoring.

Pojawia się:

 id="ct15"

evil.example.com

Certificate issued

System alarmuje:

 id="ct16"

WARNING:

New certificate detected

Przykład praktyczny

Masz domenę:

netbe.pl

Normalnie oczekujesz:

 id="ct17"

netbe.pl

Certificate

Let's Encrypt

Ale pojawia się:

 id="ct18"

netbe.pl

Certificate

Unknown CA

CT pozwala szybko wykryć problem.

Certificate Transparency w przeglądarkach

Największym użytkownikiem CT są przeglądarki.

Proces:

 id="ct19"

Browser

    |
    v

Check Certificate

    |
    v

Verify SCT

    |
    v

Accept / Reject

CT i TLS 1.3

CT działa razem z TLS.

Schemat:

 id="ct20"

DNS

 |
 v

TLS 1.3 Handshake

 |
 v

Certificate

 |
 v

Certificate Transparency Check

 |
 v

Encrypted HTTPS

CT a DNSSEC

To dwie różne warstwy.

DNSSEC:

 id="ct21"

Czy DNS wskazuje prawdziwy adres?

CT:

 id="ct22"

Czy certyfikat TLS został legalnie wydany?

Razem:

 id="ct23"

DNSSEC

↓

Correct IP

↓

Certificate Transparency

↓

Correct Certificate

↓

TLS 1.3

↓

Encrypted Connection

CT a HSTS

HSTS:

 id="ct24"

Zawsze używaj HTTPS

CT:

 id="ct25"

Certyfikat musi być publicznie widoczny

Razem zwiększają bezpieczeństwo HTTPS.

CT i Let’s Encrypt

Publiczne CA, takie jak Let’s Encrypt, publikują wydawane certyfikaty w logach CT.

Dzięki temu każdy może sprawdzić:

• kiedy certyfikat został wydany,
• dla jakiej domeny,
• przez jaki urząd.

CT Logi

Popularne logi CT są prowadzone m.in. przez:

• Google,
• Cloudflare,
• DigiCert,
• inne organizacje bezpieczeństwa.

Logi są publiczne i mogą być monitorowane.

Certificate Transparency a bezpieczeństwo firm

Duże organizacje używają CT do:

Wykrywania Shadow IT

Przykład:

 id="ct26"

dev.company.com

Certificate created

ale dział IT nic o tym nie wie.

Wykrywania phishingu

Przykład:

 id="ct27"

paypa1-login.com

Certificate issued

Monitoring może wykryć takie domeny.

CT i Zero Trust

W modelu Zero Trust:

 id="ct28"

Never Trust

Always Verify

CT pomaga zweryfikować:

Certificate History

+

Certificate Ownership

CT a przyszłość PQC

W przyszłości certyfikaty również będą musiały przejść migrację do kryptografii post-quantum.

Obecnie:

 id="ct29"

Certificate

RSA / ECDSA

        |

        v

CT Log

Przyszłość:

 id="ct30"

Certificate

ML-DSA

        |

        v

CT Log

Certificate Transparency pozostanie potrzebne, niezależnie od używanego algorytmu podpisu.

Jak wszystkie elementy HTTPS współpracują?

 id="ct31"

                 SECURE WEB


          DNSSEC
             |
             |
       Correct Destination
             |
             v

       Certificate Transparency
             |
             |
       Valid Certificate
             |
             v

            TLS 1.3
             |
       +-----+------+
       |            |
    X25519       Certificate
       |            |
       v            v
    HKDF       Signature Verify
       |
       v

AES-GCM / ChaCha20-Poly1305

       |
       v

Encrypted HTTPS

Najważniejsze do zapamiętania

Certificate Transparency
→ publiczny rejestr certyfikatów TLS

CT Log
→ przechowuje informacje o wydanych certyfikatach

SCT
→ dowód publikacji certyfikatu w logu

Merkle Tree
→ zapewnia integralność logu

CT Monitor
→ wykrywa podejrzane certyfikaty

Certificate Transparency nie szyfruje danych i nie zastępuje TLS. Jego zadaniem jest kontrola zaufania do infrastruktury certyfikatów. Dzięki CT atakujący może nie ukryć faktu uzyskania fałszywego certyfikatu – taki certyfikat zostanie zapisany w publicznym logu i może zostać wykryty przez właściciela domeny lub systemy monitorujące.

Polecane wpisy

Bezpieczne głosowanie online: jak algorytmy szyfrujące chronią integralność wyborów

Bezpieczne głosowanie online: jak algorytmy szyfrujące chronią integralność wyborów W erze cyfrowej, gdy coraz więcej aspektów naszego życia przenosi się Czytaj dalej

Algorytmy kompresji dźwięku (MP3, AAC, FLAC): analiza technik kompresji

Algorytmy kompresji dźwięku (MP3, AAC, FLAC): analiza technik kompresji W dobie strumieniowego przesyłania muzyki i ogromnych bibliotek dźwiękowych, algorytmy kompresji Czytaj dalej