与支持TLS 1.2的服务器通信的默认安全协议是什么?.NET默认情况下会选择服务器端支持的最高安全协议吗?或者我必须显式地添加这行代码:
System.Net.ServicePointManager.SecurityProtocol =
SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
除了代码更改之外，是否有方法更改此默认值?
最后，.NET 4.0是否只支持TLS 1.0?例如，我必须将客户端项目升级到4.5以支持TLS 1.2。
我的动机是在客户端删除对SSLv3的支持，即使服务器支持它(我已经有一个powershell脚本在机器注册表中禁用它)，并支持服务器支持的最高TLS协议。
更新:
查看。net 4.0中的ServicePointManager类，我没有看到TLS 1.0和1.1的枚举值。在这两个。net 4.0/4.5中，默认为SecurityProtocolType.Tls|SecurityProtocolType.Ssl3。希望在注册表中禁用SSLv3不会破坏这个默认值。
然而，我决定将所有应用程序升级到。net 4.5，并显式地添加SecurityProtocolType。Tls |安全协议类型。Tls11 | SecurityProtocolType.Tls12;总之，所有应用程序的引导代码。
这将使对各种api和服务的出站请求不降级到SSLv3，并且应该选择最高级别的TLS。
这种方法听起来合理还是过份?我有很多应用程序要更新，我想在未来证明它们，因为我听说在不久的将来，一些提供商可能会弃用TLS 1.0。
作为一个向api发出出站请求的客户端，在注册表中禁用SSL3会对.NET框架产生影响吗?我看到默认情况下，TLS 1.1和1.2没有启用，我们必须通过注册表启用它吗?是http://support.microsoft.com/kb/245030。
经过一番研究，我相信注册表设置不会有任何影响，因为它们适用于IIS(服务器子密钥)和浏览器(客户端子密钥)。
对不起，这篇文章变成了多个问题，然后是“可能”的答案。
有两种可能的情况，
如果你的应用程序运行在。net framework 4.5或更低版本上，你可以很容易地将新代码部署到产品中，那么你可以使用下面的解决方案。
你可以在调用api之前添加下面的代码行，
ServicePointManager。SecurityProtocol = SecurityProtocolType.Tls12;// .net 4.5
如果您无法部署新代码，而希望使用生产环境中存在的相同代码进行解析，那么您有两个选择。
方案一:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
然后创建一个扩展名为.reg的文件并安装。
注意:此设置将应用于注册表级别，并适用于该机器上的所有应用程序，如果您希望仅限制为单个应用程序，则可以使用选项2
选项2:这可以通过更改配置文件中的一些配置设置来完成。
您可以在配置文件中添加其中任何一个。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false"/>
</runtime>
or
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"
</runtime>
I'm running under .NET 4.5.2, and I wasn't happy with any of these answers. As I'm talking to a system which supports TLS 1.2, and seeing as SSL3, TLS 1.0, and TLS 1.1 are all broken and unsafe for use, I don't want to enable these protocols. Under .NET 4.5.2, the SSL3 and TLS 1.0 protocols are both enabled by default, which I can see in code by inspecting ServicePointManager.SecurityProtocol. Under .NET 4.7, there's the new SystemDefault protocol mode which explicitly hands over selection of the protocol to the OS, where I believe relying on registry or other system configuration settings would be appropriate. That doesn't seem to be supported under .NET 4.5.2 however. In the interests of writing forwards-compatible code, that will keep making the right decisions even when TLS 1.2 is inevitably broken in the future, or when I upgrade to .NET 4.7+ and hand over more responsibility for selecting an appropriate protocol to the OS, I adopted the following code:
SecurityProtocolType securityProtocols = ServicePointManager.SecurityProtocol;
if (securityProtocols.HasFlag(SecurityProtocolType.Ssl3) || securityProtocols.HasFlag(SecurityProtocolType.Tls) || securityProtocols.HasFlag(SecurityProtocolType.Tls11))
{
securityProtocols &= ~(SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11);
if (securityProtocols == 0)
{
securityProtocols |= SecurityProtocolType.Tls12;
}
ServicePointManager.SecurityProtocol = securityProtocols;
}
This code will detect when a known insecure protocol is enabled, and in this case, we'll remove these insecure protocols. If no other explicit protocols remain, we'll then force enable TLS 1.2, as the only known secure protocol supported by .NET at this point in time. This code is forwards compatible, as it will take into consideration new protocol types it doesn't know about being added in the future, and it will also play nice with the new SystemDefault state in .NET 4.7, meaning I won't have to re-visit this code in the future. I'd strongly recommend adopting an approach like this, rather than hard-coding any particular security protocol states unconditionally, otherwise you'll have to recompile and replace your client with a new version in order to upgrade to a new security protocol when TLS 1.2 is inevitably broken, or more likely you'll have to leave the existing insecure protocols turned on for years on your server, making your organisation a target for attacks.
