与 linkedin 的底层连接已关闭
Underlying connection was closed with linkedin
我们有一个应用程序 运行 .Net Framework 4.6.1 可以访问调用端点的 Linkedin:
https://www.linkedin.com/oauth/v2/accessToken
它一直工作到 2020 年 7 月 14 日,之后它开始在我们所有的环境中失败并出现以下错误:
An error occurred while sending the request.The underlying connection was closed: An unexpected error >occurred on a send.Unable to read data from the transport connection: An existing connection was forcibly >closed by the remote host.An existing connection was forcibly closed by the remote host
我们已经 运行 进行了一些测试,我们发现我们可以在 PowerShell 中使用以下命令重现该错误:
Invoke-WebRequest -Uri https://www.linkedin.com
经过一番研究,我们意识到可以使用以下命令强制 PowerShell 使用 TLS 1.2:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
但它在我们的 IIS 服务器上不起作用。在其他没有安装 IIS 的服务器上,该命令有效,我们可以正确访问 Linkedin URL。
我们还尝试在 C# 中执行等效操作,结果相同:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
似乎错误与 Tls12 有关,所以我们开始查看 Wireshark,我们发现在 HELLO 之后的握手期间连接被重置:
问候的相关部分是:
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 153
Version: TLS 1.2 (0x0303)
Random: 5f1536566faf9700973045f3e502909a269ec62f2df23243…
Session ID Length: 0
Cipher Suites Length: 32
Cipher Suites (16 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 80
Extension: server_name (len=21)
Extension: supported_groups (len=8)
Extension: ec_point_formats (len=2)
Extension: signature_algorithms (len=20)
Extension: session_ticket (len=0)
Extension: extended_master_secret (len=0)
Extension: renegotiation_info (len=1)
我们还有另一个使用 Twitter 的工作流程,它与 Linkedin 一样,只允许 TLS 1.2,并且工作正常。因此,除了我们的研究之外,我们并不确定问题是否出自 TLS。
此应用程序 运行 在 Windows Server 2012 R2 和 IIS 8 下。并且在过去几周内没有应用任何可能影响此行为的更新。
有人知道这个问题的原因吗?
经过一些研究,我们发现 Linkedin 只允许以下协议:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
之前的列表来自ssllabs.com
检查我们的配置,我们发现我们的服务器中启用了 none。查看文档我们发现前两个协议不适用于 Windows Server 2012 R2 being available from Windows Server 2016
因此,我们只需要在“密码套件”选项卡中使用名为 IIS Crypto 的工具启用最后两个协议并重置计算机。
我们这里遇到了同样的问题,过去几天我的同事一直在处理这个问题。
完全符合接受的答案(他实际上启用了所有密码,但现在将返回并应用上面答案中的两个密码),但这对我们来说并不完全有效,因此需要进行其他更改。
他根据微软的文章https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls编辑了两个注册表项:
You can make use of the SchUseStrongCrypto registry setting to require all .NET applications to use TLS 1.2 instead of 1.0 by default.
Windows Registry Editor Version 5.00
[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
然后他按如下方式设置 IIS Crypto:
如果已接受的答案不太奏效,希望对其他人有所帮助!
我正在使用 windows 服务器 2008 r2,似乎无法添加这些 ciper 套件。
我们有一个应用程序 运行 .Net Framework 4.6.1 可以访问调用端点的 Linkedin:
https://www.linkedin.com/oauth/v2/accessToken
它一直工作到 2020 年 7 月 14 日,之后它开始在我们所有的环境中失败并出现以下错误:
An error occurred while sending the request.The underlying connection was closed: An unexpected error >occurred on a send.Unable to read data from the transport connection: An existing connection was forcibly >closed by the remote host.An existing connection was forcibly closed by the remote host
我们已经 运行 进行了一些测试,我们发现我们可以在 PowerShell 中使用以下命令重现该错误:
Invoke-WebRequest -Uri https://www.linkedin.com
经过一番研究,我们意识到可以使用以下命令强制 PowerShell 使用 TLS 1.2:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
但它在我们的 IIS 服务器上不起作用。在其他没有安装 IIS 的服务器上,该命令有效,我们可以正确访问 Linkedin URL。
我们还尝试在 C# 中执行等效操作,结果相同:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
似乎错误与 Tls12 有关,所以我们开始查看 Wireshark,我们发现在 HELLO 之后的握手期间连接被重置:
问候的相关部分是:
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 153
Version: TLS 1.2 (0x0303)
Random: 5f1536566faf9700973045f3e502909a269ec62f2df23243…
Session ID Length: 0
Cipher Suites Length: 32
Cipher Suites (16 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 80
Extension: server_name (len=21)
Extension: supported_groups (len=8)
Extension: ec_point_formats (len=2)
Extension: signature_algorithms (len=20)
Extension: session_ticket (len=0)
Extension: extended_master_secret (len=0)
Extension: renegotiation_info (len=1)
我们还有另一个使用 Twitter 的工作流程,它与 Linkedin 一样,只允许 TLS 1.2,并且工作正常。因此,除了我们的研究之外,我们并不确定问题是否出自 TLS。
此应用程序 运行 在 Windows Server 2012 R2 和 IIS 8 下。并且在过去几周内没有应用任何可能影响此行为的更新。
有人知道这个问题的原因吗?
经过一些研究,我们发现 Linkedin 只允许以下协议:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
之前的列表来自ssllabs.com
检查我们的配置,我们发现我们的服务器中启用了 none。查看文档我们发现前两个协议不适用于 Windows Server 2012 R2 being available from Windows Server 2016
因此,我们只需要在“密码套件”选项卡中使用名为 IIS Crypto 的工具启用最后两个协议并重置计算机。
我们这里遇到了同样的问题,过去几天我的同事一直在处理这个问题。 完全符合接受的答案(他实际上启用了所有密码,但现在将返回并应用上面答案中的两个密码),但这对我们来说并不完全有效,因此需要进行其他更改。
他根据微软的文章https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls编辑了两个注册表项:
You can make use of the SchUseStrongCrypto registry setting to require all .NET applications to use TLS 1.2 instead of 1.0 by default.
Windows Registry Editor Version 5.00
[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
然后他按如下方式设置 IIS Crypto:
如果已接受的答案不太奏效,希望对其他人有所帮助!
我正在使用 windows 服务器 2008 r2,似乎无法添加这些 ciper 套件。