禁用SSL后备，仅将TLS用于.NET中的出站连接？（缓解贵宾犬）

我正在尝试减轻我们对Poodle SSL 3.0 Fallback攻击的脆弱性。我们的管理员已经开始禁用TLS，而将TLS禁用为与服务器的入站连接。我们还建议我们的团队在其网络浏览器中禁用SSL。我现在正在看我们的.NET代码库，该代码库通过System.Net.HttpWebRequest启动与各种服务的HTTPS连接。我相信，如果这些连接允许从TLS退回到SSL，则可能会受到MITM攻击。到目前为止，这是我确定的。可以请某人仔细检查一下以确认我是对的吗？该漏洞是全新的，因此我尚未看到Microsoft提供的有关如何在.NET中缓解该漏洞的任何指导：

1. System.Net.Security.SslStream类的允许协议（支持.NET中的安全通信）是通过System.Net.ServicePointManager.SecurityProtocol属性为每个AppDomain全局设置的。

2. .NET 4.5中此属性的默认值为Ssl3 | Tls（尽管我找不到支持该文档的文档。）SecurityProtocolType是具有Flags属性的枚举，因此它是这两个值的按位或。您可以使用以下代码行在您的环境中进行检查：

   Console.WriteLine（System.Net.ServicePointManager.SecurityProtocol.ToString（））;

3. 在您启动应用程序中的任何连接之前Tls，应将其更改为just ，或者也许是Tls12：

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

4. 重要说明：由于该属性支持多个按位标志，因此我假设SslStream 在握手期间不会自动回退到其他未指定的协议。否则，支持多个标志的意义何在？

TLS 1.0和1.1 / 1.2的更新：

根据Google安全专家Adam Langley的说法，如果未正确实施TLS 1.0，则以后很容易受到POODLE的攻击，因此您应该考虑专门迁移到TLS 1.2。

.NET Framework 4.7及更高版本的更新：

正如以下Von Lemongargle教授所暗示的那样，从.NET Framework 4.7版开始，无需使用此技巧，因为默认设置将允许操作系统选择最安全的TLS协议版本。有关更多信息，请参见.NET Framework的传输层安全性（TLS）最佳做法。

我们正在做同样的事情。要仅支持TLS 1.2而不支持SSL协议，可以执行以下操作：

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

SecurityProtocolType.Tls仅是TLS 1.0，不是所有TLS版本。

附带说明：如果要检查您的站点是否不允许SSL连接，可以在此处进行（我认为这不受上述设置的影响，我们必须编辑注册表以强制IIS使用TLS用于传入连接）：https : //www.ssllabs.com/ssltest/index.html

要在IIS中禁用SSL 2.0和3.0，请参见以下页面：https : //www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

@Eddie Loeffen的答案似乎是该问题的最受欢迎的答案，但它会带来一些不良的长期影响。如果您在此处查看System.Net.ServicePointManager.SecurityProtocol的文档页面，则“备注”部分意味着协商阶段应仅解决此问题（并且强制协议是一种不好的做法，因为将来还会破坏TLS 1.2）。但是，如果确实如此，我们就不会在寻找答案。

研究表明，在协商阶段必须使用ALPN协商协议才能达到TLS1.2。我们以此为出发点，并尝试使用.Net框架的较新版本来查看支持的起点。我们发现.Net 4.5.2不支持与TLS 1.2的协商，但是.Net 4.6支持。

因此，即使强制使用TLS1.2现在就可以完成工作，但我还是建议您升级到.Net 4.6。由于这是2016年6月的PCI DSS问题，因此窗口很短，但是新框架是一个更好的答案。

更新：从评论工作，我建立了这个：

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;
        }
    }

为了验证该概念，我将SSL3和TLS1.2结合在一起并运行了针对仅支持TLS 1.0和TLS 1.2（禁用1.1）的服务器的代码。使用or'd协议，似乎连接良好。如果我更改为SSL3和TLS 1.1，则连接失败。我的验证使用System.Net的HttpWebRequest，仅调用GetResponse（）。例如，我尝试了此操作但失败了：

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

虽然这个工作：

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

与强制使用TLS 1.2相比，它具有一个优势，因为如果升级了.Net框架，使得Enum中有更多条目，则代码将按原样支持它们。与仅使用.Net 4.6相比，它有一个缺点，即4.6使用ALPN，并且如果未指定限制，则应支持新协议。

编辑4/29/2019-微软于去年10月发布了此文章。他们对如何在各种版本的.net框架中完成此操作提出了很好的建议。

@沃森

在Windows窗体上，该类位于顶部

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

因为Windows是单线程的，所以它所需要的就是它，如果它是一项服务，则需要将其放在该服务的调用上方（因为没有告诉您将使用哪个线程）。

using System.Security.Principal 

也需要。

如果您想知道.NET支持哪些协议，可以在https://www.howsmyssl.com/上尝试HttpClient。

// 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");

结果是该死的：

您的客户端使用的TLS 1.0很旧，可能容易受到BEAST攻击，并且没有可用的最佳密码套件。TLS 1.0客户端以及许多更现代的密码套件均无法使用诸如AES-GCM和SHA256之类的替代品来替代MD5-SHA-1。

如Eddie上面所述，您可以手动启用更好的协议：

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

我不知道为什么它会立即使用错误的协议。这似乎是一个糟糕的设置选择，相当于一个重大的安全漏洞（我敢打赌，许多应用程序都不会更改默认设置）。我们如何举报？

我必须转换等效的整数，以避开我仍在使用.NET 4.0的事实

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

我发现最简单的解决方案是添加两个注册表项，如下所示（在具有管理员权限的命令提示符下运行此注册表项）：

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

这些条目似乎影响.NET CLR作为客户端建立安全连接时如何选择协议。

这里有有关此注册表项的更多信息：

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

这不仅更简单，而且假设它适合您的情况，比基于代码的解决方案要健壮得多，后者需要开发人员跟踪协议和开发并更新所有相关代码。希望可以对TLS 1.3及更高版本进行类似的环境更改，只要.NET保持足够的哑度而不会自动选择最高的可用协议即可。

注意：即使，根据以上文章，这仅应禁用RC4，并且不会认为这会更改.NET客户端是否允许使用TLS1.2 +，因为某些原因，它确实具有此功能影响。

注意：正如@Jordan Rieger在评论中指出的那样，这不是POODLE的解决方案，因为它不会禁用较旧的协议a －它仅允许客户端使用较新的协议，例如，当修补的服务器已禁用较旧的协议时协议。但是，在发生MITM攻击时，显然，受感染的服务器将为客户端提供较旧的协议，然后客户端会很高兴地使用该协议。

TODO：尝试通过这些注册表项禁用客户端对TLS1.0和TLS1.1的使用，但是我不知道.NET http客户端库是否遵守以下设置：

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

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