我们有一个使用.Net Framework 4.6.1运行的应用程序,该应用程序可以访问Linkedin并调用端点:

https://www.linkedin.com/oauth/v2/accessToken
它一直运行到2020/07/14之后,之后在我们所有的环境中开始失败,并出现以下错误:

我们已经在运行一些测试,发现可以在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之后的握手期间重置了连接:
c# - 底层连接已通过linkedin关闭-LMLPHP
您好的相关部分是:
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仅允许以下协议(protocol):

  • 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获得的
    检查我们的配置后,我们意识到没有在服务器中启用它们。查阅文档,我们发现Windows Server 2012 R2不能使用Windows Server 2016的前两个协议(protocol)
    因此,我们只需要使用“密码套件”选项卡中名为IIS Crypto的工具启用最后两种协议(protocol),然后重置计算机即可。
    c# - 底层连接已通过linkedin关闭-LMLPHP

    07-24 09:44
    查看更多