底层连接已通过linkedin关闭 [英] Underlying connection was closed with linkedin

问题描述

我们有一个运行.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之后的握手期间重置了连接:

您好的相关部分是:

 握手协议:客户端Hello握手类型:客户端Hello(1)长度:153版本:TLS 1.2(0x0303)随机:5f1536566faf9700973045f3e502909a269ec62f2df23243…会话ID长度:0密码套件长度:32密码套房(16间套房)密码套件:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xc028)密码套件:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xc027)密码套件:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xc014)密码套件:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xc013)密码套件:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xc02c)密码套件:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xc02b)密码套件:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xc024)密码套件:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xc023)密码套件:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xc00a)密码套件:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xc009)密码套件:TLS_RSA_WITH_AES_256_GCM_SHA384(0x009d)密码套件:TLS_RSA_WITH_AES_128_GCM_SHA256(0x009c)密码套件:TLS_RSA_WITH_AES_256_CBC_SHA256(0x003d)密码套件:TLS_RSA_WITH_AES_128_CBC_SHA256(0x003c)密码套件:TLS_RSA_WITH_AES_256_CBC_SHA(0x0035)密码套件:TLS_RSA_WITH_AES_128_CBC_SHA(0x002f)压缩方式长度:1压缩方法(1种方法)扩展长度:80扩展名:server_name(len = 21)扩展名:supported_groups(len = 8)扩展名:ec_point_formats(len = 2)扩展名:signature_algorithms(len = 20)扩展名:session_ticket(len = 0)扩展名:extended_master_secret(len = 0)扩展名: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)

以前的列表是从

We have an application running with .Net Framework 4.6.1 that access to Linkedin calling to the endpoint:

https://www.linkedin.com/oauth/v2/accessToken

It was working until past 2020/07/14 after that it started failing in all of our environments with the following error:

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

We've been running some tests and we found that we can reproduce the error with the following command in PowerShell:

Invoke-WebRequest -Uri https://www.linkedin.com

After some research, we realized that we can force PowerShell to use TLS 1.2 using the following command:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

But it didn't work in our IIS Servers. In other servers that don't have IIS installed the command works and we can access Linkedin URL properly.

We also tried to do the equivalent in C# with the same results:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Seems that the error is related with Tls12 so we started taking a look with Wireshark and we found that the connection is reset during the handshake after the HELLO:

The relevant part of the hello is:

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)

We also have another workflow where we use Twitter which, like Linkedin, only allows TLS 1.2 and it is working properly. So, besides our research, we are not really sure that the problem came from TLS.

This application is running under a Windows Server 2012 R2 and an IIS 8. And no updates have been applied during the last weeks that can affect this behavior.

Does anybody know what could be the cause to this issue?

解决方案

After some research, we found that Linkedin only allows the following protocols:

• 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)

The previous list was obtained from ssllabs.com

Checking our configuration we realized that none of them were enabled in our server. Checking in the documentation we saw that the first two protocols are not available for Windows Server 2012 R2 being available from Windows Server 2016

So, we just need to enable the last two protocols using a tool called IIS Crypto in the tab "Cipher suites" and reset the computer.

这篇关于底层连接已通过linkedin关闭的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！