SSL ve ortadaki adam yanlış anlama

Bu sorunla ilgili tonlarca belge okudum ancak yine de tüm parçaları bir araya getiremiyorum, bu yüzden birkaç soru sormak istiyorum.

1. Her şeyden önce, anladığım şekliyle kimlik doğrulama prosedürünü kısaca açıklayacağım, çünkü bu konuda yanılıyor olabilirim: Bir istemci, bir sunucunun genel anahtar, bazı meta veriler ve dijital imzanın bir kombinasyonuyla yanıt verdiği bir bağlantı başlatır. güvenilir otorite. Daha sonra istemci, sunucuya güvenip güvenmediğine karar verir, bazı rastgele oturum anahtarlarını açık anahtarla şifreler ve geri gönderir. Bu oturum anahtarının şifresi yalnızca sunucuda depolanan özel anahtarla çözülebilir. Sunucu bunu yapar ve ardından HTTPS oturumu başlar.

2. Öyleyse, yukarıda haklıysam, soru ortadaki adam saldırısının böyle bir senaryoda nasıl gerçekleşebileceğidir? Demek istediğim, birisi sunucuya (ör. Www.server.com) yanıtını açık anahtarla durdursa ve bana www.server.com olduğunu düşündüren bazı yollara sahip olsa bile, yine de oturum anahtarımın şifresini çözemezdi özel anahtar olmadan.

3. Karşılıklı kimlik doğrulama hakkında konuşursak, her şey istemci kimliği konusunda sunucu güveniyle mi ilgili? Demek istediğim, müşteri zaten doğru sunucuyla iletişim kurduğundan emin olabilir, ancak şimdi sunucu istemcinin kim olduğunu öğrenmek istiyor, değil mi?

4. Ve son soru, karşılıklı kimlik doğrulamanın alternatifi ile ilgili. Açıklanan durumda bir istemci olarak hareket edersem, SSL oturumu kurulduktan sonra HTTP başlığında bir oturum açma / şifre gönderirsem ne olur? Gördüğüm kadarıyla, bu bilgiler ele geçirilemez çünkü bağlantı zaten güvenli ve sunucu kimliğim için ona güvenebilir. Yanlış mıyım? Karşılıklı kimlik doğrulama ile karşılaştırıldığında böyle bir yaklaşımın dezavantajları nelerdir (uygulama karmaşıklığı değil, yalnızca güvenlik sorunları önemlidir)?

SSL'ye yönelik ortadaki adam saldırıları gerçekten ancak SSL'nin ön koşullarından birinin ihlal edilmesi durumunda mümkündür, işte bazı örnekler;

• Sunucu anahtarı çalındı ​​- saldırganın sunucu gibi görünebileceği ve istemcinin bilmesinin bir yolu olmadığı anlamına gelir .

• İstemci, güvenilmez bir CA'ya (veya kök anahtarı çalınan birine) güvenir - güvenilir bir CA anahtarına sahip olan kişi, sunucu gibi davranan bir sertifika oluşturabilir ve istemci ona güvenir. Bugün tarayıcılarda önceden var olan CA sayısıyla, bu gerçek bir sorun olabilir. Bu, sunucu sertifikasının başka bir geçerli sertifika ile değişmiş gibi görüneceği anlamına gelir; bu, çoğu istemcinin sizden gizleyeceği bir şeydir.

• İstemci, sertifikayı güvenilir CA'lar listesine göre doğru bir şekilde doğrulamakla uğraşmaz - herkes bir CA oluşturabilir. Doğrulama olmaksızın, "Ben'in Arabaları ve Sertifikaları", Verisign kadar geçerli görünecektir.

• İstemci saldırıya uğradı ve güvendiği kök yetkililere sahte bir CA enjekte edildi - saldırganın istediği herhangi bir sertifikayı oluşturmasına izin veriyor ve müşteri ona güveniyor. Kötü amaçlı yazılım, örneğin sizi sahte bankacılık sitelerine yönlendirmek için bunu yapma eğilimindedir.

Özellikle # 2 oldukça kötüdür, son derece güvenilir bir sertifika için ödeme yapsanız bile, siteniz hiçbir şekilde bu sertifikaya kilitlenmez, herhangi biri için sahte sertifika oluşturabileceğinden, istemcinin tarayıcısındaki tüm CA'lara güvenmeniz gerekir. aynı geçerli olan siteniz. Ayrıca sunucuya veya istemciye erişim gerektirmez.

Öncelikle kimlik doğrulama prosedürünü anladığım kadarıyla kısaca anlatacağım, belki o adımda yanılıyorum. Böylece, bir istemci bir bağlantı başlatır ve bir sunucu buna ortak anahtar, bazı meta veriler ve güvenilen bir otoritenin dijital imzası kombinasyonu ile yanıt verir.

Sunucu, bir X.509 sertifika zinciri ve kendi özel anahtarıyla imzalanmış bir dijital imza ile yanıt verir.

Ardından müşteri, sunucuya güvenip güvenmediğine karar verir.

Doğru.

bazı rastgele oturum anahtarlarını genel anahtarla şifreler ve geri gönderir.

Hayır. İstemci ve sunucu, oturum anahtarının kendisinin hiçbir zaman iletilmediği karşılıklı bir oturum anahtarı oluşturma sürecine girer.

Bu oturum anahtarının şifresi yalnızca sunucuda depolanan özel anahtarla çözülebilir.

Hayır.

Sunucu bunu yapar

Hayır.

ve ardından HTTPS oturumu başlar.

TLS / SSL oturumu başlar, ancak daha fazla adım ilk bulunmaktadır.

Öyleyse, yukarıda haklıysam, soru ortadaki adam saldırısının böyle bir senaryoda nasıl gerçekleşebileceğidir?

Sunucu kılığına girerek ve SSL uç noktası gibi davranarak. Müşteri herhangi bir yetkilendirme adımını atlamak zorunda kalacaktır. Ne yazık ki çoğu HTTPS oturumundaki tek yetkilendirme adımı bir ana bilgisayar adı kontrolüdür.

Demek istediğim, birisi sunucuya (ör. Www.server.com) yanıtını açık anahtarla durdursa ve sonra bazı yollarla www.server.com olduğunu düşünmeme izin verse bile, yine de oturum anahtarımın şifresini çözemezdi. özel anahtar olmadan.

Yukarıyı görmek. Şifresini çözülecek oturum anahtarı yok. SSL bağlantısının kendisi güvenlidir, konuştuğunuz kişi güvenli olmayabilir.

Karşılıklı kimlik doğrulama hakkında konuşursak, her şey istemci kimliği konusunda sunucu güveniyle mi ilgili? Demek istediğim, müşteri zaten doğru sunucuyla iletişim kurduğundan emin olabilir, ancak şimdi sunucu istemcinin kim olduğunu bulmak istiyor, değil mi?

Doğru.

Ve son soru, karşılıklı kimlik doğrulamanın alternatifi ile ilgili. Açıklanan durumda bir istemci olarak hareket edersem, SSL oturumu kurulduktan sonra HTTP başlığında bir oturum açma / şifre gönderirsem ne olur? Gördüğüm gibi, bu bilgiler ele geçirilemez çünkü bağlantı zaten güvenli ve sunucu kimliğim için ona güvenebilir. Yanlış mıyım?

Hayır.

Karşılıklı kimlik doğrulama ile karşılaştırıldığında bu tür bir yaklaşımın olumsuz yönleri nelerdir (uygulama karmaşıklığı değil, yalnızca güvenlik sorunları önemlidir)?

Yalnızca kullanıcı adı / parola kadar güvenlidir ve gizli bir anahtara göre sızdırılması çok daha kolaydır.

İstemci ve sunucu arasındaki yolda olan herkes ortadaki bir adamı https'ye saldırabilir. Bunun olası olmadığını veya nadir olduğunu düşünüyorsanız, bir internet ağ geçidindeki tüm SSL trafiğinin şifresini sistematik olarak çözen, tarayan ve yeniden şifreleyen ticari ürünler olduğunu düşünün.. Müşteriye, "gerçek" SSL sertifikasından kopyalanan ancak farklı bir sertifika zinciriyle imzalanmış ayrıntılarla anında oluşturulmuş bir SSL sertifikası göndererek çalışırlar. Bu zincir, tarayıcının güvenilir CA'larından herhangi biriyle sona ererse, bu MITM, kullanıcı için görünmez olacaktır. Bu ürünler öncelikle şirketlere "güvenli" (polis) kurumsal ağlar için satılır ve kullanıcıların bilgisi ve onayı ile kullanılmalıdır. Teknik olarak yine de, ISS'ler veya başka bir ağ taşıyıcısı tarafından kullanımlarını durduran hiçbir şey yoktur. (NSA'nın en az bir güvenilen kök CA imzalama anahtarına sahip olduğunu varsaymak güvenli olacaktır ).

Bir sayfayı sunuyorsanız , sayfanın hangi ortak anahtarla imzalanması gerektiğini belirten bir HTTP üstbilgisi ekleyebilirsiniz . Bu, kullanıcıları "güvenli" bağlantılarının MITM'sine karşı uyarmaya yardımcı olabilir, ancak bu ilk kullanımda güven tekniğidir. Bob "gerçek" genel anahtar pininin bir kaydına sahip değilse, Mallory belgedeki pkp başlığını yeniden yazar. Bu teknolojiyi (HPKP) kullanan web sitelerinin listesi iç karartıcı derecede kısadır. Kredilerine google ve dropbox dahildir. Genellikle, bir https-yakalama ağ geçidi, HPKP kullanan birkaç büyük güvenilir siteden gelen sayfalarda dalgalanır. Beklemediğiniz halde bir HPKP hatası görürseniz, dikkatli olun.

Şifrelerle ilgili olarak, bir https bağlantısındaki her şey, isteğin yönlendirilebilmesi için açık olması gereken alan adı dışında https ile güvence altına alınır. Genel olarak, şifreleri günlüklerde, yer imlerinde vb. Takılabilecekleri sorgu dizesine koymamanız önerilir. Ancak, https güvenliği ihlal edilmedikçe sorgu dizesi görünmez.

1. Doğru
2. O kadar doğru değil. Bu tür bir saldırıda, yineleme sunucusu isteğinizi alır ve sizin adınıza hedefe gönderir. ve sonra size sonuçla cevap verin. Aslında, sizinle iletişim kurmayı amaçladığınız gerçek sunucu değil, sizinle güvenli bağlantı kuran ortadaki adam sunucusudur. bu nedenle, sertifikanın geçerli ve güvenilir olduğunu her zaman kontrol etmelisiniz.
3. doğru olabilir
4. Güvenli bağlantının güvenilir olduğundan eminseniz, kullanıcı adı / şifre göndermek güvenlidir.

Oturum anahtarı ile ilgili kısım dışında söylediğiniz her şey doğrudur. CA'ların amacı ortadaki adam saldırısını yenmektir - diğer her şey SSL tarafından yapılır. İstemci kimlik doğrulaması, bir kullanıcı adı ve şifre şemasına bir alternatiftir.