与支持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(服务器子密钥)和浏览器(客户端子密钥)。
对不起，这篇文章变成了多个问题，然后是“可能”的答案。
当我的客户将TLS从1.0升级到1.2时，我遇到了这个问题。
我的应用程序使用。net framework 3.5和运行在服务器上。所以我用这种方法来解决它:
修复程序
在调用HttpWebRequest.GetResponse()之前添加以下命令:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolTypeExtensions.Tls11 | SecurityProtocolTypeExtensions.Tls12;
通过添加2个新类扩展2个dll: System。网络和系统。安全性。身份验证
namespace System.Net
{
using System.Security.Authentication;
public static class SecurityProtocolTypeExtensions
{
public const SecurityProtocolType Tls12 = (SecurityProtocolType)SslProtocolsExtensions.Tls12;
public const SecurityProtocolType Tls11 = (SecurityProtocolType)SslProtocolsExtensions.Tls11;
public const SecurityProtocolType SystemDefault = (SecurityProtocolType)0;
}
}
namespace System.Security.Authentication
{
public static class SslProtocolsExtensions
{
public const SslProtocols Tls12 = (SslProtocols)0x00000C00;
public const SslProtocols Tls11 = (SslProtocols)0x00000300;
}
}
更新Microsoft批处理
批量下载:
windows 2008 R2操作系统:windows6.1-kb3154518-x64.msu
windows 2012
R2: windows8.1-kb3154520-x64.msu
下载批量和更多细节，你可以在这里看到:
https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework-3.5.1-on-windows-7-sp1-and-server-2008-r2-sp1
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.
