runtime: HTTP2: SocketsHttpHandler setting Ssl.AllowRenegotiation=false incorrectly
Found during PR dotnet/corefx#35240.
SocketsHttpHandler (as part of always trying HTTP/2 first) is always setting SslStream.AllowRenegotiation to false when first attempting to connect via HTTP/2. This is fine
if the connection is truly HTTP/2 since HTTP/2 doesn’t support TLS renegotiation. However, if the
remote endpoint doesn’t support HTTP/2 and thus connects with HTTP/1.1, then the SslStream should
not have AllowRenegotiation set to false.
Client certificate scenarios frequently have the server ask for the client certificate later in the connection process. So, TLS renegotiation is used.
SocketsHttpHandler (or SslStream) should be fixed to reset the SslStream.AllowRenegotation property back to true (which is the default value) in cases where HTTP/1.1 is the resulting connection.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 21 (21 by maintainers)
That’s interesting. In other words, fix this by simply removing the setting of AllowRenegotation = false in SocketsHttpHandler.
You mean breaking layering and teaching SslStream about specifics of HTTP2?
Perhaps we should have a way of changing that in the ALPN callback or re-query after calling that callback (possibly new API).
On the other hand it slightly feels to me that since TLS is aware of ALPN it should know that HTTP2 does not allow re-negotiation in which case TLS would/should auto-restrict re-negotiation when it notices HTTP2 (in which case the HTTP client wouldn’t do anything special to handle that).