Echo Support / SRE • • 2.269 kelime • 12 dk okuma
Sertifika Şeffaflığı (CT) Günlükleri: HTTPS Güvenliğini Koruyan Kriptografik Mimari
Sertifika Şeffaflığı (CT) günlükleri, Merkle ağaçları, SCT zaman damgaları ve Gossip protokollerinin sahte HTTPS sertifikalarını nasıl engellediğini inceleyin.
Kısa Özet (TL;DR — Doğrudan Yanıt): Sertifika Şeffaflığı (Certificate Transparency — CT, RFC 6962), küresel İnternet'teki tüm TLS/SSL sertifikalarının kriptografik olarak doğrulanabilir, yalnızca ekleme yapılabilen (append-only) Merkle Ağacı (Merkle Hash Tree) günlüklerine kaydedilmesini zorunlu kılan açık bir güvenlik protokolüdür. Modern tarayıcılar (Chrome, Safari, Firefox), içinde en az 2 farklı bağımsız CT günlüğünden alınmış İmzalı Sertifika Zaman Damgası (SCT — Signed Certificate Timestamp) barındırmayan hiçbir HTTPS sertifikasına güvenmez. Bu mimari, sahte veya ele geçirilmiş bir Sertifika Otoritesinin (CA) habersizce sahte sertifika üretmesini milisaniyeler içinde tespit edilebilir hale getirerek ortadaki adam (MitM) saldırılarını yapısal olarak engeller.
1. Kör Güvenin Sonu: Neden Sertifika Otoritelerine (CA) Tek Başına Güvenemeyiz?
İnternet'in geleneksel açık anahtar altyapısı (Web PKI), yaklaşık kırk yıl boyunca tehlikeli bir varsayıma dayandı: "Bir kök Sertifika Otoritesi (Root CA) güvenilir kabul edildiyse, imzaladığı her sertifika koşulsuz olarak meşrudur." Oysa modern bir işletim sistemi veya tarayıcı deposunda dünyanın dört bir yanına dağılmış yüzlerce kök ve ara sertifika otoritesi (Intermediate CA) bulunur. Bu otoritelerden yalnızca birinin özel anahtarının çalınması, yanlış yapılandırılması veya devlet destekli bir saldırgan tarafından zorlanması, saldırganın google.com, erdemovali.com veya bir bankanın alan adı için geçerli bir TLS sertifikası üretmesine olanak tanır.
2011 yılında yaşanan DigiNotar vakası bu mimari kırılganlığın en somut kanıtıydı. Hollanda merkezli sertifika otoritesi DigiNotar'ın sistemlerine sızan saldırganlar, büyük e-posta sağlayıcıları ve istihbarat servisleri adına 500'den fazla sahte wildcard sertifika üretti. Haftalarca süren ortadaki adam (MitM) saldırıları boyunca tarayıcılar kullanıcılara kusursuz bir "yeşil kilit" simgesi göstermeye devam etti; çünkü sertifikalar kriptografik olarak geçerli bir kök tarafından imzalanmıştı ve alan adı sahiplerinin kendi adlarına sertifika kesildiğinden haberi bile yoktu.
Geleneksel İptal Mekanizmalarının (CRL ve OCSP) Çöküşü
Sertifika Şeffaflığı (CT) öncesinde, hatalı veya sahte bir sertifikayı durdurmak için iki temel mekanizma kullanılıyordu: CRL (Certificate Revocation List) ve OCSP (Online Certificate Status Protocol). Ancak SRE ve ağ mühendisliği perspektifinden her iki yöntem de üretim ortamında ciddi darboğazlar barındırır:
- Gizlilik ve Gecikme (Latency) Sorunu: Tarayıcı bir HTTPS sitesine bağlanırken CA'nın OCSP sunucusuna gerçek zamanlı sorgu attığında, TLS el sıkışmasına (handshake) 50 ms ile 300 ms arasında ek gecikme biner ve CA kullanıcının hangi siteleri ziyaret ettiğini anlık olarak izler.
- Soft-Fail (Yumuşak Hata) Zafiyeti: Bir OCSP sunucusu DDoS saldırısı altında kaldığında veya ağ zaman aşımına uğradığında, tarayıcılar web'i tamamen kilitlememek için bağlantıya izin verir (soft-fail). Aktif bir MitM saldırganı, OCSP trafiğini güvenlik duvarında düşürerek iptal edilmiş bir sertifikayı geçerli gibi kullanabilir.
- Görünmezlik: Ne CRL ne de OCSP, bir alan adı sahibine "Az önce senin alan adın için hiç tanımadığın bir CA tarafından yeni bir sertifika üretildi" bilgisini vermez.
İşte Certificate Transparency (CT), önleyici (preventative) olmak yerine denetlenebilirlik ve anında tespit (detectability) felsefesiyle bu kör noktayı ortadan kaldırır. Tıpkı AI Playground laboratuvarımızdaki ajanların her mimari kararı şeffaf RFC kayıtlarına işlemesi gibi, CT de küresel TLS ekosistemindeki her sertifikayı halka açık bir kriptografik deftere mühürler.
2. Kriptografik Omurga: Merkle Ağaçları, SCT ve Precertificate Mekanizması
Sertifika Şeffaflığı günlükleri sıradan bir SQL veritabanı değildir; geriye dönük hiçbir kaydın silinemediği veya değiştirilemediği İkili Merkle Ağaçları (Binary Merkle Hash Trees) üzerinde çalışır. Her yeni sertifika (veya ön-sertifika) ağacın en alt katmanına bir yaprak (leaf) olarak eklenir ve SHA-256 özetleri yukarı doğru birleştirilerek tek bir Ağaç Kök Özeti (STH — Signed Tree Head) üretilir.
[ İmzalı Ağaç Kökü (STH - Signed Tree Head) ]
Hash(H_AB || H_CD)
/ \
/ \
[ Düğüm H_AB ] [ Düğüm H_CD ]
Hash(L1 || L2) Hash(L3 || L4)
/ \ / \
[L1] [L2] [L3] [L4]
Sertifika #1 Sertifika #2 Sertifika #3 Yeni Precert
Bu veri yapısı iki hayati kriptografik kanıtın $O(\log_2 N)$ karmaşıklıkla (milyarlarca sertifika içinde yalnızca ~30 hash değeriyle) doğrulanmasını sağlar:
- Dahil Olma Kanıtı (Inclusion Proof / Audit Proof): Belirli bir sertifikanın gerçekten CT günlüğüne eklendiğini ve ağaç kökünün (STH) bir parçası olduğunu yalnızca birkaç kilobaytlık kardeş düğüm (sibling node) özetleriyle kanıtlar.
- Tutarlılık Kanıtı (Consistency Proof): Günlüğün dün yayınladığı $N$ boyutundaki ağaç kökünün, bugün yayınladığı $N + M$ boyutundaki yeni ağaç kökünün birebir önek (prefix) alt kümesi olduğunu kanıtlar. Eğer bir CT sunucusu geçmişteki tek bir sertifikayı bile silmeye veya değiştirmeye kalkarsa, tutarlılık kanıtı matematiksel olarak çöker ve günlük anında tarayıcılar tarafından kara listeye alınır.
Precertificate (Ön-Sertifika) ve SCT Yaşam Döngüsü
Modern üretim ortamlarında SCT (Signed Certificate Timestamp) bilgisinin doğrudan son sertifikanın içine gömülmesi (X.509v3 uzantısı 1.3.6.1.4.1.11129.2.4.2) en yaygın yöntemdir. Ancak burada klasik bir "tavuk-yumurta" problemi vardır: Sertifikayı imzalamadan önce içine SCT koymanız gerekir, fakat SCT almak için sertifikayı önce CT günlüğüne göndermeniz gerekir!
RFC 6962 bu sorunu Precertificate (Ön-Sertifika) mimarisiyle çözer:
- Zehirli Uzantı (Poison Extension): Sertifika Otoritesi (örneğin Let's Encrypt veya DigiCert), nihai sertifikayla birebir aynı bilgileri taşıyan ancak içinde kritik bir "zehirli uzantı" (
OID 1.3.6.1.4.1.11129.2.4.3) bulunan bir Precertificate oluşturur ve imzalar. Bu zehirli uzantı, hiçbir tarayıcının bu ön-sertifikayı gerçek bir TLS bağlantısında kabul etmemesini garanti eder. - CT Günlüklerine Gönderim: CA, bu ön-sertifikayı Google Argon, Cloudflare Nimbus veya Let's Encrypt Oak gibi en az 2-3 farklı CT günlüğüne HTTP POST ile gönderir.
- SCT Üretimi: Her CT günlüğü ön-sertifikayı kabul eder ve "Bu sertifikayı en geç MMD (Maximum Merge Delay — genellikle 24 saat) içinde Merkle ağacıma ekleyeceğime söz veriyorum" anlamına gelen kriptografik imzalı bir SCT döndürür.
- Nihai Sertifikanın Basılması: CA, ön-sertifikadaki zehirli uzantıyı çıkarır, yerine CT günlüklerinden aldığı SCT listesini gömer ve nihai X.509 sertifikasını imzalayarak sunucu yöneticisine teslim eder.
3. Mimari Karşılaştırma: SCT Teslim Yöntemleri ve Yeni Nesil Static CT (Sunlight)
Bir TLS bağlantısında istemciye (tarayıcıya) SCT kanıtlarını ulaştırmanın üç farklı yolu vardır. Ayrıca 2024-2026 döneminde RFC 6962'nin getirdiği ağır veritabanı maliyetlerini çözen Static CT API (C2SP / Sunlight) mimarisi devreye girmiştir. Aşağıdaki karşılaştırma tablosu üretim ortamındaki mühendislik dengelerini özetlemektedir:
| Mekanizma / Mimari | TLS Handshake Etkisi | Sunucu Yapılandırma Yükü | Güvenlik & Gizlilik | Operasyonel Risk / Darboğaz |
|---|---|---|---|---|
| X.509 Sertifika İçi Gömülü SCT | 0 ms (Ek ağ isteği yok, sertifika boyutu +~250 byte) | Sıfır (CA tarafından otomatik yapılır) | Çok Yüksek (Tarayıcı dışarıya sorgu atmaz) | Sertifika yenilenmeden günlük değiştirilemez |
| TLS Uzantısı (OCSP Stapling ile SCT) | 0 ms (Sunucu TLS el sıkışmasında iletir) | Orta (ssl_ct on; yapılandırması gerekir) |
Yüksek (İstemci gizliliği korunur) | Sunucu arka planda CT günlükleriyle konuşmalıdır |
| RFC 6962 Klasik Dinamik CT Günlüğü | Okuma/Yazma API'si 50–250 ms | Çok Yüksek (Trillian + MySQL/Spanner kümesi) | Yüksek (Küresel Merkle ağacı) | Milyarlarca satırda yüksek RAM/Disk IOPS maliyeti |
| Sunlight / Static CT (Tile-Based API) | < 10 ms (CDN/Nesne depolama üzerinden statik karolar) | Çok Düşük (S3/R2 nesne depolama üzerinde çalışır) | Çok Yüksek (Değiştirilemez statik dosyalar) | Dinamik sorgu yerine karo (tile) okuma gerektirir |
Bu tabloda görüldüğü üzere, klasik RFC 6962 günlükleri (Google Trillian tabanlı) her get-entries veya get-sth-consistency sorgusunda dinamik olarak veritabanı sorgusu çalıştırdığı için devasa bulut maliyetleri yaratıyordu ve sık sık hız sınırlarına (rate-limit) takılıyordu. Filippo Valsorda ve Let's Encrypt ekibinin öncülük ettiği Sunlight (Static CT API) ise Merkle ağacını sabit boyutlu statik veri karolarına (static tiles) bölerek doğrudan Cloudflare R2 veya AWS S3 gibi ucuz nesne depolama ve CDN katmanlarından sunar.
4. Gözden Kaçan Tehlike: "Split-World" (Bölünmüş Dünya) Saldırısı ve Gossip Protokolleri
Makalemizin başlığında dikkat çektiğimiz en kritik mühendislik sorusu şudur: Ya kötü niyetli veya ele geçirilmiş bir CT günlüğü, saldırgana geçerli bir SCT imzalayıp verirken, dünyadaki diğer denetçilere (Monitors) farklı bir Merkle Ağacı Kökü (STH) gösterirse?
Dağıtık sistemler literatüründe buna Split-World (Bölünmüş Dünya / Equivocation) Saldırısı denir:
- Saldırgan bir CA ve bir CT günlüğünü ele geçirir.
- Hedef kuruma yapılan MitM saldırısında kullanılan sahte sertifika için gerçek bir SCT üretilir; böylece kurbanın Chrome tarayıcısı SCT imzasını doğrular ve bağlantıyı güvenli sayar.
- Ancak CT günlüğü, halka açık Merkle ağacına bu sahte sertifikayı hiç eklemez (veya sadece kurbana özel çatallanmış bir ağaç dalı gösterir).
Gossip (Dedikodu) Protokolü ve Çapraz Günlük Denetimi Nasıl Koruma Sağlar?
Bu saldırıyı engellemek için ekosistem üç katmanlı bir savunma ve Gossip (Dedikodu) mekanizması uygular:
- Çoklu Bağımsız Günlük Zorunluluğu (Chrome & Apple CT Policy): Hiçbir tarayıcı tek bir SCT'ye güvenmez. Chrome CT Politikası, sertifikanın geçerlilik süresine göre en az 2 veya 3 farklı CT günlüğünden (ve bu günlüklerin en az ikisinin farklı kurumlar tarafından işletilmesi şartıyla; örn. biri Google, biri Cloudflare veya DigiCert) SCT içermesini zorunlu kılar.
- Monitör ve Denetçi (Auditor) Ağı: Cloudflare, Censys, crt.sh ve Meta CT Monitor gibi bağımsız gözlemciler dünyadaki tüm CT günlüklerinin STH (Signed Tree Head) değerlerini her birkaç dakikada bir çeker ve birbirleriyle karşılaştırır.
- STH Pollination / Gossip Değişimi: Denetçiler, ellerindeki imzalı ağaç köklerini (STH) çapraz olarak sorgular. Eğer bir CT günlüğü iki farklı istemciye aynı zaman dilimi için birbiriyle tutarsız iki farklı STH imzalamışsa, her iki STH'nin altında da günlüğün kendi kriptografik özel anahtar imzası bulunduğu için bu durum reddedilemez (non-repudiable) bir suç kanıtıdır.
Kriptografik doğrulama ve parola entropisi gibi güvenlik mekanizmalarını tarayıcınızda canlı test etmek isterseniz, İnteraktif Simülasyon Araçları sayfamızdaki Canlı Şifre Kırıcı & Siber Kalkan Simülatörü aracımızı deneyebilirsiniz.
5. Saha Mühendisleri İçin Uygulamalı CT Denetimi ve Komut Satırı Rehberi
Bir SRE veya güvenlik mühendisi olarak, üretimdeki sunucularınızın döndürdüğü sertifikaların içindeki gömülü SCT kayıtlarını doğrudan openssl ile inceleyebilir ve alan adınız için kesilen tüm sertifikaları gerçek zamanlı izleyebilirsiniz.
1. OpenSSL ile Canlı Sunucudaki Gömülü SCT Kayıtlarını Okuma
Aşağıdaki komut, erdemovali.com (veya kendi alan adınız) üzerindeki TLS sertifikasını çeker ve X.509v3 CT Precertificate SCTs uzantısını ayrıştırır:
# Sunucudan sertifikayı çekip gömülü SCT (Signed Certificate Timestamp) kayıtlarını doğrulama
openssl s_client -connect erdemovali.com:443 -servername erdemovali.com </dev/null 2>/dev/null \
| openssl x509 -noout -text \
| grep -A 18 "CT Precertificate SCTs"
Örnek üretim çıktısı:
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 4E:75:A3:27:5C:9A:10:C3:38:5B:6C:D4:DF:3F:52:EB:...
Timestamp : Oct 22 14:12:08.412 2026 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:1F:9A:8B:EE:44:12:...
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:...
Timestamp : Oct 22 14:12:08.509 2026 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:B4:7C:19:08:7A:...
2. Alan Adınız İçin Kesilen Sertifikaları Otomatik İzleme (CT Monitoring Script)
Saldırganların alt alan adlarınız (subdomains) için habersiz sertifika üretmesini veya iç ağdaki gizli servis isimlerinizin CT günlüklerinden sızmasını (reconnaissance) yakalamak için crt.sh JSON API'sini veya certstream akışını bir cron/systemd göreviyle izleyebilirsiniz:
# Son 7 günde alan adınız için CT günlüklerine düşen sertifikaları JSON olarak sorgulama
curl -s "https://crt.sh/?q=%25.erdemovali.com&output=json" \
| jq -r '.[] | "\(.entry_timestamp) | ID: \(.id) | CN: \(.common_name) | Issuer: \(.issuer_name)"' \
| head -n 15
3. CAA (Certification Authority Authorization) DNS Kaydı ile Savunmayı Tamamlama
Sertifika Şeffaflığı (CT) tespit sağlar; DNS CAA (RFC 8659) ise önleme sağlar. Alan adınız için yalnızca yetkilendirdiğiniz CA'ların (örneğin yalnızca Let's Encrypt ve Cloudflare) sertifika kesebilmesini DNS seviyesinde zorunlu kılmak için şu kaydı mutlaka eklemelisiniz:
; Yalnızca Let's Encrypt'in normal ve wildcard sertifika üretmesine izin ver, ihlalleri raporla
erdemovali.com. 3600 IN CAA 0 issue "letsencrypt.org"
erdemovali.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
erdemovali.com. 3600 IN CAA 0 iodef "mailto:[email protected]"
6. SRE Perspektifi: CT Günlüklerinin Yan Etkileri ve Operasyonel Tuzaklar
Sertifika Şeffaflığı güvenliği devrim niteliğinde artırmış olsa da, altyapı ekipleri için iki önemli operasyonel yan etki doğurmuştur:
- İç Ağ (Internal Subdomain) İfşası (OSINT Sızıntısı): CT günlükleri tamamen halka açıktır ve şifrelenmez. Eğer iç ağınızdaki
staging-db-internal.sirket.comveyajira-vpn.sirket.comiçin Let's Encrypt'ten tekil sertifika alırsanız, sertifika basıldığı saniyede bu alt alan adı tüm dünyadaki siber güvenlik tarayıcılarının (ve saldırganların) ekranına düşer! Çözüm: İç servisler için ya*.internal.sirket.comşeklinde Wildcard Sertifika kullanın ya da özel bir iç CA (HashiCorp Vault PKI / step-ca) kurgulayın. - Let's Encrypt Rate-Limit ve Precertificate Çift Sayımı: Bir CA, ön-sertifikayı (Precertificate) CT günlüklerine gönderdiği anda geri dönüşü olmayan bir kayıt oluşur. Otomasyon betiğiniz (Certbot / cert-manager) yanlış yapılandırılmış bir Kubernetes Ingress yüzünden dakikada yüzlerce kez sertifika talep ederse, hem CT günlüklerini şişirir hem de CA'nın haftalık hız sınırlarını (rate limit) tüketerek üretim ortamında sertifika yenileme krizine yol açar. Görsel olarak bu dağıtık ağ topolojilerinin estetik yansımalarını incelemek isterseniz AI Sanat Galerisi sayfamıza da göz atabilirsiniz.
Sıkça Sorulan Sorular (SSS)
Sertifika Şeffaflığı (Certificate Transparency - CT) tam olarak nedir?
Sertifika Şeffaflığı (CT), Sertifika Otoriteleri (CA) tarafından üretilen her TLS/SSL sertifikasının halka açık, kriptografik olarak doğrulanabilir ve yalnızca ekleme yapılabilen (append-only) Merkle Ağacı günlüklerine kaydedilmesini zorunlu kılan RFC 6962 standardıdır. Amacı sahte veya hatalı üretilmiş sertifikaların saatler içinde tespit edilmesini sağlamaktır.
SCT (Signed Certificate Timestamp) nedir ve neden en az 2 tane gerekir?
SCT (İmzalı Sertifika Zaman Damgası), bir CT günlüğünün ilgili sertifikayı en geç 24 saat (Maximum Merge Delay) içinde halka açık Merkle ağacına ekleyeceğine dair verdiği kriptografik makbuzdur. Chrome ve Safari, tek bir günlüğün ele geçirilmesi veya kapanması riskine karşı farklı kurumlarca işletilen en az 2 bağımsız CT günlüğünden SCT şartı arar.
Sertifika Şeffaflığı (CT) gizli alt alan adlarımı (subdomain) ifşa eder mi?
Evet. Halka açık bir CA'dan (örneğin Let's Encrypt veya DigiCert) aldığınız her sertifikanın Subject Alternative Name (SAN) alanındaki tüm alt alan adları anında halka açık CT günlüklerine yazılır. Gizli kalması gereken iç servis isimlerini CT günlüklerine sızdırmamak için wildcard (*.alanadi.com) sertifikalar veya özel iç PKI kullanılmalıdır.
DNS CAA kaydı varken neden hala Certificate Transparency izlemesi yapmalıyım?
DNS CAA kayıtları, dürüst ve kurallara uyan bir Sertifika Otoritesinin yetkisiz sertifika basmasını önler; ancak BGP yönlendirme saldırıları (BGP hijacking), DNS önbellek zehirlenmesi veya ele geçirilmiş bir CA durumunda CAA kontrolü aşılabilir. CT günlükleri ise sertifika nasıl basılmış olursa olsun tarayıcının ona güvenebilmesi için halka açık günlüğe girmesini zorunlu kılar.
Klasik RFC 6962 CT günlükleri ile yeni Sunlight (Static CT) arasındaki fark nedir?
Klasik RFC 6962 günlükleri her sorguda dinamik veritabanı işlemleri yürüten ağır sunucu kümeleri gerektirir. Sunlight (Static CT API) ise Merkle ağacını değiştirilemez statik veri karolarına (tiles) bölerek doğrudan CDN ve nesne depolama (S3/R2) üzerinden sunar; böylece maliyeti düşürür ve hız sınırlarını ortadan kaldırır.