Microsoft.AspNetCore.Server.Kestrel.Core 2.3.6 restricts the ListenOptions Protocols

[w4mhi]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Hi,
The issue was closed with a comment that 2.3 is based 2.1 and not on 2.2
I understand that, but what is the solution for ListenOptions? We are using this in production and we are looking for a solution. You have only Http1 and no support for Http2. Please advice.

Here is the issue (avoid code duplication):
Microsoft.AspNetCore.Server.Kestrel.Core 2.3.6 restricts the ListenOptions Protocols
#64256

Thank you,
Mihai

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.Protocols is internal in Microsoft.AspNetCore v2.3.0 #61823

[w4mhi]

I investigated and the breaking change is here:
2.2.0 - public HttpProtocols Protocols { get; set; } = HttpProtocols.Http1;
2.3.0 - internal HttpProtocols Protocols { get; set; } = HttpProtocols.Http1;

I understand the API was internal in 2.1.0, but now everyone using 2.2.0 have no solution. 2.2.0 has vulnerabilities that were fixed in 2.3.0(6) but the breaking change force us to not make the migration to the new library.

This is a breaking change that let us without choice for Http2. Please advise.

More to come. Here are the Protocols in the source:
///

/// The protocols enabled on this endpoint.
///

/// Defaults to HTTP/1.x and HTTP/2
public HttpProtocols Protocols
{
get => _protocols;
set
{
_protocols = value;
ProtocolsSetExplicitly = true;
}
}
Why the sources show 'public' and the nuget has 'internal'. Could anyone explain? Thanks!

[martincostello]

The path forward should have been to upgrade from 2.2 to 3.0 around the time it was released, and then keep pace with upgrades from there as 2.2 was a Short (now Standard) Term Support release so was only in support for a year. Support lifetimes for STS have since increased to 18 months and then recently 2 years, but those increases aren't retrospective to versions that have already reached the end of their support life.

2.2 has been out of support since December 2019, so disregarding the specific CVE, your use has been unsupported for nearly 6 years at this point.

Some options could include:

• downgrade to 2.3 (as it's effectively 2.1) and lose the functionality
• suppress the CVE warning if your specific use case is not affected by it (you would need to audit and verify this yourself, only you know what your app does)
• upgrade to a version that is in support (8+)

I'm sure none of these options are good for you, but staying on unsupported versions for so long is a ticking time-bomb for when (not if) a vulnerability that needs to be patched is uncovered that needs addressing.

Maybe there's other possibilities you could explore, but I think they are the intended avenues.

[martincostello]

Also note that for use beyond 2.3 of the API in question, it does not ship as a specific NuGet package. Instead it is part of the Shared Framework which you need to use instead, as documented here: https://learn.microsoft.com/aspnet/core/fundamentals/target-aspnetcore#use-the-aspnet-core-shared-framework