Sadece merak ediyordum. Çok sayıda SSL sertifikası kullanıyoruz. Günümüzde neredeyse sadece letsencrypt kullanıyoruz (teşekkürler!). Bu sertifikaların en alt satırında, sertifika üzerindeki etki alanı adlarının sahip olduğunun kanıtı, DNS kayıtlarını veya bu etki alanları altındaki web sitesini değiştirme yetkisinden gelir. DNS kanıtı, DNS'ye TXT kaydı olarak bazı anahtarların (letsencrypt tarafından verilen) eklenmesinden gelir.

Bu nedenle, bir alanın DNS kayıtlarını değiştirebilmeniz için yeterli kanıt varsa, neden DNS'de parmak izi ile kendinden imzalı sertifikalar kullanmıyorsunuz?

Ben bu letsencrypt (ve diğer CA) DNS tabanlı prosedürü ile tam olarak aynı miktarda güven verir söyleyebilirim:

1. Kendinden imzalı bir CA oluşturun (çeşitli işlemlerin adımlarını uygulayın)
2. Bazı alan adları için sertifika oluşturma
3. 2. adımdaki sertifikayı 1. adımdaki CA ile imzalayın. Artık güvenilir olmayan bir CA tarafından imzalanmış temel bir sertifikanız var
4. Her bir alan adının DNS'sine bir TXT (veya özel) kaydı ekleyin ve şunu belirtin: bu etki alanının sertifikasını bu CA ile imzaladık. Gibi: 'CA = -Fingerpint of CA-'
5. Bir tarayıcı sertifikayı indirir ve CA / CA sertifikasının parmak izini belirtilen etki alanı için DNS'deki verilerle karşılaştırarak doğrular.

Bu, herhangi bir temel SSL sertifikası ile aynı güven seviyesine sahip üçüncü taraf müdahalesi olmadan güvenilir kendinden imzalı sertifikalar oluşturmayı mümkün kılacaktır. DNS erişiminiz olduğu sürece sertifikanız geçerlidir. DNS kaydındaki değişikliklerde güvenin ortadan kalktığından emin olmak için CA artı SOA kaydından bir karma yapmak gibi şifreleme gibi bazı DNSSEC bile eklenebilir.

Bu daha önce düşünülmüş mü?

Jelmer

Bunu mümkün kılacak temel altyapı var ve adlandırılmış varlıkların DNS tabanlı kimlik doğrulaması (DANE) olarak adlandırılıyor ve RFC6698'de belirtiliyor . TLSASon varlığın sertifikasını veya ortak anahtarını veya zincirdeki CA'larından birini belirten bir kaynak kaydı aracılığıyla çalışır (Aslında dört farklı tür vardır, ayrıntılar için RFC'ye bakın).

Benimseme

Ancak DANE henüz yaygın bir şekilde benimsenmedi. VeriSign izler DNSSEC ve DANE benimsenmesini ve zamanla büyümesini izler :

Karşılaştırma için, VeriSign'a göre yaklaşık 2,7 milyon DNS bölgesi var, bu da tüm bölgelerin% 1'inden biraz fazlasının en az bir TLSA kaydına sahip olduğu anlamına geliyor.

Yetkili bir cevap veremiyorum, neden DANE, ama işte spekülasyonlarım:

DANE, Sertifika İptal Listeleri (CRL) ve Çevrimiçi Sertifika Durum Protokolü (OCSP) ile aynı sorundan muzdariptir. Sunulan bir sertifikanın geçerliliğini doğrulamak için üçüncü bir tarafla temasa geçilmelidir. Hanno Böck , bunun pratikte neden büyük bir sorun olduğu konusunda iyi bir genel bakış sunuyor . Üçüncü tarafa ulaşamadığınızda ne yapılacağı konusuna değinir. Tarayıcı satıcıları bu durumda yumuşak başarısızlığı (aka izin) seçti , bu da her şeyi anlamsız hale getirdi ve Chrome nihayetinde 2012'de OCSP'yi devre dışı bırakmaya karar verdi.

DNSSEC

Muhtemelen DNS, CA'ların CRL ve OCSP sunucularından çok daha iyi kullanılabilirlik sunar, ancak yine de çevrimdışı doğrulamayı imkansız hale getirir. Ayrıca DANE, sadece DNSSEC ile birlikte kullanılmalıdır. Normal DNS, kimliği doğrulanmamış UDP üzerinde çalıştığından, sahteciliğe, MITM saldırılarına vb. Oldukça eğilimlidir. DNSSEC'nin benimsenmesi DANE'nin benimsenmesinden çok daha iyidir, ancak yine de her yerde olmaktan çok uzaktır.

Ve DNSSEC ile tekrar yumuşak-arıza problemiyle karşılaşıyoruz. Bildiğim kadarıyla hiçbir büyük sunucu / istemci işletim sistemi varsayılan olarak bir doğrulayan DNSSEC çözümleyici sağlamaz.

Sonra bir de iptal meselesi var. DNSSEC'in iptal mekanizması yoktur ve bunun yerine kısa ömürlü tuşlara dayanır.

Yazılım desteği

Katılan tüm yazılımlar DANE desteğini uygulamalıdır.

Teorik olarak, bunun kripto kütüphanelerinin işi olacağını ve uygulama geliştiricilerinin çok fazla şey yapmak zorunda olmayacağını düşünebilirsiniz, ancak gerçek şu ki, kriptografik kütüphaneler genellikle sadece ilkelleri sağlar ve uygulamalar çok fazla yapılandırma ve kurulum yapmak zorunda kalırlar (ve maalesef işleri yanlış anlamanın birçok yolu var).

Herhangi bir büyük web sunucusunun (örneğin Apache veya nginx) örneğin DANE'yi uyguladığını veya bunu yapmayı planladığını bilmiyorum. Web sunucuları burada özel bir öneme sahiptir, çünkü web teknolojileri üzerine giderek daha fazla şey üretilmektedir ve bu nedenle genellikle ilklerin uygulandığı ilk şeydir.

Karşılaştırma olarak CRL, OCSP ve OCSP Zımbalamalarına baktığımızda, DANE evlat edinme öyküsünün nasıl gideceğini çıkarabiliriz. Yalnızca OpenSSL, libnss, GnuTLS, vb. Kullanan bazı uygulamalar bu özellikleri desteklemektedir. Apache veya nginx gibi büyük yazılımların bunu desteklemesi biraz zaman aldı ve tekrar Hanno Böck'ün makalesine atıfta bulunarak yanlış anladılar ve uygulamaları hatalı. Postfix veya Dovecot gibi diğer önemli yazılım projeleri OCSP'yi desteklemezve temel olarak dosya sistemindeki bir dosyaya işaret eden çok sınırlı CRL işlevselliğine sahiptir (düzenli olarak yeniden okunması gerekmez, bu nedenle sunucunuzu manuel olarak yeniden yüklemeniz gerekir vb.). Bunların, sıklıkla TLS kullanan projeler olduğunu unutmayın. Ardından, TLS'nin daha az yaygın olduğu şeylere, örneğin PostgreSQL / MySQL gibi bakmaya başlayabilir ve belki de en iyi ihtimalle CRL'ler sunabilirler.

Bu yüzden modern web sunucularını bile uygulayamadım ve diğer birçok yazılım OCSP ve CRL'yi uygulamak için bile var, 5 yıllık kurumsal uygulama veya cihazınızda iyi şanslar.

Potansiyel uygulamalar

DANE'yi gerçekte nerede kullanabilirsiniz? Şu an itibariyle, genel internette değil. Sunucuyu ve istemciyi kontrol ederseniz, belki de bir seçenek olabilir, ancak bu durumda, Genel Anahtar Sabitleme'ye başvurabilirsiniz.

Posta alanında DANE biraz çekiş alıyor çünkü SMTP'nin en uzun süre herhangi bir kimlik doğrulamalı taşıma şifrelemesi yoktu. SMTP sunucuları bazen birbirleri arasında TLS kullandılar, ancak sertifikalardaki adların gerçekten eşleştiğini doğrulamadılar, şimdi DANE aracılığıyla bunu kontrol etmeye başlıyorlar.

Farklı sertifika doğrulama prosedürleri türleri

Düzenli CA imzalı sertifikalarda, birkaç sertifika doğrulama düzeyi vardır:

• Alan Adı Doğrulama (DV)
  Yalnızca alan adı sahipliği doğrulanır, yalnızca alan adı sertifikada "Konu" olarak gösterilir
• Kuruluş Doğrulaması (OV)
  Alan adı ve sahip adı doğrulandı, alan adı ve sahip adı sertifikada "Konu" olarak gösterildi
• Genişletilmiş Doğrulama (EV) Sahip
  kuruluşun, alan adının ve sahip adının daha titiz bir şekilde doğrulanması sertifikada "Konu", sahip adıyla yeşil çubuk olarak gösterilir

Tanımladığınız ve yenisini önerdiğiniz işlem yalnızca en düşük düzey olan Etki Alanı Doğrulaması (DV) için geçerlidir.

DV, LetsEncrypt'in yaptığı gibi doğrulama işleminin otomatikleştirilmesinin nispeten basit olduğu düzeydir ve bir güven bağlantısı için tek kaynak olarak kullanıldığında DNS'nin sağlayabileceğile aynı düzeyde güven sağlar (UI etkileri, sertifika güvenilir ancak hiçbir şekilde doğrulanmamış ek veriler içerir).

Adlandırılmış Varlıkların DNS Tabanlı Kimlik Doğrulaması (DANE)

DANE , DNS'deki TLS istemcileri için güven tutturma bilgilerini yayınlamak üzere DNSSEC'nin üzerine kuruludur (DNS veri özgünlüğü çok önemlidir).

Bu kullanan TLSARR tipi ve sertifika veya ortak anahtarı (ya da tespit için kullanılabilecek seçici ya da (başarılı düzenli sertifika zinciri doğrulama gerektirmeden, son bir oluşum veya CA ya) sertifika kullanım ) ve nasıl sertifika / key verileri kayıtta gösterilir ( eşleşen tip ).

TLSAKayıt sahibinin adı portu ve protokolü (örn belirten bir önek _443._tcp) ve rdata gösterir cert usage, selectorve matching typesertifika ek olarak modları / anahtar veri eşleşecek. Bu parametrelerin özellikleri için RFC6698'in 2.1 bölümüne bakın .

TLSAÖrneğin bir kayıt şöyle görünebilir:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

Kullanım modlarında 2veya 3(yalnızca TLSA güven bağlantısının kullanımını gösterir), DANE kullanan bir istemci, genel olarak güvenilen bir CA tarafından imzalanmamış ancak TLSAkayıtla eşleşen bir sertifikayı kabul eder .
Bu, kavramsal olarak sorunuzda önerdiğinizle aynıdır.

Yakalayış? DANE bilinçli istemciler şu anda az ya da çok yok, bir sorun DNSSEC'nin kendisinin DANE'nin çıkarması için muhtemelen gerekli olan kadar yaygın bir şekilde konuşlandırılmamış olması (özellikle istemci makinesinde doğrulama). DANE'nin kimliği doğrulanmış DNS verilerine dayanan ilk potansiyel olarak büyük yeni kullanım durumlarından biri olduğu düşünülürse, muhtemelen bir tavuk ve yumurta sorunu.

DNSSEC ve DANE doğrulaması ekleyen bir tarayıcı eklentisi var, bunun dışında bu noktada ana akımın yakınında herhangi bir yerde pek bir şey yok. Ayrıca, yerel olarak desteklenmekten ziyade bir eklenti olarak, genel kullanım söz konusu olduğunda, herhangi bir şeyden ziyade bir kavram kanıtı olarak hizmet eder.

Bu yapılabilir. Dikkate alınmıştır. Hala olabilir, ama çok fazla hareket olmadı.