Open lukeelmers opened 4 weeks ago
Pinging @elastic/kibana-core (Team:Core)
Also cc @pgayvallet as our http2 expert 🙂
This proposal makes sense to me. One caveat is clients running with only TLSv1.1
.
h2 requires TLSv1.2 or better. While I expect most/all installations will have this configured, it's technically possible to tell Kibana to only support TLSv1.1
. I don't think we should automatically enable http2 in this scenario.
Given that there's http1 fallback I don't foresee this causing any issues, but we are essentially defaulting to enabling http2 so it feels like it would be worth highlighting this in our release notes.
Just to clarify: h2 is the protocol, and http2 is the spec of having h2 over tls.
http2 requires TLS1.2, because TLS Protocol negotiation (ALPN) is a TLS1.2+ feature, so http2-to-https fallback will not work if Kibana is configured to only run on TLS1.1.
So Larry is right, we should not enable http2 automatically if TLS is configured to run only on tls1.1.
I already implemented that check in the http2 support PR, so it should only be about reusing that logic: https://github.com/elastic/kibana/blob/fe83c0da5644f630b79d93546e5f587f01192026/packages/core/http/core-http-server-internal/src/http_config.ts#L266-L271
I don't see any other problem with that proposal, and think it's a great idea.
We want http2 to be the default experience for as many Kibana users as possible. What if, starting in 9.0, we were to automatically enable http2 (
server.protocol
) if we detected that TLS is enabled (server.ssl.*
)? Are there any risks/downsides?cc @timductive @rayafratkina @thomasneirynck @elastic/kibana-security