System.Net.WebRequest hangi SSL / TLS sürümlerini destekliyor?


81

Artık SSL 3'ün POODLE saldırısına karşı savunmasız olduğu bulundu :

System.Net.WebRequest herhangi bir https Uri'ye bağlanırken hangi SSL / TLS sürümlerini kullanıyor?

Birkaç 3. parti API'ye bağlanmak için WebRequest kullanıyorum. Bunlardan biri şimdi SSL 3 kullanan herhangi bir isteği engelleyeceğini söyledi. Ancak WebRequest .Net çekirdek çerçevesinin bir parçasıdır (4.5 kullanan), bu nedenle hangi sürümü kullandığı açık değildir.


Sunucu (veya ortadaki adam) isterse WebRequest SSL 3'e geri dönecek mi?
Philip Pittle

Yanılmıyorsam, WebRequest'in açmaya çalıştığınız sunucudaki güvenlik sertifikasına baktığını ve web sunucusundaki şifreleme şemasını kullandığını düşünüyorum. Müşteri tarafında hiçbir şeyi değiştirmen gerektiğini sanmıyorum.
Icemanind

1
Umarım az önce SSL3'ü desteklemeyeceklerini söyleyen API sahipleri, sunucularının istemcinin SSL3 kullanmasını istemediğinden emin olmayı düşünmüşlerdir :)
JK.

@iceman bir sertifikadan SSL3'ü destekleyip desteklemediğini anlamanın bir yolu var mı? Sürümlerle ilgili herhangi bir özellik görmüyorum.
JK.

@JK. - Diğer tarayıcılardan emin değilim, ancak Chrome kullanıyorum. Chrome'da, bir HTTPS web sitesine (örneğin Wellsfargo.com) giderseniz, URL'nin yanında yeşil bir kilit göreceksiniz. Bu kilide tıklayın, ardından bağlantı sekmesine tıklayın, size gösterecektir. Wellsfargo.com söz konusu olduğunda, Chrome "Bağlantı TLS 1.0 kullanıyor" der. IE ve diğer tarayıcılar aynı benzer şeyi göstermelidir.
Icemanind

Yanıtlar:


51

System.Net.WebRequest'i kullanırken, uygulamanız, hem uygulamanızın hem de sunucunun desteklediği en yüksek TLS sürümünü belirlemek için sunucuyla görüşecek ve bunu kullanacaktır. Bunun nasıl çalıştığına dair daha fazla ayrıntıyı burada görebilirsiniz:

http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

Sunucu TLS'yi desteklemiyorsa, SSL'ye geri dönecektir, bu nedenle potansiyel olarak SSL3'e geri dönebilir. .NET 4.5'in desteklediği tüm sürümleri burada görebilirsiniz:

http://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.110).aspx

Uygulamanızın POODLE'a karşı savunmasız kalmasını önlemek için, bu açıklamayı izleyerek uygulamanızın çalıştığı makinede SSL3'ü devre dışı bırakabilirsiniz:

/server/637207/on-iis-how-do-i-patch-the-ssl-3-0-poodle-vulnerability-cve-2014-3566


20
WebRequest ve HttpWebRequest gibi giden istekleri güvenli hale getirmek için, stackoverflow.com/questions/26389899/… adresindeki sorumda ayrıntılı olarak açıklanan SSL geri dönüşünü devre dışı bırakma adımlarını izlemenizi öneririm . Temel olarak önce bu kod satırını çalıştırırsınız: System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; Anladığım kadarıyla, bu yanıtta ayrıntılı olarak açıklanan kayıt defteri düzeltmesi yalnızca gelen bağlantılar için geçerlidir.
Ürdün Rieger

1
SecurityProtocolType.Tls.Net çerçevesi 3.5 veya altında yalnızca seçeneğiniz (ve dolayısıyla TLS 1.0) olduğunu unutmayın
James Westgate

System.Net.WebRequest'i kaldırıp RestSharp gibi başka bir kitaplık kullanarak daha yüksek TLS desteği alabilir miyim yoksa yükseltilmesi gereken gerçek .net çerçevesi mi?
Kek Adam

Bunun yükseltilmesi gereken gerçek .net çerçevesi olduğuna inanıyorum. www.passionatecoder.ca
Ehsan

1
@JamesWestgate TLSAslında OS / makine düzeyinde uygulanacak bir şey olduğu izlenimine kapıldım ? Gerçek HTTP trafiğinin gerçekleştiği yer burası değil mi? Bu nedenle, kodunuza gerçekten işletim sistemi tarafından belirlenen belirli bir TLS'yi kullanmasını söylemenin mantıklı olduğunu düşünmüyorum.
Don Cheadle

52

Bu önemli bir soru. SSL 3 protokolü (1996), 2014 yılında yayınlanan Kaniş saldırısı tarafından onarılamayacak şekilde bozulmuştur. IETF, "SSLv3 KULLANILMAMALIDIR" yayınlamıştır . Web tarayıcıları bundan kurtuluyor. Mozilla Firefox ve Google Chrome bunu zaten yaptı.

Tarayıcılarda protokol desteğini kontrol etmek için iki mükemmel araç, SSL Lab'ın istemci testi ve https://www.howsmyssl.com/'dir . İkincisi Javascript gerektirmez, bu yüzden .NET'in HttpClient'ından deneyebilirsiniz :

// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");

File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);

// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");

Sonuç kahredici:

Müşteriniz çok eski olan, muhtemelen BEAST saldırısına duyarlı olan ve üzerinde mevcut en iyi şifre paketlerine sahip olmayan TLS 1.0 kullanıyor. MD5-SHA-1'in yerini alacak AES-GCM ve SHA256 gibi eklemeler, bir TLS 1.0 istemcisinin yanı sıra daha birçok modern şifre paketi için kullanılamaz.

Bu ilgili. 2006'nın Internet Explorer 7'si ile karşılaştırılabilir.

Bir HTTP istemcisinin tam olarak hangi protokolleri desteklediğini listelemek için, aşağıdaki sürüme özgü test sunucularını deneyebilirsiniz:

var test_servers = new Dictionary<string, string>();
test_servers["SSL 2"] = "https://www.ssllabs.com:10200";
test_servers["SSL 3"] = "https://www.ssllabs.com:10300";
test_servers["TLS 1.0"] = "https://www.ssllabs.com:10301";
test_servers["TLS 1.1"] = "https://www.ssllabs.com:10302";
test_servers["TLS 1.2"] = "https://www.ssllabs.com:10303";

var supported = new Func<string, bool>(url =>
{
    try { return new HttpClient().GetAsync(url).Result.IsSuccessStatusCode; }
    catch { return false; }
});

var supported_protocols = test_servers.Where(server => supported(server.Value));
Console.WriteLine(string.Join(", ", supported_protocols.Select(x => x.Key)));

.NET Framework 4.6.2 kullanıyorum. HttpClient'in yalnızca SSL 3 ve TLS 1.0'ı desteklediğini öğrendim. Bu ilgili. Bu, 2006'nın Internet Explorer 7'si ile karşılaştırılabilir.


Güncelleme: HttpClient'in TLS 1.1 ve 1.2'yi desteklemesini sağlar, ancak bunları adresinden manuel olarak açmanız gerekir System.Net.ServicePointManager.SecurityProtocol. Bkz. Https://stackoverflow.com/a/26392698/284795

Kutudan çıkar çıkmaz kötü protokolleri neden kullandığını bilmiyorum. Bu, kötü bir kurulum seçeneği gibi görünüyor, büyük bir güvenlik hatasıyla eşdeğerdir (bahse girerim pek çok uygulama varsayılanı değiştirmez). Nasıl rapor edebiliriz?


Hangi protokolü kullanmalıyım ?
Kiquenet

8

Oraya da bir cevap verdim, ancak @Colonel Panic'in güncellemesi TLS 1.2'yi zorlamayı öneriyor. Gelecekte, TLS 1.2'nin güvenliği ihlal edildiğinde veya yeni geçtiğinde, kodunuzun TLS 1.2'ye yapıştırılması bir eksiklik olarak kabul edilecektir. TLS1.2 ile anlaşma, .Net 4.6'da varsayılan olarak etkindir. Kaynağınızı .Net 4.6'ya yükseltme seçeneğiniz varsa, TLS 1.2'yi zorlayarak değiştirmenizi şiddetle tavsiye ederim.

TLS 1.2'yi zorlarsanız, 4.6 veya daha yüksek bir çerçeveye yükseltme yaparsanız bu gücü ortadan kaldıracak bir tür içerik haritası bırakmayı kesinlikle düşünün.


2
"TLS1.2 için anlaşma varsayılan olarak .Net 4.6'da etkinleştirilmiştir" bunun için belgeleriniz var mı?
felickz

2
O zamanlar, bu özelliğe işaret eden kesin olmayan belgeler bulduk ( örneklerin hemen yukarısındaki msdn.microsoft.com/en-us/library/… bakın ). Ancak, bunu TLS 1.2'ye kilitlenmiş bir sunucuya sahip bir test programı oluşturarak ve bir sayfayı denemek ve indirmek için bir web isteği kullanarak doğruladık. Daha sonra programdaki çerçeve sürümlerini değiştirdik. Tüm alt düzey sürümler bağlanamadı, ancak .Net 4.6 sorunsuz bir şekilde bağlandı.
Prof Von Lemongargle 01

Ayrıntılar için teşekkürler,
4.5'in

Bu doğru ve gidilecek yol. Şu anda TLS'de ısrar eden web uç noktalarıyla konuşan birkaç eski sunucumuz var. Web servis referansları SSL / TLS hataları ile başarısız olmaya başladı. Kayıt defterini hackleyebilirsiniz, ancak sunucuyu en son .NET sürümüne yükseltmek daha kolay ve daha güvenlidir.
Neil Laslett
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.