ASP.NET 5 docker image fails to communicate with TLS1.2 server

[jchannon]

Description

We have a ASP.NET Core app inside mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim that talks to a server via https (via HttpClient) that seems to report it has TLS1.2 support and ciphers that the image should support. It fails to connect via HttpClient with an SSL exception and also can be seen in curl

The SSL labs report can be seen here https://www.ssllabs.com/ssltest/analyze.html?d=stdapi.webflotta.hu

I found this document about changes in Linux and .NET 5 and changed the container's ciphers to match the minimal conf file at the bottom of this document and it started working https://docs.microsoft.com/en-us/dotnet/core/compatibility/cryptography/5.0/default-cipher-suites-for-tls-on-linux

Should the MS Docker images have the SSL conf match what is in that document?

@bartonjs

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

We have a ASP.NET Core app inside mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim that talks to a server via https (via HttpClient) that seems to report it has TLS1.2 support and ciphers that the image should support. It fails to connect via HttpClient with an SSL exception and also can be seen in curl

The SSL labs report can be seen here https://www.ssllabs.com/ssltest/analyze.html?d=stdapi.webflotta.hu

I found this document about changes in Linux and .NET 5 and changed the container's ciphers to match the minimal conf file at the bottom of this document and it started working https://docs.microsoft.com/en-us/dotnet/core/compatibility/cryptography/5.0/default-cipher-suites-for-tls-on-linux

Should the MS Docker images have the SSL conf match what is in that document?

@bartonjs

Author:	jchannon
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

[vcsjones]

Well, the curl issue reproduces in the original debian:buster docker image, and likely in Debian as well.

This isn't exactly a cipher suite issue. Using the stock Debian container, I can see that the client and server agree on ECDHE-RSA-AES256-GCM-SHA384, but fail because the SigAlg being used is SHA1:

openssl s_client -connect stdapi.webflotta.hu:443 -security_debug_verbose

Security callback: Check Signature Algorithm scheme=rsa_pkcs1_sha1, security bits=80: no
140237302592640:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1111

By changing the SECLEVEL, you're permitting SHA1 signatures.

Interestingly, if you disable SNI, it works:

openssl s_client -connect stdapi.webflotta.hu:443 -security_debug_verbose -noservername

Security callback: Check Signature Algorithm scheme=rsa_pkcs1_sha256, security bits=128: yes

This leads me to believe that the server is using a buggy version of OpenSSL, where signature algorithms were offered incorrectly when using SNI, and is fixed here openssl/openssl#4554.

Any chance you know how the server at stdapi.webflotta.hu is configured? It looks like it's using nginx, possibly with a version of OpenSSL that has the issue you are working around.

[jchannon]

I have no knowledge or control over the server

…

On Tue, 16 Feb 2021 at 16:51, Kevin Jones ***@***.***> wrote: Well, the curl issue reproduces in the original debian:buster docker image, and likely in Debian as well. This isn't exactly a cipher suite issue. Using the stock Debian container, I can see that the client and server agree on ECDHE-RSA-AES256-GCM-SHA384, but fail because the SigAlg being used is SHA1: openssl s_client -connect stdapi.webflotta.hu:443 -security_debug_verbose Security callback: Check Signature Algorithm scheme=rsa_pkcs1_sha1, security bits=80: no 140237302592640:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1111 By changing the SECLEVEL, you're permitting SHA1 signatures. *Interestingly*, if you disable SNI, it works: openssl s_client -connect stdapi.webflotta.hu:443 -security_debug_verbose -noservername This leads me to believe that the server is using a buggy version of OpenSSL, where signature algorithms were offered incorrectly when using SNI, and is fixed here openssl/openssl#4554 <openssl/openssl#4554>. Any chance you know how the server at stdapi.webflotta.hu is configured? It looks like it's using nginx, possibly with a version of OpenSSL that has the issue you are working around. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#48337 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZVJSSOYMULXNHA7M46ODS7KPCFANCNFSM4XWSWCXA> .

[ManickaP]

Triage: this might not be an issue with .NET 5.0 but a server problem.
@jchannon does the issue happen outside of docker as well?

[jchannon]

What exact distro would you want it tested on?

…

On Thu, 18 Feb 2021 at 17:19, Marie Píchová ***@***.***> wrote: Triage: this might not be an issue with .NET 5.0 but a server problem. @jchannon <https://github.com/jchannon> does the issue happen outside of docker as well? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48337 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZVJXN5XOAVYQLXDAPIXLS7VD3VANCNFSM4XWSWCXA> .

[vcsjones]

Triage: this might not be an issue with .NET 5.0 but a server problem.

I can reproduce it with openssl in plain Debian buster images.

FROM debian:buster
RUN apt-get update && apt-get install -y openssl
CMD openssl s_client -connect stdapi.webflotta.hu:443 -security_debug_verbose

Debian buster takes a fairly aggressive stance on disabling old algorithms by default, in this case SHA1 signature algorithms. The site is using a configuration that uses SHA1 signature algorithms. My suspicion is that the site uses a buggy version of OpenSSL, indicated by the varying behavior of SNI.

[wfurt]

Purpose of the change was to have secure defaults @jchannon so I think the answer is no. I also feel that is ok if different bistro vends have their unique setting to reflect their preferences.

I try same command @vcsjones on Ubuntu 20 and it seems to work.

Could you try 5.0-focal @jchannon to see if that works for you?

[vcsjones]

@wfurt this actually fails for me in Ubuntu focal as well. When you tested did you get an exit code of 0 or 1?

[wfurt]

yeah. I spoke too soon. 20.04 fails. Ubuntu 18.04 works with & without SNI

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

That suggest there should be some solution for this particular server.

[ghost]

This issue has been automatically marked no recent activity because it has been marked as needs more info but has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no recent activity.

Please refer to our contribution guidelines for tips on what information might be required.

[cetindogu]

Same problem, .net 5 images cant connect to SQL server (debian 11)
Same problem with .net6 images
Alpine, debian 11 and Ubuntu 20.04 not working

Ubuntu 18.04 working
So problem is tls1.2
İ saw eventlogs schannel says tls1.2 connection failed

[ghost]

This issue has been automatically marked no recent activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no recent activity.

[wfurt]

I look at this again and I think @vcsjones is right. The site sometimes chooses Signature Algorithm: rsa_pkcs1_sha1 (0x0201) and sometimes Signature Algorithm: rsa_pkcs1_sha256 (0x0401). (Visible in Server Key Exchange frame).

It does not matter If this is because of the linked bug or something I noticed in #78957 where the site seems to be front-loaded by nginx based on the name. Since the sha1 is banned by OS configuration the handshake fails.

Changing the SecLevel seems correct action - even if highly inconvenient. I don't think we (e.g. NET) are going to change Linux OS default to allow insecure algorithms. The general trend is to follow OS choices. The Exception raised seems unique and relevant so it should be possible to diagnose this quickly.

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
 ---> Interop+OpenSsl+SslException: SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL.
 ---> Interop+Crypto+OpenSslCryptographicException: error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
   --- End of inner exception stack trace ---
   at Interop.OpenSsl.DoSslHandshake(SafeSslHandle context, ReadOnlySpan`1 input, Byte[]& sendBuf, Int32& sendCount)

There is openssl/openssl#17662 discussing this but I don't know if anything is directly relevant to .NET APIs and functions. It would just provide more granular choices to the user.

cc: @bartonjs for any more thoughts.

I don't know if this is same issue as the SQL @cetindogu. Feel free to post more info and possibly simple repro for investigation.