Runtime: TLS 1.2 The handshake failed due to an unexpected packet format

[hpetriffer]

We have an environment where we always get the error "One or more errors occurred. (The SSL connection could not be established, see inner exception.): The handshake failed due to an unexpected packet format". If you use the switch AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false), then there is no problem with the connection setup.
It happens with a netcoreapp3.0.

for (int i = 0; i < 4; i++)
{
   var client = new HttpClient();
   var result = Task.Run(()=>client.GetAsync(@"https://hubfe.solutiondocondemand.com/solutiondoc_hub.asmx?wsdl")).Result;
   result.EnsureSuccessStatusCode();
   Console.WriteLine("returned Ok");
}

Mostly the error happens in the second and the forth call

[vcsjones]

Which operating system and version is the code running on? I'm unable to reproduce this on Ubuntu 19.04.

[hpetriffer]

I have testet it with different Windows operating systems.
e.g. Windows Server 2012 R2 Standard Version 6.3.9600. If it helps I can send you a recording of Wireshark

[vcsjones]

Hm. I can't reproduce this in Windows 10, either. Any chance your organization is using a network appliance / proxy that performs TLS inspection?

What does this print out for you on one of the problematic servers, with and without the AppContext Switch?

using(var tcp = new TcpClient("hubfe.solutiondocondemand.com", 443))
using(var sslstream = new SslStream(tcp.GetStream()))
{
    sslstream.AuthenticateAsClient("hubfe.solutiondocondemand.com");
    var cert = sslstream.RemoteCertificate;
    Console.WriteLine(cert.Subject);
}

[hpetriffer]

You are right. there is a firewall with TLS inspection. If we disable the firewall for this adress it works. Your testprogram has the following output if it works

CN=*.solutiondocondemand.com, O=2C SOLUTION SRL, L=GAZZO, S=Padova, C=IT

Every second call gives the error

The handshake failed due an unexpected package format

Do you think it is an bug in the firewall?

[vcsjones]

Do you think it is an bug in the firewall?

It's certainly a possibility. TLS inspection devices have been known to be buggy^1,2,3.

It looks like TLS for hubfe.solutiondocondemand.com is terminated by an AWS Elastic Load Balancer - is that something you can confirm? If TLS is being handled by an AWS ELB, I would suspect there would be more reports of breakage if .NET Core was not able to correctly negotiate TLS with an AWS load balancer given their popularity.

It is probably worth reaching out to the manufacturer and asking if they are aware of any incompatibilities with .NET Core with their product / services.

[vcsjones]

/cc @bartonjs @davidsh

[hpetriffer]

I think you are right. The webservice runs on AWS.
Thank you for your help!