SSL geri dönüşü devre dışı bırakılsın ve .NET'te giden bağlantılar için yalnızca TLS kullanılsın mı? (Kaniş azaltma)

Poodle SSL 3.0 Fallback saldırısına karşı güvenlik açığımızı azaltmaya çalışıyorum . Yöneticilerimiz zaten sunucularımıza gelen bağlantılar için TLS lehine SSL'yi devre dışı bırakmaya başladı. Ayrıca ekibimize web tarayıcılarında SSL'yi devre dışı bırakmalarını tavsiye ettik. Şimdi System.Net.HttpWebRequest aracılığıyla çeşitli hizmetlerle HTTPS bağlantılarını başlatan .NET kod tabanımıza bakıyorum . TLS'den SSL'ye geri dönüşe izin verirlerse bu bağlantıların bir MITM saldırısına açık olabileceğine inanıyorum. İşte şimdiye kadar belirlediklerim. Birisi haklı olduğumu doğrulamak için lütfen bunu iki kez kontrol edebilir mi? Bu güvenlik açığı tamamen yenidir, bu nedenle .NET'te bu güvenlik açığının nasıl azaltılacağına dair Microsoft'tan henüz herhangi bir rehber görmedim:

1. NET'te güvenli iletişimi destekleyen System.Net.Security.SslStream sınıfı için izin verilen protokoller, System.Net.ServicePointManager.SecurityProtocol özelliği aracılığıyla her AppDomain için global olarak ayarlanır .

2. .NET 4.5 Bu özelliğin varsayılan değeridir Ssl3 | Tls(O kadar geri belgelerine bulamıyorum rağmen.) O bit tabanlı yüzden SecurityProtocolType, Bayraklar özelliği olan bir enum olan YA bu iki değerden. Bu kod satırıyla ortamınızda bunu kontrol edebilirsiniz:

   Console.WriteLine (System.Net.ServicePointManager.SecurityProtocol.ToString ());

3. Bu , uygulamanızda herhangi bir bağlantı başlatmadan önce Tlsveya belki de olarak değiştirilmelidir Tls12:

   System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;

4. Önemli: özellik birden bitsel bayrakları desteklediği için, öyle sanıyorum ki SslStream olacak değil otomatik geri dönüş diğer belirtilmemiş protokollere el sıkışma sırasında. Aksi takdirde, birden çok bayrağı desteklemenin anlamı ne olur?

TLS 1.0 ve 1.1 / 1.2 ile ilgili güncelleme:

Google güvenlik uzmanı Adam Langley'e göre, TLS 1.0'ın daha sonra doğru şekilde uygulanmazsa POODLE'a karşı savunmasız olduğu tespit edildi , bu nedenle yalnızca TLS 1.2'ye geçmeyi düşünmelisiniz.

.NET Framework 4.7 ve üzeri için güncelleme:

Aşağıda Prof Von Lemongargle tarafından belirtildiği gibi, .NET Framework'ün 4.7 sürümünden başlayarak, varsayılan ayar işletim sisteminin en güvenli TLS protokol sürümünü seçmesine izin vereceği için bu hack'i kullanmaya gerek yoktur. Daha fazla bilgi için .NET Framework ile Taşıma Katmanı Güvenliği (TLS) en iyi uygulamalarına bakın .

Biz de aynı şeyi yapıyoruz. Yalnızca TLS 1.2'yi desteklemek ve hiçbir SSL protokolünü desteklemek için, bunu yapabilirsiniz:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

SecurityProtocolType.Tls yalnızca TLS 1.0'dır, tüm TLS sürümleri değildir.

Taraf olarak: Sitenizin SSL bağlantılarına izin vermediğini kontrol etmek istiyorsanız, buradan yapabilirsiniz (Bunun yukarıdaki ayardan etkileneceğini sanmıyorum, IIS'yi TLS kullanmaya zorlamak için kayıt defterini düzenlememiz gerekti. gelen bağlantılar için): https://www.ssllabs.com/ssltest/index.html

IIS'de SSL 2.0 ve 3.0'ı devre dışı bırakmak için şu sayfaya bakın: https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

@Eddie Loeffen'in cevabı bu sorunun en popüler cevabı gibi görünüyor, ancak bazı kötü uzun vadeli etkileri var. System.Net.ServicePointManager.SecurityProtocol için dokümantasyon sayfasını gözden geçirirseniz buradaki açıklamalar bölümü, müzakere aşamasının yalnızca bunu ele alması gerektiğini ima eder (ve protokolü zorlamak kötü bir uygulamadır çünkü gelecekte TLS 1.2 de tehlikeye atılacaktır). Ancak, olsaydı bu yanıtı aramazdık.

Araştırma, ALPN görüşme protokolünün müzakere aşamasında TLS1.2'ye ulaşmak için gerekli olduğu anlaşılıyor. Bunu başlangıç ​​noktamız olarak aldık ve desteğin nerede başladığını görmek için .Net çerçevesinin daha yeni sürümlerini denedik. .Net 4.5.2'nin TLS 1.2'ye pazarlığı desteklemediğini, ancak .Net 4.6'nın desteklediğini gördük.

Dolayısıyla, TLS1.2'yi zorlamak işi şimdi halledecek olsa da, bunun yerine .Net 4.6'ya yükseltmenizi tavsiye ederim. Bu, Haziran 2016 için bir PCI DSS sorunu olduğundan, zaman aralığı kısadır, ancak yeni çerçeve daha iyi bir yanıttır.

GÜNCELLEME: Yorumlardan çalışarak şunu oluşturdum:

ServicePointManager.SecurityProtocol = 0;    
foreach (SecurityProtocolType protocol in SecurityProtocolType.GetValues(typeof(SecurityProtocolType)))
    {
        switch (protocol)
        {
            case SecurityProtocolType.Ssl3:
            case SecurityProtocolType.Tls:
            case SecurityProtocolType.Tls11:
                break;
            default:
                ServicePointManager.SecurityProtocol |= protocol;
            break;
        }
    }

Kavramı doğrulamak için, SSL3 ve TLS1.2'yi birlikte kullandım veya kullandım ve kodu yalnızca TLS 1.0 ve TLS 1.2'yi destekleyen bir sunucuyu hedefleyen çalıştırdım (1.1 devre dışı bırakıldı). Or'd protokolleriyle, iyi bağlanıyor gibi görünüyor. SSL3 ve TLS 1.1'e geçersem, bu bağlantı başarısız oldu. Doğrulam, System.Net'ten HttpWebRequest'i kullanıyor ve sadece GetResponse () 'yi çağırıyor. Örneğin, bunu denedim ve başarısız oldum:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls11;
        request.GetResponse();

bu işe yararken:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
        request.GetResponse();

Bu, TLS 1.2'yi zorlamaktan daha avantajlıdır, çünkü .Net çerçevesi Enum'da daha fazla giriş olacak şekilde yükseltilirse, kod tarafından olduğu gibi desteklenecektir. Sadece .Net 4.6 kullanmaya göre bir dezavantajı vardır, 4.6 ALPN kullanır ve herhangi bir kısıtlama belirtilmemişse yeni protokolleri desteklemelidir.

Edit 4/29/2019 - Microsoft bu makaleyi geçen Ekim ayında yayınladı . .Net çerçevesinin çeşitli sürümlerinde bunun nasıl yapılması gerektiğine dair tavsiyelerinin oldukça iyi bir özeti var.

@yavbirah

Windows formlarında, sınıfın en üstünde bulunur

  static void Main(string[] args)
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
       //other stuff here
    }

pencereler tek iş parçacıklı olduğundan, ihtiyacınız olan tek şey, bir hizmet olması durumunda, onu hizmet çağrısının hemen üstüne koymanız gerekir (çünkü hangi iş parçacığını kullanacağınızı bilmiyorsunuz).

using System.Security.Principal 

ayrıca gereklidir.

NET'in hangi protokolleri desteklediğini merak ediyorsanız, HttpClient'i https://www.howsmyssl.com/ adresinde 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.

Eddie'nin yukarıda açıkladığı gibi, daha iyi protokolleri manuel olarak etkinleştirebilirsiniz:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11; 

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ğer (bahse girerim pek çok uygulama varsayılanı değiştirmez). Nasıl rapor edebiliriz?

Hala .NET 4.0 kullandığım gerçeğini aşmak için tamsayı eşdeğerini çevirmek zorunda kaldım

System.Net.ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
/* Note the property type  
   [System.Flags]
   public enum SecurityProtocolType
   {
     Ssl3 = 48,
     Tls = 192,
     Tls11 = 768,
     Tls12 = 3072,
   } 
*/

En basit çözümün aşağıdaki gibi iki kayıt defteri girişi eklemek olduğunu buldum (bunu yönetici ayrıcalıklarına sahip bir komut isteminde çalıştırın):

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:32

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64

Bu girdiler, istemci olarak güvenli bir bağlantı kurarken .NET CLR'nin bir protokolü nasıl seçtiğini etkiliyor gibi görünmektedir.

Bu kayıt defteri girdisi hakkında daha fazla bilgiyi burada bulabilirsiniz:

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358#suggested-actions

Bu sadece daha basit değil, aynı zamanda sizin durumunuz için çalıştığını varsayarsak, geliştiricilerin protokolü ve geliştirmeyi izlemesini ve ilgili tüm kodlarını güncellemesini gerektiren kod tabanlı bir çözümden çok daha sağlamdır. Umarım, .NET mevcut en yüksek protokolü otomatik olarak seçmeyecek kadar aptal kaldığı sürece TLS 1.3 ve sonrası için benzer ortam değişiklikleri yapılabilir.

NOT : Yukarıdaki makaleye göre, bunun yalnızca RC4'ü devre dışı bırakması gerekse de, .NET istemcisinin TLS1.2 + kullanmasına izin verilip verilmeyeceğinin değişeceğini düşünmemekle birlikte, bazı nedenlerden dolayı buna sahiptir. etki.

NOT : @ Jordan Rieger tarafından yorumlarda belirtildiği gibi, devre dışı bırakmadığı için bu POODLE için bir çözüm değildir. eski protokolleri a - yalnızca istemcinin daha yeni protokollerle çalışmasına izin verir, örneğin yamalı bir sunucu bıraktığında protokoller. Bununla birlikte, bir MITM saldırısıyla, açık bir şekilde, güvenliği ihlal edilmiş bir sunucu istemciye, istemcinin mutlu bir şekilde kullanacağı daha eski bir protokol sunacaktır.

TODO : Bu kayıt defteri girdileriyle TLS1.0 ve TLS1.1'in istemci tarafı kullanımını devre dışı bırakmayı deneyin, ancak .NET http istemci kitaplıklarının bu ayarlara uyup uymadığını bilmiyorum:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-10

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-11