Not: Orijinal cevabımı çok aceleyle yazdım, ancak o zamandan beri bu oldukça popüler bir soru / cevaba dönüştü, bu yüzden biraz genişlettim ve daha kesin hale getirdim.
TLS Kabiliyetleri
"SSL" bu protokole atıfta bulunmak için en sık kullanılan isimdir, ancak SSL özellikle Netscape tarafından 90'lı yılların ortalarında tasarlanan özel protokole atıfta bulunur. "TLS" SSL tabanlı bir IETF standardıdır, bu yüzden cevabımda TLS kullanacağım. Bugünlerde, web'deki güvenli bağlantılarınızın neredeyse tamamı SSL değil TLS kullanıyor olabilir.
TLS'nin çeşitli yetenekleri vardır:
- Uygulama katmanı verilerinizi şifreleyin. (Sizin durumunuzda, uygulama katmanı protokolü HTTP'dir.)
- Sunucunun istemcisinin kimliğini doğrulayın.
- İstemcinin sunucunun kimliğini doğrulayın.
# 1 ve # 2 çok yaygındır. # 3 daha az yaygındır. # 2 üzerinde duruyorsun, o yüzden açıklayacağım.
Kimlik Doğrulama
Bir sunucu, bir sertifika kullanarak kendini istemciye doğrular. Sertifika, bir web sitesi hakkında bilgi içeren bir veri bloğudur [1]:
- Alan adı
- Genel anahtar
- Sahibi olan şirket
- Verildiği zaman
- Süresi dolduğunda
- Kim yayınladı
- Vb.
Yalnızca bu sunucuda güvenli bir şekilde saklanması gereken ilgili özel anahtarla şifresi çözülebilen iletileri şifrelemek için sertifikaya dahil edilen genel anahtarı kullanarak gizlilik elde edebilirsiniz (yukarıdaki # 1). [2] Bu anahtar çifti KP1 diyelim, böylece daha sonra kafamız karışmayacak. Ayrıca, sertifikadaki alan adının ziyaret ettiğiniz siteyle eşleştiğini de doğrulayabilirsiniz (yukarıdaki # 2).
Peki ya bir rakip sunucuya gönderilen ve sunucudan gönderilen paketleri değiştirebilirse ve bu rakip size sunulan sertifikayı değiştirip kendi genel anahtarlarını eklerse veya diğer önemli ayrıntıları değiştirirse ne olur? Eğer bu olursa, düşman güvenli bir şekilde şifrelenmiş olduğunu düşündüğünüz tüm mesajları arayabilir ve değiştirebilir.
Bu saldırıyı önlemek için, sertifika başkasının özel anahtarı tarafından imzaya karşılık gelen ortak anahtara sahip olan herkes tarafından doğrulanabilecek şekilde şifrelenerek imzalanır. Bunların sunucunun kullandığı anahtarlarla aynı olmadığını açıkça belirtmek için bu anahtar çiftine KP2 diyelim.
Sertifika Yetkilileri
Peki kim KP2'yi yarattı? Sertifikayı kim imzaladı?
Biraz basitleştiren bir sertifika yetkilisi KP2'yi oluşturur ve diğer kuruluşlar için sertifikaları imzalamak için özel anahtarlarını kullanma hizmetini satarlar. Örneğin, bir sertifika oluşturuyorum ve Verisign gibi bir şirkete özel anahtarlarıyla imzalaması için ödeme yapıyorum. [3] Verisign dışında hiç kimse bu özel anahtara erişemediğinden hiçbirimiz bu imzayı taklit edemeyiz.
Ve bu imzayı doğrulamak için kişisel olarak KP2'deki ortak anahtarı nasıl alabilirim?
Bir sertifikanın ortak bir anahtarı tutabildiğini gördük - ve bilgisayar bilimcileri özyinelemeyi seviyor - neden KP2 ortak anahtarını bir sertifikaya koyup bu şekilde dağıtmıyorsunuz? İlk başta biraz çılgınca geliyor, ama aslında tam da böyle çalışıyor. Verisign örneğiyle devam eden Verisign, kim oldukları, ne tür şeyleri imzalamalarına (diğer sertifikalar) ve genel anahtarlarına ilişkin bilgileri içeren bir sertifika üretir.
Şimdi bu Verisign sertifikasının bir kopyasına sahipsem, ziyaret etmek istediğim web sitesinin sunucu sertifikasındaki imzayı doğrulamak için bunu kullanabilirim. Kolay değil mi?!
Çok hızlı değil. Verisign sertifikasını bir yerden almak zorunda kaldım . Birisi Verisign sertifikasını taklit edip kendi ortak anahtarını oraya koyarsa ne olur? Sonra sunucunun sertifikasındaki imzayı taklit edebilirler ve başladığımız yere geri dönüyoruz: ortadaki adam saldırısı.
Sertifika Zincirleri
Yinelemeli düşünmeye devam ederek, elbette üçüncü bir sertifika ve üçüncü bir anahtar çifti (KP3) ekleyebilir ve bunu Verisign sertifikasını imzalamak için kullanabiliriz. Buna sertifika zinciri diyoruz: zincirdeki her sertifika bir sonraki sertifikayı doğrulamak için kullanılır. Umarım bu özyinelemeli yaklaşımın sadece kaplumbağalar / sertifikalar olduğunu görebilirsiniz. Nerede duruyor?
Sonsuz sayıda sertifika oluşturamadığımız için, sertifika zinciri açıkça bir yerde durmak zorundadır ve bu, zincire kendinden imzalı bir sertifika ekleyerek yapılır .
Beyninizin parçalarını kafanızdan alırken bir an dururum. Kendinden imzalı ?!
Evet, sertifika zincirinin sonunda (diğer adıyla "kök"), kendisini imzalamak için kendi anahtar çiftini kullanan bir sertifika olacaktır. Bu, sonsuz özyineleme sorununu ortadan kaldırır, ancak kimlik doğrulama sorununu çözmez. Herkes, tıpkı siyaset, teorik fizik ve popo tekmeleme uyguladığımı ve sonra kendi adımı imzaladığımı söyleyen sahte Princeton diploması oluşturabileceğim gibi, üzerinde bir şey söyleyen kendinden imzalı bir sertifika oluşturabilir.
Bu sorunun [biraz zorlayıcı] çözümü, sadece açıkça güvendiğiniz kendinden imzalı bazı sertifikaları seçmektir. Örneğin, " Bu Verisign kendinden imzalı sertifikaya güveniyorum " diyebilirim .
Bu açık güven ile artık tüm sertifika zincirini doğrulayabilirim. Zincirde kaç sertifika olursa olsun, her imzayı köküne kadar doğrulayabilirim. Köke geldiğimde, bu kök sertifikanın açıkça güvendiğim bir sertifika olup olmadığını kontrol edebilirim. Eğer öyleyse, tüm zincire güvenebilirim.
Verilen Güven
TLS'de kimlik doğrulaması, verilen güven sistemini kullanır . Eğer bir oto tamircisi kiralamak istersem, bulduğum herhangi bir rastgele tamirciye güvenmeyebilirim. Ama belki arkadaşım belirli bir tamirciye kefil olur. Arkadaşıma güvendiğim için, o tamirciye güvenebilirim.
Bir bilgisayar satın aldığınızda veya bir tarayıcı indirdiğinizde, açıkça güvendiği birkaç yüz kök sertifika ile birlikte gelir. [4] Bu sertifikalara sahip olan ve çalışan şirketler, sertifikalarını imzalayarak diğer kuruluşlara bu güveni sağlayabilirler.
Bu mükemmel bir sistem olmaktan çok uzak. Bazı durumlarda bir CA hatalı bir sertifika verebilir. Bu gibi durumlarda sertifikanın iptal edilmesi gerekebilir. Verilen sertifika her zaman kriptografik olarak doğru olacağından iptal işlemi zordur; önceden geçerli olan sertifikaların iptal edildiğini bulmak için bant dışı bir protokol gereklidir. Uygulamada, bu protokollerin bazıları çok güvenli değildir ve birçok tarayıcı zaten onları kontrol etmez.
Bazen CA'nın tamamı tehlikeye girer. Örneğin, Verisign'a girip kök imzalama anahtarını çalacak olsaydınız , dünyadaki herhangi bir sertifikayı taklit edebilirdiniz . Bunun sadece Verisign müşterilerini etkilemediğine dikkat edin: sertifikam Thawte (Verisign'ın rakibi) tarafından imzalanmış olsa bile önemli değil. Sertifikam Verisign'ın güvenliği ihlal edilmiş imzalama anahtarı kullanılarak yine de taklit edilebilir.
Bu sadece teorik değil. Vahşi doğada oldu. DigiNotar ünlü bir hacklendi ve daha sonra iflas etti. Comodo da hacklendi , ama açıklanamaz bir şekilde günümüze kadar işlerini sürdürüyorlar.
CA'lar doğrudan tehlikeye atılmasa bile bu sistemde başka tehditler de vardır. Örneğin, bir hükümet sahte bir sertifikayı imzalamak için bir CA'yı zorlamak için yasal zorlama kullanır. İşvereniniz, çalışan bilgisayarınıza kendi CA sertifikalarını yükleyebilir. Bu çeşitli durumlarda, "güvenli" olmasını beklediğiniz trafik, söz konusu sertifikayı kontrol eden kuruluş tarafından tamamen görünür / değiştirilebilir.
Yakınsama , TACK ve DANE gibi bazı değiştirmeler önerildi .
Son Notlar
[1] TLS sertifika verileri X.509 standardına göre biçimlendirilir . X.509, ASN.1'e ("Özet Sözdizimi Notasyonu # 1") dayanmaktadır ; bu, ikili veri biçimi olmadığı anlamına gelir . Bu nedenle, X.509 ikili biçime kodlanmalıdır . DER ve PEM bildiğim en yaygın iki kodlama.
[2] Pratikte, protokol aslında simetrik bir şifreye geçer, ancak bu sorunuzla ilgili olmayan bir ayrıntıdır.
[3] Tahmin edilebileceği gibi, CA aslında sertifikanızı imzalamadan önce kim olduğunuzu doğrular. Bunu yapmadılarsa, google.com için bir sertifika oluşturabilir ve bir CA'dan imzalamasını isteyebilirim. Bu sertifikayla, google.com'a herhangi bir "güvenli" bağlantıyı arayabilirim. Bu nedenle, doğrulama adımı bir CA'nın çalışmasında çok önemli bir faktördür. Ne yazık ki, bu doğrulama sürecinin dünyadaki yüzlerce CA'da ne kadar titiz olduğu açık değildir.
[4] Mozilla'nın güvenilir CA'lar listesine bakın .
