deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Python ve Node, tarayıcıların engellediği eMudhra'nın ele geçirilmiş CA ara sertifikalarına hâlâ güveniyor

Özel anahtarları geri kazanılabilen sekiz eMudhra ara CA'sı ekim ortasında büyük tarayıcılar tarafından engellendi, ancak bir geliştirici testi, Python requests ve Node 22 fetch'in bunlara bağlanan TLS zincirlerini hâlâ kabul ettiğini gösteriyor.

Python ve Node, tarayıcıların engellediği eMudhra'nın ele geçirilmiş CA ara sertifikalarına hâlâ güveniyor

Tarayıcılar ve sunucu runtime'ları, ele geçirilen sekiz eMudhra ara sertifika yetkilisi (CA) konusunda bölündü. Firefox ve Chrome, ara sertifikaların bildirildiği gün olan 17 Ekim'de bunlara güveni kaldırdı; Apple 19'unda, Microsoft ise 20'sinde aynı adımı attı. Buna rağmen Neeraj Sharma'nın dev.to'daki yazısına göre 21 Ekim sabahı, Python'ın requests kütüphanesi ve Node 22'nin yerleşik fetch() fonksiyonu, ele geçirilen ara sertifikalardan birinden alınmış sertifika sunan genel bir test sunucusuna karşı istekleri başarıyla tamamladı ve her biri 200 yanıtı döndürdü. Başka bir deyişle, tarayıcı korunuyor; backend korunmayabilir.

Ele geçirilen neydi

Olayla ilgili disclosure sitesi, eMudhra'nın Nisan 2025'te oluşturduğu sekiz ara CA sertifikasını listeliyor. Altısı TLS sertifikası düzenliyor — G3B ve G3C olmak üzere iki nesil boyunca domain-, organization- ve extended-validation çeşitleri — ikisi ise kod imzalama sertifikası düzenliyor. Her ara sertifika ayrıca Sectigo'nun AAA Certificate Services kök sertifikası tarafından çapraz imzalandığı için olay, sekiz anahtarı paylaşan 16 sertifikayı kapsıyor.

Kusur anahtar üretiminde yatıyor: Yazıya göre özel anahtarlar, genel sertifikalardan geri kazanılabiliyor ve bunu bildiren kişi, sekiz anahtarın her biriyle geçerli bir imza üreterek bunu kanıtladı. Geri kazanılmış bir anahtara sahip olan herkes bu CA'lar altında sertifika düzenleyebilir.

Bir hafifletici faktör var. Disclosure, Nisan 2025'ten beri bu ara sertifikalar için Certificate Transparency kaydı olmadığını belirtiyor ve CT'yi zorunlu kılan tarayıcıların saldırıya uğrayamayacağı sonucuna varıyor. Bu güvence yalnızca tarayıcılara ulaşıyor.

Runtime'lar neden hâlâ güveniyor

İki güven zinciri devrede. İlkinde, bir yaprak sertifika, ele geçirilmiş bir ara sertifika üzerinden emSign Root TLS CA - G3'e — ki bu kök, Apple, Chrome, Microsoft ve Mozilla tarafından dağıtılan emSign ECC Root CA - G3 tarafından çapraz imzalanmış — uzanıyor. İkincisinde zincir, AAA çapraz imzası üzerinden AAA Certificate Services köküne gidiyor; Chrome ve Mozilla bu yolu engellemiş olsa da Apple ve Microsoft hâlâ ona güveniyor.

Tarayıcılar her iki durumu da ara sertifika güven-kaldırma mekanizmalarıyla kapsıyor: Firefox'un OneCRL ve CRLite'ı, Chrome'un CRLSet'leri ile Apple ve Microsoft'un bastığı benzer engellemeler. Yazıya göre Python, Node, Go ve çoğu SDK bunların hiçbirini yapmıyor. Statik bir kök sertifika demeti yüklüyorlar, genellikle iptal (revocation) kontrolünü tamamen atlıyorlar ve CT'yi zorunlu kılmıyorlar. Bağlantı noktası olan bir kök sertifika demette varsa, ele geçirilmiş ara sertifika ona bağlanıyor ve el sıkışma başarıyla sonuçlanıyor.

151 satırlık bir denetim

Yazı, Python standart kütüphanesi ve openssl CLI üzerine kurulmuş, dört alt komutlı bir script paylaşıyor:

  • stores, makinedeki CA demetlerini buluyor — sistem yolları ve certifi — ve DER sertifikasının SHA-256 parmak iziyle eşleştirerek dört bağlantı kökünden birini içerenleri işaretliyor.
  • client, iki genel test sunucusuna karşı canlı bir TLS el sıkışması yapıyor; bir kez Python'ın varsayılan context'iyle, bir kez certifi'nin demetiyle; başarılı bir el sıkışması, o runtime'ın ele geçirilmiş bir ara sertifikaya güvendiğini kanıtlıyor. Yazar, requests, httpx, boto3 ve çoğu SDK'nın doğrulamayı işletim sistemi deposu yerine certifi üzerinden yaptığına dikkat çekiyor.
  • hosts, kendi uç noktalarınızın sunduğu zinciri çekiyor ve genel anahtarı sekiz ele geçirilmiş anahtardan biriyle eşleşen her sertifikayı işaretliyor; eşleştirme SubjectPublicKeyInfo hash'i üzerinden yapıldığı için, kötü bir anahtarı yeniden kullanan yeniden düzenlenmiş bir sertifika da yakalanıyor.
  • verify, disclosure sitesinden alınmış on iki zincirin adını verdiğiniz herhangi bir demete karşı çevrimdışı bir openssl doğrulamasını çalıştırıyor.

Script, bir kontrol başarısız olduğunda 1 çıkış koduyla sonlanıyor, böylece bir CI işini tetikleyebilir.

Neden önemli

Bu, tek bir kütüphanedeki hata değil, TLS ekosistemindeki yapısal bir boşluk. Tarayıcı üreticileri savunmaları katmanlandırıyor — iptal listeleri, CT zorunluluğu — buna karşılık sunucu tarafı runtime'ları, ikisi de olmayan statik güven demetlerine dayanıyor. Bu yüzden Python, Node, Go veya bunların üzerindeki bir SDK ile kurulmuş bir backend, zamanlanmış görev ya da entegrasyon istemcisi, bağlantı kökleri yaygın demetlerde kaldığı sürece geri kazanılan anahtarlardan üretilmiş bir sahte sertifikayı doğrulayabilir. Bu bağlantı noktaları kaldırılana ya da ara sertifikalar demet düzeyinde güvenilmez sayılana kadar pratik yanıt tespit: script'in yaptığı gibi yerel demetleri ve sunulan zincirleri denetleyin ve bu denetimi CI'a bağlayın ki boşluk, biri suistimal etmeden görünür olsun.

  • #tls
  • #pki
  • #python
  • #node-js
  • #security

İlgili yazılar