eMudhra Ara Kurum CA Olayı: Zayıf P-384 Anahtarları ve Güven Deposu Uzun Kuyruğu

Kısa cevap: Sekiz eMudhra ara kurum CA sertifikası, sayısal değeri 256'dan küçük P-384 özel anahtarlarıyla üretildi. Bu, anahtar kurtarmayı zor bir ayrık logaritma probleminden ilk 255 P-384 anahtarını üretip açık noktaları karşılaştırmaya indirir. Ara kurumların altısı TLS, ikisi kod imzalama sertifikası düzenleyebiliyordu. Chrome ve Firefox 17 Ekim 2026'da zinciri blokladı; Apple ve Microsoft, eMudhra'nın durum sayfasına ve olay sitesine göre 19 ve 20 Ekim'de takip etti. Kalıcı çözüm bir çalışma zamanı yaması değildir. Sertifika doğrulayan her güven deposu güncellenmelidir; kendini güncellemeyenler dahil: cihazlar, gömülü Java anahtar depoları, eski konteyner imajları, özel PKI istemcileri ve mTLS karşı tarafları.

Gerçekte ne oldu?

eMudhra, 30 Nisan 2025 tarihli bir Anahtar Üretim Töreni'nde (KGC) 24 ara kurumdan oluşan bir parti oluşturdu. Parti üç seri (A, B, C), iki anahtar türü (RSA-4096 ve P-384) ve dört amaç (DV, OV, EV, kod imzalama) içeriyordu. A serisi sertifikalar Mayıs 2025'te iptal edilip A-1 serisiyle değiştirildi. Ele geçen küme, B ve C serilerindeki tüm P-384 anahtarlarıdır: sekiz sertifika.

eMudhra'ya göre tören FIPS 140-2 Seviye 3 HSM'lerde yapıldı. Anahtar dışa aktarımını test etmek için yapılan bir wrap/unwrap adımı, HSM üzerinde ikinci ve daha zayıf bir anahtar çifti üretti. Benzer anahtar etiketleri, zayıf çiftin CSR için seçilmesine, kök tarafından imzalanmasına ve Sectigo'ya çapraz imzalama için gönderilmesine yol açtı. Dolayısıyla yayımlanan açık anahtarlar, amaçlanan güçlü anahtarlara değil zayıf özel anahtarlara karşılık geliyor. eMudhra altyapı ihlali veya veri sızıntısı kanıtı olmadığını, kod düzeyindeki kesin kök nedeni henüz doğrulamadığını söylüyor.

Bu anlatım iki nedenle önemli. Birincisi, hata P-384, ECDSA veya HSM'nin kriptografik sınırında değil, anahtar üretimi ve anahtar seçimindeydi. İkincisi, "HSM destekli" ile "doğru" eş anlamlı değildir. HSM'ye zayıf bir skaler üretmesi söylenirse bunu sadakatle yapar. Başarısız olan kontrol prosedürel ve betik düzeyindeydi: yanlış anahtar nesnesi kaydedildi ve sertifikanın açık anahtarının amaçlanan anahtarla eşleştiğini bağımsız olarak kimse kontrol etmedi.

Mozilla'nın incelemesi bağımsız bir doğrulama sağlıyor. Mozilla'nın hata yorumlarına göre Mozilla, özel anahtarları 17 Ekim'de kurtardı (kesin saat doğrulanmadı). Mozilla ayrıca yerel yapay zeka ajanlarını basit bir CTF istemiyle test ettiğini bildiriyor; ajanlar anahtarı ilk denemede kurtarmış. Bu test iddiası bağımsız olarak kontrol edilmedi.

Matematik: 255 tahmin neden tam kırılma demek?

P-384 özel anahtarı, grup mertebesi n olan 1..n aralığından düzgün seçilmiş bir d tamsayısıdır; n yaklaşık 2^384'tür. Açık anahtar Q = dG'dir. Q'dan d'yi bulmak, P-384 için yaklaşık 2^192 iş gerektirdiğine inanılan eliptik eğri ayrık logaritma problemidir.

Etkilenen anahtarlar tüm aralığı kullanmıyor. d 256'dan küçük. İkili gösterimde son bayt dışındaki tüm baytlar sıfır. Saldırganın Pollard rho, yan kanal veya HSM erişimine ihtiyacı yok. G, 2G, 3G, … 255G üretir, her noktayı sertifikanın açık noktasıyla karşılaştırır ve eşleşince durur.

Maliyet ihmal edilebilir: Python'da birkaç milisaniye, optimize kodda mikrosaniyeler. Mozilla, kurtarmayı baby-step giant-step veya daha basitçe ilk 256 P-384 anahtarını üretmek olarak tanımlıyor. Kamuya açık analizde bir anahtarın d = 4 olduğu bildirildi; bu spesifik değer ikincil kaynaktır, ancak aralıkla tutarlıdır. Değerin 4 veya 200 olması sonucu değiştirmez.

Bu, güvenlik marjını azaltan kısmi bir zayıflık değildir. Özel skaleri 256'nın altında olan 384 bitlik bir eğrinin en fazla 8 bit entropisi vardır. Sertifikanın anahtarı fiilen açıktır.

Sekiz sertifika

Kamuya açık olay JSON'u altı TLS ve iki kod imzalama ara kurumunu listeler. Her biri hem eMudhra kökü hem de Sectigo AAA Certificate Services çapraz imzası altında görünür: toplam 16 entry, sekiz benzersiz anahtar.

Kök adlandırması çözülmemiş. Olay JSON'u altı TLS ara kurumunu emSign Root TLS CA - G3 altında, iki kod imzalama ara kurumunu emSign Root CS CA - G3 altında doğrudan veren olarak listeliyor; emSign ECC Root CA - G3 ise çapraz imzalayıcı olarak görünüyor. eMudhra ise ara kurumların bu ECC kökünün altında oturduğunu söylüyor. Mozilla hata kaydı 2083449'un 21 numaralı yorumu düzenlemenin emSign ECC Root CA - G3e kadar uzanan zincirlerde durdurulduğunu, Chrome'un yazısı da kaldırılan kök olarak bu kökü adlandırdığını kaydediyor. Bu kaynaklar uzlaştırılmadı; tablodaki "veren kök" sütunu JSON'a dayanıyor, eMudhra ifadesine değil.

TLS ara kurumlarının notBefore değeri olay verisine göre 30 Nisan 2025'tir. Sectigo çapraz imzalı sürümler 14 Mayıs 2025'te düzenlendi. eMudhra kaynaklı CRL kayıtları 18 Ekim 2026, 09:24–09:38 UTC itibarıyla görünüyor (Mozilla hata yorumu 1, iptali 09:38 UTC olarak bildiriyor). Sectigo çapraz imzasının CRL zamanı 19 Ekim 2026, 10:35:36 UTC, olay verisinden alındı ve bu denetimde doğrulanmadı. Tüm kayıtlar reason: ca_compromise listeliyor.

[ÇIKARIM] Her TLS ara kurumunun iki zincirde de aynı subject key identifier değerine sahip olduğu görünüyor; çapraz imza yeni anahtar üretmez. Bu doğruysa SPKI hash'ini bloklamak hem emSign hem Sectigo yolunu aynı anda kapatır. Chrome'un CRLSet kaydı, yazısına göre SPKI hash'lerine bağlıydı.

Zaman çizelgesi ve çözülmemiş tek tutarsızlık

eMudhra'nın kamuya açık açıklaması haberdar olunduğunu 17 Ekim geç akşam Hindistan saatinde ve iptalin 18 Ekim'de yapıldığını söylüyor. Mozilla raporu 17 Ekim 20:06 UTC'de aldı; Chrome raporu 17 Ekim 18:05 UTC'de kaydetti. CRL zaman damgaları UTC'de 18 Ekim'de başlıyor. Bu, saat cinsinden büyük bir fark değil; ancak anahtarın 18 ay boyunca kurtarılabilir olduğu bir olayda önemlidir. Kesin sıralamayı CA'nın nihai kök neden raporu uzlaştırmalıdır; bir blog, birincil kaynaklar çelişirken tek ve otoriter bir zaman çizelgesi uydurmamalıdır.

Tarayıcılar neden önce SPKI, sonra kök?

Tarayıcının iki ayrı kaldıracı vardır:

1. Belirli bir ara kurumu bloklamak. Chrome, ara kurumların SPKI hash'lerine bağlı bir CRLSet kaydı dağıttı. Firefox OneCRL kullandı. Bu mekanizmalar tarayıcı yeniden başlatmadan uygulanır ve dakikalar-saatler içinde yayılır.
2. Kökü kaldırmak. Bu daha geniş, daha yavaş ve kök altındaki ilgisiz ara kurumlar dahil her sertifikayı etkiler. Chrome, emSign ECC Root CA - G3 kaldırmayı 27 Ekim PDT'ye planladı. Mozilla NSS 3.131.1 aynı kökü 20 Ekim 2026'da güven listesinden kaldırdı (Bugzilla 2084101); bu, Chrome'un planlı kaldırmasından ayrı bir eylemdir.

SPKI bloğu daha dar ve hızlıdır. Kök kaldırma, OneCRL veya CRLSet tüketmeyen istemciler için kalıcı kontroldür; ancak o kök altındaki diğer hiyerarşiler için yan etki yaratır. İki adımın günler arayla yapılmasının nedeni budur.

Chrome'un yazısında anlaşılması gereken bir ayrıntı var: bloktan önce altı TLS ara kurumuna bağlı son kullanıcı sertifikası için hiçbir sertifika şeffaflığı (CT) kaydı yoktu. CT'de olmayan bir sertifika, CT zorunluluğu uygulayan istemciye karşı kullanılamaz; ancak CT uygulamayan istemcilere karşı kullanılabilir. CT'de yokluk, kullanılmadığının kanıtı değil, çevrimdışı kötüye kullanılmadığının da kanıtı değildir.

Hangi taraf neyi değiştirdi?

Cloudflare duyurusu, tarayıcı sorununu sunucu sorunundan ayırdığı için faydalı. Cloudflare kendi hizmetlerinde aktif istismar bulmadı; ancak paylaşılan güven depolarını, temel imajları ve origin/uzak uç nokta doğrulayan ürünleri güncellemek zorunda kaldı. Müşteri yönlendirmesi net: bir SDK'yı güncellemek altındaki doğrulayıcıyı değiştirmeyebilir ve güncelleme sonrası sertifika hataları doğrulamayı kapatarak "düzeltilmemelidir".

Güven deposu durumu: tarayıcılar kolay kısım

Takip sitesi en kapsamlı kamuya açık matrisi tutuyor. Aşağıdaki tablo bir anlık görüntüdür, kalıcı gerçek değildir; işlem öncesi güncel paket sürümünü doğrulayın.

İki uyarı kolayca gözden kaçar:

• macOS tek bir güven deposu değildir. Bazı araçlar, belirli curl, git ve Python derlemeleri dahil, /etc/ssl/cert.pem gibi bir yoldan paket yükler. İşletim sistemini güncellemek, belirli bir aracın yüklediği paketi güncellemeyebilir; bu makale o paketin iptali nasıl ele aldığını doğrulamadı. Aracın gerçekte kullandığı yolu kontrol edin.
• Temel imaj bir anlık görüntüdür. Dockerfile eski bir digest'i sabitliyorsa, CA dosyasını ana makineden kopyalıyorsa veya uygulama içine gömülü bir paket kuruyorsa konteyneri yeniden derlemek işe yaramaz. Derleme günlüğünü değil, çalışan konteynerin içindeki paketi kontrol edin.

Kendinizi kandırmadan istemcilerinizi nasıl test edersiniz?

Olay sitesi bu test sunucularını listeliyor. DNS kayıtları çözümleniyor; ancak bunların ne sunduğu ve bu amaç için açık kalıp kalmayacağı doğrulanmadı.

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Yorum sezgisel değildir ve sık sık ters aktarılır:

• Sertifika hatası, istemcinin ele geçen ara kurumlara güvenmediği anlamına gelir. İstenen sonuç budur.
• Temiz TLS bağlantısı, istemcinin hâlâ ele geçen zincire güvendiği anlamına gelir. Bu bir başarısızlıktır.

Her bağlantı hatasını başarı saymayın. Hata DNS, proxy, güvenlik duvarı, süresi dolmuş test sertifikası veya ana makine adı uyuşmazlığından da gelebilir. Hatadanın eMudhra zinciri için sertifika doğrulama hatası olduğunu, genel bir ağ hatası olmadığını doğrulayın. Yalnızca sistem curl'ünü değil, uygulamanın kullandığı tam ikiliyi ve güven yapılandırmasını test edin.

Canlı bir zincir için sunucunun gerçekte gönderdiğini inceleyin:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

LibreSSL tabanlı macOS araçlarında ilk s_client komutu 1 ile çıkabilir; çıktı yine de işlenir, ancak pipefail kullanan betiklerde pipeline başarısız görünebilir. OpenSSL 3/4 ile test edildi.

Bir sertifika dosyası için subject, issuer ve SPKI hash'ini yazdırın:

openssl x509 -in cert.pem -noout -subject -issuer
openssl x509 -in cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | openssl base64

Doğru tanımlayıcı sertifika seri numarası veya subject adı değil, SPKI hash'idir. Aynı anahtar hem emSign hem Sectigo zincirinde görünür.

Zayıf anahtar iddiasını kendiniz doğrulayın

Bu, yalnızca açık sertifikayla yapılan salt okunur bir kontroldür:

from cryptography import x509
from cryptography.hazmat.primitives.asymmetric import ec

def find_small_scalar(cert_path: str, limit: int = 256):
    with open(cert_path, "rb") as f:
        cert = x509.load_pem_x509_certificate(f.read())
    target = cert.public_key().public_numbers()
    for d in range(1, limit):
        cand = ec.derive_private_key(d, ec.SECP384R1()).public_key().public_numbers()
        if (cand.x, cand.y) == (target.x, target.y):
            return d
    return None

print(find_small_scalar("intermediate.pem"))

Örnek cryptography paketini gerektirir. Sistem Python'unda eksikse python3 -m pip install cryptography veya izole ortamda uv run --with cryptography python weak-scalar.py kullanın.

None dışında bir sonuç, özel anahtarın kurtarılabilir olduğu anlamına gelir. Bunu envanter yerine kullanmayın: laboratuvarda meşru küçük test skalerleri olabilir ve bu kontrolün kapsamadığı başka zayıf anahtar kalıpları da vardır.

Go CVE'si: kripto hatası değil, kara liste

Go issue 82345 (başlık: "crypto/x509: mitigation for security concerns with a specific Certificate Authority"), CL 851047 ve GO-2026-6809 kaydı doğrulandı; CVE-2026-111943 eşleşmesi pkg.go.dev'de teyit edildi. Kod düzeyindeki açıklama bu denetimde incelenmedi.

Go, güven deposu yanıtı için CVE-2026-111943 (GO-2026-6809) atadı. Duyuru dikkatli: çoğu platformda Go sistem köklerini kullanır, dolayısıyla güncellenmiş işletim sistemi Go programlarını otomatik korur. Daha dar durumlarda program hâlâ ele geçen ara kurumlara güvenebilir. Doğrulayıcının bu ara kurumları nasıl reddettiği (kod davranışı) bu denetimde incelenmedi.

Issue 82345 için backport commit'leri: release-branch.go1.26 üzerinde aa64342a9e13affffea3e989d67e574475af5a78, release-branch.go1.27 üzerinde 90617fb7ceb59cf08bee7826bb51b8c8fb8c11de. Ana dal CL'si 851047. Eski 7f86f957… referansı issue'da yer almıyor. Düzeltilmiş sürümler durum sayfasında Go 1.26.10 ve 1.27.3 olarak listeleniyor. Kod düzeyindeki ayrıntılar (SPKI kara listesi, platform doğrulayıcı filtreleri, crypto/x509.Certificate.Verify) bu denetimde incelenmedi.

Buna "Go güvenlik açığı" demek kesin değildir. Kusur eMudhra'nın anahtar üretimindeydi. Go, aşağı yönde bir güven kararı değiştiği ve kurumların izleme ve değişiklik kayıtları için bir tanımlayıcıya ihtiyacı olduğu için CVE atadı. Tarama aracının bileti gerçek iyileştirmeyi gölgelemesine izin vermeyin: doğrulayıcıyı güncelleyin ve zincire her yerde güvenmeyi bırakın.

Kurumsal maruziyet: gerçekte nerede acıtır?

Kamuya açık web görece iyi çıktı. eMudhra, sekiz ara kurumdan yedisinin üretimde hiç kullanılmadığını ve üretimdeki tek TLS ara kurumunun hiç son kullanıcı sertifikası düzenlemediğini söylüyor; bu iddialar bu denetimde doğrulanmadı. Chrome altı TLS ara kurumu için CT kaydı olmadığını gözlemledi. Bu, kamuya açık yanlış düzenleme kanıtını sınırlar. Aşağıdaki maruziyetleri ortadan kaldırmaz.

Bir ayrım daha: kök güvensizliği ve ara kurum bloğu farklı etki alanlarına sahiptir. Hâlâ köke güvenen bir istemci, o kök altındaki farklı ve ele geçmemiş bir ara kurumdan gelen sertifikayı doğrulayabilir. Kökü kaldırmış istemci doğrulayamaz. Sekiz bilinen ara kurumu bloklamanın, kökü her yerde kaldırmakla eşdeğer olduğunu varsaymayın.

İyileştirme planı

İlk 24 saat

1. Ortamdaki her güven deposunu envanterleyin: işletim sistemi, dil çalışma zamanları, tarayıcılar, Java, konteynerler, cihazlar, CI çalıştırıcıları ve mTLS eşleri.
2. Önce yüksek değerli doğrulayıcıları güncelleyin: kamuya açık TLS sonlandırma, service mesh, API ağ geçitleri, kod imzalama doğrulaması ve TLS denetim proxy'leri.
3. Gerçek doğrulayıcıyla test edin. Olay test sunucularını ve kendi zincirinizi kullanın; hatanın DNS veya proxy gürültüsü değil sertifika hatası olduğunu doğrulayın.
4. Etkilenen ara kuruma bağlı sunucu sertifikalarını yeniden düzenleyin. İstemcilerin güncellenmesini beklemeyin; etkilenmemiş bir köke karşı doğrulanan zincir sunun.
5. Pinleri kontrol edin. Bir mobil uygulama veya cihaz eski ara kurumu sabitliyorsa, kesintiden sonra değil kök kaldırmadan önce güncelleme hazırlayın.
6. Hataları susturmak için doğrulamayı kapatmayın. Bu, güven deposu güncellemesini yeni bir güvenlik açığına çevirir.

İlk hafta

1. Konteyner imajlarını ve CI çalıştırıcılarını güncel temellerden yeniden derleyin; çalışan konteynerin içindeki paketi doğrulayın.
2. İmzalayanı etkilenen hiyerarşiye bağlanan kod eserlerini ve paketleri yeniden imzalayın; imza doğrulamasını temiz bir makinede test edin.
3. Etkilenen ara kurumlar altında düzenlenen sertifikalar için günlükleri ve CT'yi arayın; kendi işlettiğiniz iç CT günlükleri dahil.
4. Üçüncü taraf ve tedarikçi beyanlarını gözden geçirin. "HSM kullanıyoruz" yanıtı, "bu sertifikayı hangi anahtar üretti?" sorusunun yanıtı değildir.
5. Zaman çizelgesini kendi sertifika envanterinizle uzlaştırın: her sertifika ne zaman ortaya çıktı ve hangi istemciler kabul edebilirdi?

İlk ay

1. CA ve sertifika lint süreçlerine zayıf anahtar kontrolleri ekleyin. Küçük skaler kontrolü ucuzdur ve bütün bir hata sınıfını yakalar.
2. İmzalamadan önce sertifikanın açık anahtarının amaçlanan özel anahtarla eşleştiğini bağımsız olarak doğrulamayı zorunlu kılın. Benzer etiketler kimlik değildir.
3. Konteyner ve cihaz envanterlerine güven deposu sapma tespiti ekleyin. Bilinen bir güncelleme penceresinde digest değişmediyse uyarın.
4. Sabitleme ve sabit kodlanmış güveni yeniden değerlendirin. Sabitleme bir kullanılabilirlik ödünleşimidir; rotasyon planını belgeleyin ve test edin.
5. Bir sonraki CA olayı için masa tatbikatı yapın: güven depolarının sahibi kim, kim yeniden düzenleyebilir, kesintiyi kim duyurur?

Tespit ve olay müdahalesi

Anahtarların kullanıldığından şüpheleniyorsanız kanıt tipik bir web istismarına benzemez.

• Sertifika şeffaflığı izleme. Etkilenen ara kurumlara veya emSign ECC Root CA - G3 köküne bağlı yeni sertifikaları izleyin. Bloktan sonra bile CT'ye kaydedilmiş bir sertifika, anahtarın kullanıldığının kanıtıdır.
• Zincir anomalileri. Sekiz ara kurumu içeren üst akış zincirlerinde, özellikle kamuya açık CA kullanmaması gereken iç hizmetlerde uyarın.
• Beklenmeyen güven çapaları. Her çalışan konteynerin ve cihazın güven deposunu üreticinin güncel paketiyle karşılaştırın. 18 Ekim öncesinde donmuş bir digest bulgudur.
• Pin hataları. Daha önce başarılı olup aniden başarısız olan istemci eski zincire sabitlenmiş olabilir. Bu bir semptomdur, saldırı kanıtı olmak zorunda değildir.
• Kod imzalama hataları. Güven güncellemesi sonrası imza doğrulama hatalarında artış, yeniden imzalanması gereken eserleri gösterebilir.
• Araya girme göstergeleri. Hassas trafik taşıyan yollarda yeni TLS sonlandırma noktaları, beklenmeyen üst akış proxy'leri, DNS değişiklikleri veya BGP anomalileri.

Sahte bir sertifikadan şüpheleniliyorsa:

1. Herhangi bir şeyi döndürmeden önce sertifikayı, zinciri ve sunum günlüklerini koruyun.
2. Zinciri hangi doğrulayıcıların kabul ettiğini belirleyin: tarayıcılar, mobil uygulamalar, iç hizmetler, mTLS eşleri, kod imzalama araçları.
3. Etkilenmemiş bir hiyerarşiden iptal edin ve yeniden düzenleyin; pinleri ve güven depolarını tek koordineli pencerede güncelleyin.
4. Trafiğe araya girildiyse kimlik bilgilerini ve oturumları potansiyel olarak açığa çıkmış sayın.
5. CA'ya, ilgili kök programa ve yargı alanınızın gerektirdiği düzenleyiciye bildirin.

CA ve ekosistem ne öğrenmeli?

• Anahtar töreni kontrolleri kimliği anahtar malzemesine bağlamalıdır. Etiket bir kontrol değildir. CSR'deki açık anahtar, amaçlanan anahtarla ikinci bir kişi ve otomatik kontrolle doğrulanmalıdır.
• Zayıf anahtar tespiti hattın parçası olmalıdır. Küçük skalerleri numaralandırmak önemsizdir. Sertifika bir CT günlüğüne veya kök programa ulaşmadan önce çalışmalıdır.
• İptal evrensel bir çözüm değildir. Birçok istemci CRL veya OCSP kontrol etmez. Kök kaldırma ve üretici güncellemeleri kalıcı kontrollerdir ve yavaştır.
• Asıl maruziyet uzun kuyruktur. Tarayıcılar bir anahtarla değiştirebilir. Java anahtar depoları, cihazlar ve gömülü paketler değiştiremez. Saatlerle değil aylarla planlayın.
• Zaman çizelgeleri uzlaştırılabilir olmalıdır. CA'nın anlatımı güvenen taraf günlüklerinden farklıysa zaman damgaları yayımlayın ve farkı açıklayın. Üzerini örtmeyin.
• "CT'de yok" "kullanılmadı" değildir. Bu bir kanıttır, kanıtın tamamı değil. Özel PKI ve CT dışı istemciler bu kanıtın dışındadır.

Teknik SSS

P-384 kırıldı mı?

Hayır. Eğri ve ECDSA sağlam. Özel skalerler beklenen aralığın dışında üretildi. 8 bit skalerli 384 bitlik eğri, eğri nedeniyle değil skaler nedeniyle zayıftır.

Bu, saldırganın her web sitesini taklit edebileceği anlamına mı gelir?

Yalnızca etkilenen zincire hâlâ güvenen istemci için ve yalnızca saldırgan bir anahtar kurtarıp sertifika düzenlediyse. Kamuya açık CT verisi, bloktan önce altı TLS ara kurumu altında son kullanıcı sertifikası olmadığını gösteriyor; bu, kamuya açık web'de yanlış düzenleme kanıtını sınırlar. İç, sabitlenmiş ve CT dışı istemciler ayrı risklerdir.

Chrome ve Firefox'u güncelledim. Bitti mi?

Hayır. Sunucuları, konteynerleri, Java uygulamalarını, mTLS eşlerini, kod imzalama doğrulayıcılarını ve gömülü cihazları kontrol edin. Tarayıcılar en görünür güvenen taraftır, tek taraf değildir.

Chrome neden kökü hemen değil 27 Ekim'de kaldırıyor?

Kök kaldırma, ara kurum bloğundan daha geniş ve yavaştır. Kök altındaki her sertifikayı etkiler, güncelleme kanallarından yayılmalıdır ve ilgisiz hiyerarşileri kırabilir. Chrome, kök kaldırma hazırlanırken acil riski azaltmak için altı TLS ara kurumunu 17 Ekim'de SPKI hash ile blokladı.

CVE-2026-111943 güvenlik açığı mı?

Go güven deposu değişikliği için bir izleme tanımlayıcısıdır. Asıl kusur eMudhra'nın anahtar üretimidir. Go düzeltmesi, işletim sistemi güncellemesini almayan programların bilinen ara kurumları yine reddetmesi için crypto/x509 içinde bir kara listedir.

session.upload_progress veya memory_limit burada önemli mi?

Hayır. Bunlar ayrı PHP2Shell analizine aittir. Bu olay bir PKI anahtar üretim hatasıdır; PHP yapılandırmasının buna etkisi yoktur.

Bilinen sınırlamalar

• KGC betik hatasının kesin kod düzeyindeki kök nedeni yayımlanmadı. eMudhra incelemesinin sürdüğünü söylüyor.
• "Yedisi hiç kullanılmadı; biri sertifika düzenlemedi" iddiası CA'nın beyanıdır; crt.sh sorgusu bu denetimde yapılmadı. Özel PKI veya CT dışı kullanımı kapsamaz.
• Bun ve Erlang satırları takip sitesinin 20 Ekim 2026 civarındaki anlık görüntüsünü yansıtır ve değişmiş olabilir. Java satırı 21 Ekim OpenJDK duyurusuyla güncellendi.
• d = 4 örneği ikincil kaynaktır; bağımsız olarak kurtardığımız bir değer değildir. 256'nın altındaki aralık Mozilla'nın birincil analiziyle doğrulanmıştır.
• Zincire hâlâ güvenen istemcilerin kesin sayısı bilinemez; her tahmin spekülasyon olur.

Kaynaklar ve ileri okuma

• eMudhra olay sayfası, etkilenen ara kurum JSON'u ve test sunucuları: emudhra.we-have-a-problem.com
• Mozilla bug 2083449, bağımsız anahtar kurtarma ve eMudhra yanıtı: bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Mozilla Security Blog, Firefox yanıtı (bu denetimde açılamadı, 403): Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Chrome Root Program, Chrome ve Android yanıtı: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• eMudhra açıklaması: eMudhra Statement on Recent Certificate Security Incident
• Cloudflare yanıtı ve müşteri yönlendirmesi: Cloudflare's response to the eMudhra certificate compromise
• Go güvenlik açığı veritabanı: GO-2026-6809
• Go sorunu ve düzeltmesi: go.dev/issue/82345, go.dev/cl/851047
• Red Hat RHSB-2026-012 (sayfanın varlığı doğrulandı; Bugzilla 2556046): access.redhat.com/security/vulnerabilities/RHSB-2026-012
• NSS 3.131.1 duyurusu (20 Ekim 2026, oss-security): openwall.com/lists/oss-security/2026/10/20/30
• Sertifika şeffaflığı araması: crt.sh (ana sayfa erişildi; sorgu yapılmadı)

Güncelleme geçmişi

• 22 Ekim 2026: Go kara liste analizi eklendi; test sunucusu yorumu düzeltildi; "256 bit anahtar" ifadesi "sayısal skaler 256'dan küçük" olarak düzeltildi; FreeBSD ca_root_nss 1.131.1 olarak güncellendi; KGC wrap/unwrap kök nedeni ve Mozilla'nın bağımsız anahtar kurtarması eklendi.