Closed PKizzle closed 3 months ago
Problem here is that we are then enforcing a QUIC-enabled SSL library in base image of our IC product to everyone, which also includes possible security issues that otherwise distro security maintainers take care of. I don't think we are going to replace regular OpenSSL base image with quictls-enabled one soon.
One option could be to offer two different images similar to how the base haproxy image handles this.
I'll pass on your request further up the chain and up for internal discussion 👍
I have noticed that initial QUIC support has been added with 67f36664afce87c1dff2f4190f58d902947eb60d 🎉
Thank you very much @ivanmatmati!
I have just one question regarding the implementation: Why is it necessary to have a working default certificate for QUIC to be enabled? Consider the following situation: I have configured specific certificates for various subdomains and the default (fallback) certificate is out of date then QUIC will be globally disabled even though all other certificates are valid. This does not seem the case with HTTPS implementation.
Hi @PKizzle , we took note of your suggestion and will discuss it in a follow-up of this feature as we plan to expand it in a close future.
Since I am using this feature without any issues in production I will close this issue. Note: I am building the image manually using haproxytech/haproxy-debian-quic
as the base image in order to gain full QUIC support.
Since Kubernetes 1.24 the feature gate
MixedProtocolLBService
is enabled by default and finally makes it possible to open the same ports for differenct protocols. This allows clients to connect to HTTP/2 via TCP on port 443 or using HTTP/3 via UDP on the same port. Since there are already Docker images available with the QUIC feature flag being set (haproxytech/haproxy-alpine-quic) I guess that the amount of work to enable this feature should not be overwhelmingly large.Search Keywords: H3, HTTP3, QUIC