deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak Cloudflare blog

Cloudflare'ın 1.1.1.1'i kuantum sonrası ML-DSA-44 DNSSEC imzalarını doğrulamaya başladı

Cloudflare'ın genel çözümleyicisi artık NIST'in ML-DSA-44 ile oluşturulan DNSSEC imzalarını doğruluyor; böylece 2.420 baytlık imzalar ve sürüm düşürme koruması internet ölçeğinde test edilmiş oluyor.

Cloudflare'ın 1.1.1.1'i kuantum sonrası ML-DSA-44 DNSSEC imzalarını doğrulamaya başladı

Cloudflare neyi etkinleştirdi

Cloudflare'ın genel çözümleyicisi 1.1.1.1 artık NIST tarafından standartlaştırılan kuantum sonrası imza algoritması ML-DSA-44 ile oluşturulan DNSSEC imzalarını doğruluyor. Cloudflare bloguna göre bu, DNSSEC'i bugünkü algoritmaların artık güvenli olmadığı bir geleceğe hazırlamanın ilk adımı ve Cloudflare'ın 2029'a kadar tam kuantum sonrası güvenliğe ulaşma hedefinin bir parçası. Şirket, dağıtılmış RSA ve ECDSA anahtarlarını kırmaya yetecek kadar güçlü bir kuantum bilgisayarın 2030'a kadar var olabileceği ihtimaline karşı hazırlandığını söylüyor.

DNSSEC, DNS kayıtlarını imzalar; böylece doğrulayıcı bir çözümleyici, DNS kökünden istenen alan adına kadar uzanan imzalı kayıt zincirini takip ederek yanıtın gerçek olduğunu doğrulayabilir. DNSSEC olmazsa, sahte bir yanıt üreten bir saldırgan kullanıcıları kendi seçtiği bir adrese yönlendirebilir. Bugün kullanılan neredeyse tüm algoritmalar, kuantum bilgisayarların sonuçta çözeceği beklenen matematiksel problemlere dayanır; bu da bir saldırganın özel anahtarları ele geçirip doğrulayıcıların kabul edeceği imzalar üretmesine olanak tanır.

Cloudflare, DNSSEC'in gizlilik değil özgünlük sağladığı için "şimdi topla, sonra şifre çöz" saldırılarına maruz kalmadığını belirtiyor. Şimdi başlama nedeni koordinasyon: DNSSEC geçişi yetkili sunucular, kayıt defterleri, kayıt kuruluşları ve doğrulayıcı çözümleyiciler genelinde değişiklikler gerektiriyor ve en sonunda DNS köküne ulaşması gerekiyor; orada ele geçirilen bir imzalama anahtarı, saldırganın altındaki her bölge için sahte bir doğrulama yolu üretmesine izin verirdi.

Pakete sığmayan imza

Başlıca mühendislik engeli boyut. ML-DSA-44 imzası 2.420 bayt ve açık anahtarı 1.312 bayt; ECDSA P-256 ile karşılaştırıldığında imza 64 bayt ve anahtar 64 bayt. Klasik UDP üzerinden DNS mesajları 512 baytla sınırlıydı; bugün birçok uygulama IPv6'nın 1.280 baytlık minimum MTU'suna sığması için muhafazakâr bir 1.232 bayt sınırı duyuruyor ve RFC 9715 en fazla 1.400 bayt öneriyor. Tek başına bir ML-DSA-44 imzası, imzalanan kayıtlar, alan adları, başlıklar ve diğer DNSSEC verileri eklenmeden önce bile tüm bu bütçeleri aşıyor.

Cloudflare'ın konumu, böyle yanıtların parçalanmış UDP olarak gönderilmesinin güvenilmez olduğu ve kaçınılması gerektiği. Bunun yerine yetkili sunucu, çözümleyiciyi başka bir taşıma katmanı üzerinden (genellikle TCP) yeniden denemeye yönlendiren kesilmiş bir yanıt döndürmeli. Baskı noktası, çözümleyicinin ihtiyaç duyduğu anahtarları taşıyan DNSKEY yanıtları: ML-DSA-44 ile hem 1.312 baytlık bir anahtar hem de 2.420 baytlık bir imza içeriyorlar. Geçiş süresince bölgeler eski doğrulayıcılar için geleneksel anahtar ve imzaları yayınlamaya devam edecek ve anahtar devirleri daha fazlasını ekleyerek bu yanıtları yeniden büyütebilir.

Taşıma katmanı yedekliliği Cloudflare için zaten rutin. Yazıda alıntılanan Radar verileri, 1.1.1.1'e gelen sorguların yaklaşık %85'inin UDP üzerinden geldiğini gösteriyor. Çözümleyicinin arkasındaki platform olan Big Pineapple, Gateway DNS dahil diğer servisleri de destekliyor ve tümünde sorguların yaklaşık %60'ı UDP üzerinden gelirken, kalan %40'ı TCP, DNS over TLS veya DNS over HTTPS kullanıyor. Bu rakamlar istemcilerin Cloudflare'e nasıl ulaştığını, 1.1.1.1'in yetkili sunucularla nasıl iletişim kurduğunu değil; orada büyük yanıtlar hâlâ ek TCP yeniden denemelerine yol açabilir.

Sürüm düşürme yolunu kapatmak

İkinci zorluk, eski algoritmaların kolayca kaldırılamaması. Yalnızca ML-DSA-44 yayınlayan bir bölge, bunu desteklemeyen çözümleyiciler için doğrulanamaz hale gelir; bu yüzden pratik yol, geleneksel ve kuantum sonrası imzaları muhtemelen yıllar boyunca yan yana yayınlamak. Ancak RFC 6840, doğrulayıcıların tek bir geçerli yolu kabul etmesi gerektiğini belirtir. ECDSA gibi geleneksel algoritmalar kırıldığında bu kural bir sürüm düşürme yoluna dönüşür: bir saldırgan, çözümleyici ML-DSA-44 desteklese bile kabul edeceği yalnızca ECDSA içeren sahte bir yanıt üretebilir.

Cloudflare bloguna göre 1.1.1.1'in yanıtı, üst bölge tarafından yayınlanan DS kayıtlarını doğrulanmış bir sinyal olarak kullanmak. Doğrulanmış DS RRset'i desteklenen bir kuantum sonrası algoritma için kayıt içerdiğinde, 1.1.1.1 bilinçli olarak daha katı bir yerel politika uygular: en az bir geçerli kuantum sonrası doğrulama yolu gereklidir ve yalnızca geleneksel bir yol artık yeterli değildir. Geçerli bir ML-DSA-44 yolu yoksa doğrulama başarısız olur. Cloudflare, bunun henüz standart DNSSEC davranışı olmadığını, ancak RFC 4035'in ek imzaların denetlenip denetlenmeyeceğine ve çakışmaların nasıl ele alınacağına yerel çözümleyici politikasının karar verebileceğini belirtir.

Neden önemli

Bu bir laboratuvar gösterisinden fazlası. 1.1.1.1 dünyadaki en büyük genel çözümleyicilerden biri olduğundan, ML-DSA-44 doğrulamasını etkinleştirmek DNS ekosistemine iki açık soruyla ilgili operasyonel veri sağlıyor: çok daha büyük yanıtlar güvenilir biçimde taşınabilir mi ve eski çözümleyicilerle uyumluluk, yenilerinin koruması zayıflatılmadan korunabilir mi? Cloudflare'ın kuantum sonrası TLS konusundaki önceki çalışması, daha büyük mesajların ağ yazılımındaki gizli varsayımları ve hataları ortaya çıkardığını ve yaygın istemci benimsenmesinin yıllar sürdüünü gösterdi. DNSSEC geçişine şimdi, Cloudflare'ın çizdiği 2030 tehdit senaryosunun çok öncesinde başlamak, kayıt defterlerine, kayıt kuruluşlarına ve çözümleyici operatörlerine algoritma değişikliğinin DNS hiyerarşisinin köküne ulaşmak zorunda kalmasından önce bu başarısızlıkları erken keşfetme zamanı tanıyor.

  • #dnssec
  • #post-quantum
  • #cloudflare
  • #dns
  • #security

İlgili yazılar