与 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 套件。