Underlying connection was closed with linkedin

Question

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?

Orifice

Answer 1

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.

Orifice

Answer 2

We've had the same issue here and my colleague has been working on this for the past few days. Absolutely spot on with the accepted answer (he actually enabled all the ciphers but will now go back and apply the two from your answer above), but that didn't fully work for us, so additional changes were needed.

He edited two Registry keys based on Microsoft's article https://learn.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

And then he set up the IIS Crypto as follows:

Hope that helps someone else if the accepted answer doesn't quite work!

Rattly

Answer 3

I am using windows server 2008 r2 and there appears to be no way to add these ciper suites.

Hinckley