[release/8.0] Don't unset ALPN list pointer during ALPN selection callback. #99670
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones |
rzikm
changed the title
|
@rzikm, any chance of this backport making it into the April patch release of .NET 8? |
Unfortunately no, the deadline for that one was on Monday. |
|
The CI failure is unrelated |
|
@rzikm any news on this making it into the May patch release? |
The deadline for code changes for that release is mid April, I am keeping an eye on this so that it makes it there. |
|
FIPS on Linux is important scenario. It is a regression against .NET 6.0. We should fix it. |
rbhanda
added
Servicing-approved
|
CI failure is unrelated. System.Net.Security-related pipeliens pass |
Backport of #99357 to release/8.0-staging
Fixes #99289
/cc @rzikm
Customer Impact
The issue prevents adoption of .NET 8 in scenarios where FIPS conformance is required on Linux. Clients attempting to connect to FIPS .NET 8 Linux server will see TLS protocol errors.
The only workarounds are disabling TLS 1.3 or allowing algorithms not approved by FIPS on the server running the application. These workarounds go against security best-practices and may require system-wide configuration settings which may not be accessible in e.g. cloud deployment scenarios.
Reported by 2 customers:
Technical details
The issue in .NET is not related to FIPS specifically. When connecting to server via TLS 1.3, clients take a guess at an algorithm to be used when negotiating the shared secret needed for deriving the encryption keys. If server does not agree with the clients guess, it sends a HelloRetryRequest message with a different algorithm suggestion. The client then retries the handshake process.
The typical default guess of clients (x25519) is not a FIPS approved algorithm, and thus servers configured to use only FIPS-approved algorithms would always reply with HelloRetryRequest.
Another part of the TLS handshake process is Application Layer Protocol Negotiation (ALPN), which allows negotiating e.g. the HTTP version as during the TLS handshake (client sends a list of protocols it is willing to negotiate, server picks one of these). The bug manifests because .NET discards the list of accepted ALPN protocols on the server after receiving the first ClientHello. However, due to server sending a HelloRetryRequest, client sends another ClientHello message and at this point, the server behaves as if there was no commonly understood application layer protocol and terminates the handshake.
Regression
Yes, regression against .NET 6.0, introduced in PR #57079 (.NET 7).
Testing
Tested manually. It is not possible to implement automated test (the API on OpenSSL is not exposed via .NET APIs). Editing system-wide configuration is necessary for reproducing the issue.
The issue was missed previously because the situation where server replies with HelloRetryRequest is rare.
Risk
Low, the issue is well understood and tested and the fix is very localized to the rare HelloRetryRequest code path and does not affect other code paths.