Neden CAA Kullanılmalı?
Bir CA her zaman şu yöntemleri kullanır: alan adı doğrulaması emin olmak için her SSL /TLS sertifika isteği yetkilendirilir (genellikle bu alan adını kullanan belirli bir siteye bağlandığından emin olarak).
Örneğin, bir CA istekte bulunan kişiye özel bir doğrulama dosyası sağlayabilir. Bu dosyayı web sitesine yerleştirmek, istekte bulunanın bu siteyi de kontrol ettiğini kanıtlar, ancak dosyayı meşruluk bu kontrolün. Bir sitenin kontrolünü ele geçiren bir bilgisayar korsanı, meşru sahip gibi görünebilir ve daha sonra bir SSL talep edebilir ve alabilir /TLS CA'nın standart kontrollerini geçen sertifika ve dolayısıyla görünüyor meşru. Daha sonra geri dönüp bu SSL /TLS bu sitede veya başka yerlerde yaramazlık sertifikası.
CAA, hangi CA'ların bir etki alanı için sertifika vermesine izin verildiğini (veya hatta sertifika vermeyi tamamen kısıtlayarak) tanımlayarak bu tür istismarların engellenmesine yardımcı olur. Bu, bir saldırganın verebileceği zararı sınırlar - bir sitenin kontrolüne sahip olsalar bile, sahte bir SSL puanlamak için çok daha az seçeneğe sahip olacaklar /TLS belgesi.
CAA Nasıl Çalışır?
CAA DNS kullanıyor
The Alan Adı Sistemi (DNS), internet altyapısının önemli bir parçasıdır. Herhangi bir alanın sahibi DNS kayıtlarını tutar (sözde bölge dosyaları) alan adlarını, sitelerinin barındırıldığı IP adresine işaret eder ve yazmamıza izin verir google.com yerine bir tarayıcı penceresine 216.58.194.46.
DNS kayıtları genellikle "İnternet için telefon rehberi" olarak kullanılır, ancak DNS ayrıca bir alan adına diğer bilgileri atayabilen diğer özel kayıt türlerine de izin verir.
CAA Kayıtları
CAA, Sertifika Yetkilisi Yetkilendirme Kaynak Kaydı (CAA kaydı). Bunlar DNS kullanılarak yayınlanır ve alan adı sahibi, diğer DNS kayıtlarının yanına yalnızca CAA kayıtları ekler. Bir CAA kaydı aşağıdakileri içerir: etiket ve değerve etiket-değer çiftine özellik. Orada bir de bayrak bu mülkün ne kadar kritik olduğunu gösterir. Şöyle görünüyor:
example.com. CAA 0 sorunu "ssl.com"
Burada, example.com bu kaydın uygulandığı alan adıdır ve CAA bunun ne tür bir kayıt olduğunu bize bildirir. 0 bayraktır (sıfır varsayılandır - bunun hakkında aşağıda konuşacağız). Etiket konu ve değer (tırnak işaretleri içinde) ssl.com, birlikte mülkü oluştururlar.
Bayraklar
Bayrakların şu anda yalnızca iki kesin olarak tanımlanmış durumu vardır: 0 (kritik olmayan) ve 1 (Kritik). Kritik bir bayrak CA'ya şart Devam etmek için özellik etiketini tamamen anlayın. RFC 6844, kullanıcı tanımlı işaret kullanımı için diğer olasılıkları açık bırakır (aşağıda bunlardan da bahsedeceğiz).
Etiketler
RFC 6844, üç yaygın etiketin kullanımını tanımlar: konu, ihraç ve iyot. (Bayraklarda olduğu gibi, diğer potansiyel özelleştirilmiş etiket türlerine de izin verir.)
The konu etiket
The konu etiketi, hangi (varsa) CA'nın bu etki alanı için sertifika verme yetkisine sahip olduğunu belirtir. Örneğin, example.com etki alanının sahibi, aşağıdaki DNS bölge dosyasını kullanarak sertifika verilmesini bir CA (burada, SSL.com) ile kısıtlayabilir:
example.com. CAA 0 sorunu "ssl.com"
Alan adı sahibi, bir alan adı için birden fazla bölge dosyası ayarlamayı seçebilir:
example.com. CAA 0 sorunu "ssl.com" example.com. CAA 0 sorunu "comodoca.com"
Yukarıdaki kayıtlar SSL'yi /TLS için sertifika verilmesi example.com iki CA'ya (SSL.com ve Comodo.com).
The konu kayıt ayrıca, belirtilen CA'ya belirtilen etki alanının herhangi bir alt etki alanı için sertifika verme yetkisi verir. SSL.com'a izin veren bir kayıt böylelikle sertifikaların verilmesine izin verebilir example.com ve benzer alt alan adları www.example.com, posta.example.com ve hatta özel joker alt alan adı * .example.com.
Bir CAA kaydı aşağıdakileri yapmak için kullanılabilir: kısıtlamak sertifika verilmesi de - bu kayıt, CAA kullanan sertifika yetkililerine şunu söyler: yok hayır SSL /TLS için sertifikalar verilmelidir example.com ve alt alan adlarına göre herhangi AC:
ornek.com. CAA 0 sorunu ";"
(Bu örnekteki noktalı virgül "burada hiçbir şeye izin verme", Ancak daha sonra göstereceğimiz gibi, özel parametreleri tanımlamak için de kullanılır.)
Standart bir sorun etiketinin, CA'nın… tarafından değiştirilmedikçe bir joker karakter için sertifika vermesine izin verdiğini unutmayın.
The ihraç etiket
Bu etiket, bir CA'nın sahibinin etki alanı için joker sertifika verme yetkisine sahip olduğunu belirtir (ör. * .example.com).
Joker karakterler özel bir tümünü yakalama alt etki alanıdır ve joker karakter sertifikaları verilirken özel dikkat ve dikkat gösterilir. ihraç etiketi, alan sahibinin CA'ların ana alan adlarından veya diğer alt alan adlarından ayrı olarak joker karakterler için sertifika verebileceklerini tanımlamasını sağlar. ihraç etiketler herhangi bir önceliğe sahiptir konu etiketleri. İle aynı sözdizimini kullanırlar. konu etiket. Bazı örnekler:
example.com. CAA 0 sorunu "ssl.com" example.com. CAA 0 issuewild ";"
Yukarıdakiler, SSL.com'un example.com ve tüm alt alan adları dışında joker karakter için * .example.com. (Ne SSL.com ne de başka bir CA, için joker karakter sertifikası verme izni verilmez. example.com.)
example.com. CAA 0 sorunu ";" example.com. CAA 0 issuewild "ssl.com"
Bu örnek yasaklıyor herşey Sertifika düzenleyecek CA'lar example.com ve alt etki alanları, ancak SSL.com'un joker karakter sertifikaları vermesine izin vermek için bir istisna oluşturur (ve bir tek joker sertifikalar) example.com.
The iyot etiket
Üçüncü tanımlanan etiket: iyot. Bu etiket, alan adı sahibine geçersiz sertifika isteklerini bildirmek için kullanılabilir ve şöyle görünür:
ornek.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Üstteki kayıt, adrese bir e-posta bildirimi göndermek için gereken CA bilgilerini verir sertifikalar@example.com. İkincisi, CA'yı bir web hizmetine (alan adı sahibi tarafından bu amaç için ayarlanmış) bir olay mesajı yayınlamaya yönlendirir. sertifikalar.example.com. (CA ve etki alanı sahibinin işlemlerini nasıl ayarladığına bağlı olarak bu yöntemlerden biri veya her ikisi de kullanılabilir.)
iyot posta iletileri, Olay Nesnesi Açıklama Değişim Biçimi veya IODEF - dolayısıyla adı. (IODEF, RFC 6546.)
CA tanımlı bayraklar ve etiketler
RFC 6844'te açıklandığı gibi CAA yalnızca iki bayrak durumunu (0 ve 1) ve üç etiketi (konu, ihraç ve iyot). Ancak, tasarımı CA'ların sertifika verme işlemlerini tanımlamak için özel etiketler ve bayraklar oluşturup kullanmasına yetecek kadar açık bırakır. Örnekler şunlar olabilir:
example.com. CAA 0 sorunu "SSL.com; policy = ev"
Bu kayıt standart kullanıyor konu CA'ya bu etki alanı için sertifika verirken Genişletilmiş Doğrulama (EV) ilkesini kullanmasını bildiren fazladan bir parametreye sahip etiket.
ornek.com. CAA 128 pca "PCA = 12345"
Alan adı sahibi bu kaydı yeni, CA tanımlı bir şekilde kullanabilir pca etiketi, Tercih Edilen Müşteri Hesabına sahip olduklarını ve hesap numarasını parametre olarak ayarladıklarını gösterir. (Bayrak 255'e kadar özel bir değer olabilir.) CA'nın hesabı nasıl ayarladığına bağlı olarak bu, belirli faturalandırma yöntemleri, ek hesap tanımlı doğrulama veya diğer özel işlemlere izin verebilir.
Artıları ve eksileri
Artılar…
CAA'yı kullanmak için birkaç mükemmel neden vardır. Ana ve en önemli avantajı, CAA'nın sertifikanın yanlış verilmesi riskini büyük ölçüde azaltma yeteneğidir. Bu, alanınızı, işletmenizi ve çevrimiçi kimliğinizi korumaya yardımcı olur. Belirli bir CA'nın yazılımında bir hata bulmuş olabilecek potansiyel saldırganlar, etki alanınız için SSL sertifikaları yayınlamak için ondan yararlanamaz. Ayrıca, iyodef etiketini kullanmak, bir istismara teşebbüs edildiğinde bir rapor almanızı sağlar.
CAA'nın tasarımı güvenliği artırır, ancak aynı zamanda kaynakların daha ayrıntılı tahsisine de izin verebilir - örneğin, bir şirket, satış ve pazarlama departmanının belirli bir kaynaktan sales.example.com için SSL sertifikaları satın almasına izin vermek (veya sınırlamak) için kayıtlar oluşturabilir.
Buna ek olarak, CAA büyük esneklik sunar. Bir etki alanı sahibi için, kendi denetimi altında olan ve gerektiğinde değiştirilebilen DNS kaynak kayıtlarını kullanır, bu nedenle belirli bir CA'ya bağlı değildirler (ve belirli bir etki alanı adı için sorun kayıtlarıyla birden fazla CA'ya sahip olabilirler) . CA'lar için, özelleştirilmiş kullanımlar dışında bile, CA / B Forum tarafından yeni kabul edilen kurallar (CA ve tarayıcı güvenliği konularında standartları belirleyen grup), CAA kayıtlarının doğrulama amacıyla kullanılmasına izin vererek bunları kullanmak için başka bir iyi neden sağlar.
… Ve eksiler
CAA ile ilgili en büyük sorun, tüm CA'lar tarafından benimsenmemiş olmasıdır. CA / B Forumunun Temel Gereksinimleri (tüm güvenilir CA'ların yerine getirdiği), bir CA'ya çevrimiçi belgelerinde CAA'yı destekleme derecesini belirtmesi talimatını verir. Ancak bu yazı itibariyle, CAA kullanımı yalnızca Tavsiye edilen, gerekli değil. CAA ile uyumlu olmayan sertifika yetkilileri hala hedeflenebilmektedir ve CAA daha geniş bir kullanım alanına gelene kadar bir korsan, sahte bir sertifika vermek isteyen uyumlu olmayan bir CA bulabilir.
İlgili bir dezavantaj, CAA kayıtları yerleştirilse bile, bir kullanıcının uygulamak bir sertifika yetkilisi tarafından kullanılması. Bu kayıtlara göre işlem yapılabilmesi için bir CA'nın RFC 6844 ile uyumlu olması gerekir ve uyumlu olmayan bir CA, CAA kayıtlarında açıklanan etki alanı sahibinin açık isteklerini basitçe göz ardı edebilir.
CAA ayrıca hem etki alanı sahibi hem de CA tarafından doğru şekilde yapılandırılmalıdır. Let's Encrypt (CAA'yı destekliyor) son zamanlarda kod tabanlarıyla ilgili küçük bir sorun bildirdiler Bu da ne yazık ki CAA kurallarının göz ardı edilmesine ve altı sertifikanın yanlış verilmesine yol açtı. Bunların hiçbiri kötü niyetli istisnalar değildi (ve sorunu keşfedildikten sonra saatler içinde çözmesi ve bildirmesi için Let's Encrypt ekibine tebrikler). Ancak bu, uyumlu bir sertifika yetkilisinin şart CAA uygulamak kusursuzca.
Bir başka olası sorun da CAA'nın DNS'ye güvenmesidir. Bir etki alanı sahibi kendi ad hizmetlerini güvence altına almadığı sürece, bu saldırı için bir vektör olabilir. RFC 6844, uygulamayı önerir Etki Alanı Adı Sistemi Güvenlik Uzantıları (DNSSEC)verilerin kimlik doğrulaması ve DNS sahteciliği tehdidiyle mücadele için dijital olarak imzalanmış DNS kayıtlarını kullanır.
Son olarak, CAA yerinde ve doğru bir şekilde uygulanmış olsa bile, bir CAA kaydı kendi başına sahte sertifikaların verilmesini tamamen engelleyemez. CAA, bir saldırganın seçeneklerini sınırlamak için yararlı ve önemli bir araç olsa da, yeterli erişime sahip bir korsan, (örneğin, DNS'yi kontrol ederek veya sosyal mühendislik yoluyla) etrafından dolaşabilir.
Sonuç
Sertifika Yetkilisi Yetkilendirmesi, daha geniş bir güvenlik ekosisteminin parçası olarak müthiş bir potansiyele sahiptir ve CAA'nın yaygın bir şekilde benimsenmesi ve uygulanması, sertifikaların yanlış verilmesine karşı koruma sağlayacaktır. Tüm sertifika yetkililerinin şu anda CAA'yı desteklememesi talihsiz bir durum olsa da, bunun tüm CA'lar için daha güçlü bir şekilde önerilmesi veya zorunlu hale getirilmesi konusunda tartışmalar vardır. CAA tek başına her sertifikanın yanlış verilmesini durdurmayacak olsa da, doğru yönde atılmış iyi bir adımdır ve SSL.com, CAA kayıtlarını kendiniz kullanmayı düşünmenizi tavsiye eder.
Referanslar
- RFC6844: DNS Sertifika Yetkilisi Yetkilendirme (CAA) Kaynak Kaydı
- RFC5070: Olay Nesnesi Açıklama Değişim Biçimi
- RFC6546: Gerçek Zamanlı Ağlar Arası Savunma (RID) İletilerinin HTTP /TLS
- RFC4033: DNS Güvenliği Giriş ve Gereksinimleri
- CA / B Forum Oylama 125 - CAA Kayıtları
- DNS Sertifika Yetkilisi Yetkilendirmesi hakkında Wikipedia girişi
