8.0 image breaking change due to Debian 12 breaking change

[richlander]

I think we may have missed creating a breaking change notice related to:

• Docker : OpenSslCryptographicException: error:0A000410:SSL routines::sslv3 alert handshake failure runtime#107172
• Failed to setup SSL connection with .NET8 Linux-Container Image with failure "Received an unexpected EOF or 0 bytes from the transport stream"  runtime#98797 (comment)

I received a customer report that led me to those issues. The following is what I found.

• We made a breaking change in .NET 5 related to cipher suites: https://learn.microsoft.com/en-us/dotnet/core/compatibility/cryptography/5.0/default-cipher-suites-for-tls-on-linux#change-description
• These changes are based on guidance per Microsoft security standards.
• However, the change in behavior allowed the openssl.conf to override the .NET defaults.
• Debian 11 (and likely earlier versions) includes overrides so there was no effective change.
• Debian 12 no longer includes the overrides so the break is finally effective with .NET 8.
• It's not entirely clear that we shipped the right behavior back with .NET 5 (given that Debian overrode them). That appears to no longer matter.
• The switch to Ubuntu 24.04 won't result in another behavior, per Proposal: Switch to Ubuntu for .NET convenience tags #5709
• The workaround is to modify /etc/ssl/openssl.cnf to include the override content, present in the following examples.

The following demonstrates version differences. It looks like all distros at tip are now the same and that .NET defaults are now the defaults. That means that the official images are now in compliance with Microsoft security standards. One expects that those standards will change again at some point.

Debian:

$ docker run --rm mcr.microsoft.com/dotnet/aspnet:6.0 cat /etc/ssl/*.cnf | tail -n 3
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:6.0 cat /etc/ssl/*.cnf | grep Cipher
CipherString = DEFAULT@SECLEVEL=2
=$ docker run --rm mcr.microsoft.com/dotnet/aspnet:7.0 cat /etc/ssl/*.cnf | grep Cipher
CipherString = DEFAULT@SECLEVEL=2
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:8.0 cat /etc/ssl/*.cnf | grep Cipher
$

Alpine:

$ docker run --rm mcr.microsoft.com/dotnet/aspnet:6.0-alpine cat /etc/ssl/*.cnf | grep Cipher
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:7.0-alpine cat /etc/ssl/*.cnf | grep Cipher
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:8.0-alpine cat /etc/ssl/*.cnf | grep Cipher

Ubuntu:

$ docker run --rm mcr.microsoft.com/dotnet/aspnet:6.0-jammy cat /etc/ssl/*.cnf | tail -n 3

[system_default_sect]
CipherString = DEFAULT:@SECLEVEL=2
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:6.0-jammy cat /etc/ssl/*.cnf | grep Cipher
CipherString = DEFAULT:@SECLEVEL=2
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:7.0-jammy cat /etc/ssl/*.cnf | grep Cipher
CipherString = DEFAULT:@SECLEVEL=2
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:8.0-jammy cat /etc/ssl/*.cnf | grep Cipher
CipherString = DEFAULT:@SECLEVEL=2
$ docker run --rm mcr.microsoft.com/dotnet/aspnet:8.0-noble cat /etc/ssl/*.cnf | grep Cipher
$

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[richlander]

Assuming everyone agrees, we should consider adding this break to docs. It appears that multiple people have hit this.

@bartonjs @vcsjones @gewarren

[bartonjs]

I'm not sure where you want to document it, but I won't get in your way.

The cynic in me does say, though, "It's 2024. TLS 1.2 (and the minimum ciphersuites on our default list) was ratified in 2008. You really shouldn't be using anything that can't talk with our defaults, as it means you don't have nearly the the level of security that you think you do...".

[richlander]

There is a distinction between a change in behavior and whether a workaround is a good idea. My intent is to document a change in behavior. One can think of three waves of users, at various timeframes: 8.0 GA, 7.0 EOL, and 6.0 EOL. It's entirely possible that this issue is coming up now due to 6.0 EOL. The stated reason is that .NET 8 cannot connect to certain database software. It's likely that people are using old versions of the database software that do not support TLS 1.3 (ratified in 2018). A primary solution (not a workaround) should be to upgrade your database and any other relevant components such that TLS 1.3 can be used and that the .NET and OS defaults can be use as-is.

Note that this issue is not the breaking change notice but a suggestion to write one and to ensure we have the right guidance.

[lbussell]

I'm not sure where you want to document it, but I won't get in your way.

Presumably it would go here https://learn.microsoft.com/en-us/dotnet/core/compatibility/8.0#containers

[richlander]

I can make a PR next week.

[AppMarius]

Hi Microsoft Team,

May this Issue be also related to a recent critical CVE-2024-5535 https://security-tracker.debian.org/tracker/[CVE-2024-5535](https://security-tracker.debian.org/tracker/CVE-2024-5535) ?
Related to the Debian 12 image (.net 8.0)

[lbussell]

Hi @AppMarius. No, this is not related to CVE-2024-5535. @richlander is describing a breaking change between Debian 11 and Debian 12 that affected .NET 8 images all the way back in November of last year. The breaking change he mentions is also not a vulnerability.