aspnetcore
aspnetcore copied to clipboard
dotnet
Http1AndHttp2 without TLS/SSL
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
Allow Kestrel to run Http1AndHttp2 over TCP without TLS/SSL.
Use case. Running Kestrel behind a TLS termination load balancer/router.
Describe the solution you'd like
https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Core/src/Internal/KestrelServerImpl.cs:164 should not just check for hasTls.
Possibly check for a flag indicating that, yes, I know that normally Http/2 will not be negotiated without TLS/SSL ALPN.
Additional context
No response
yes, I know that normally Http/2 will not be negotiated without TLS/SSL ALPN.
There's no spec for how to negotiate this without ALPN. What kind of negotiation are you proposing?
(Well, there was the Upgrade mechanic, but that's obsolete now).
We’re discussion having an optional middleware that can sniff plaintext http2 traffic for this so we can gauge interest. It has come up multiple times so maybe worth looking at it.
cc @JamesNK
As you can imagine I'm horribly dubious about making up a payload detection and assumption. Any such feature should be opt-in.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
yes, I know that normally Http/2 will not be negotiated without TLS/SSL ALPN.
There's no spec for how to negotiate this without ALPN. What kind of negotiation are you proposing?
(Well, there was the Upgrade mechanic, but that's obsolete now).
The only spec that I can think of that is in general use, and is not obsolete, that I can think of right now is to use Proxy Protocol v2. https://www.rfc-editor.org/rfc/rfc7639.html
A quick glance at https://github.com/aspnet/AspLabs/blob/main/src/ProxyProtocol/ProxyProtocol.Sample/ProxyProtocol.cs shows that the ALPN header isn't parsed in the experimental connection handler, yet.
Oh, PPv2 could do this. We'd have to see if any PPv2 clients implement that. Note RFC 7639 is not related to PPv2, the spec is here: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt,
2.2.1 PP2_TYPE_ALPN Application-Layer Protocol Negotiation (ALPN). It is a byte sequence defining the upper layer protocol in use over the connection. The most common use case will be to pass the exact copy of the ALPN extension of the Transport Layer Security (TLS) protocol as defined by RFC7301 [9].
I'm not sure any reverse proxy supports this does it? We could add it to YARP though...
Okay, what about with Proxy Protocol V2? Surely we don't need to detect protocol there.
On Sat, 10 Sept 2022, 04:10 msftbot[bot], @.***> wrote:
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md.
— Reply to this email directly, view it on GitHub https://github.com/dotnet/aspnetcore/issues/43836#issuecomment-1242414092, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA46MLL34AXXU66MPOFW6ADV5OKRTANCNFSM6AAAAAAQH6PAQI . You are receiving this because you authored the thread.Message ID: @.***>