Open strarsis opened 3 months ago
@swalkinshaw: Using nginx
includes makes the configuration much readable now.
The SSL early data option allows for RTT-0 requests (zero round-trip time), however, it comes with security implications (possibility of replay attacks), the application layer (so the PHP WordPress app here) gets a HTTP Header Early-Data
passed from the reverse proxy (nginx
), and for risky operations (as authentication/login) the app has to terminate requests with HTTP 425 Too Early
.
I was not able to find any occurrence of this logic in WordPress code or plugins or discussions about this, hence I commented out this optimization until it is deemed safe for WordPress applications.
Mind rebasing @strarsis ? Looks good otherwise and all the notes/documentation is appreciated.
@swalkinshaw: Sure! I also have to test the HTTP/3 specific configuration a bit further.
@swalkinshaw: Well, I "rebased" it somehow. If necessary, I create a new branch/PR.
So it turned out that a global listen for QUIC with reuseport
is necessary for working QUIC responses.
For a QUIC listen is also a SSL certificate required, it does not matter which one.
So for providing such a SSL certificate, one of the sites have to be specified as the "default site".
😓 wow they really don't make this easy. I'll try and think of another solution for the default site/SSL cert 🤔
another solution for the default site/SSL cert
That listen quic is only needed for reuseport (apparently required by the nginx worker processes for correctly responding to QUIC requests). With listen quic nginx requires a SSL cert and key, but that listen and SSL would not be used otherwise.
Working, confirmed alternatives:
/etc/ssl/certs/ssl-cert-snakeoil.pem
; /etc/ssl/private/ssl-cert-snakeoil.key
) for the global quic listen directive with reuseport to satisfy the cert condition for a quic
listen.Edit: jinja namespaces probably do not scope beyond the iteration of ansible template loops, so a different approach is used.
Now simply the first site that uses HTTPS will have the reuseports
option added to its quic listen directive.
For this a helper variable is added that contains all sites that use SSL (not the boolean one),
and then just the item key is compared to determine whether the current config in jinja is the one for the first HTTPS using site.
@swalkinshaw: Edit: After some real-world testing I noticed that some WordPress sites had redirect issues (on frontend) (ERR_TOO_MANY_REDIRECTS
). I am not sure whether this has been caused by http/3. Still testing and observing the behavior with http/3 enabled. Possible related issue. This appears to be caused by the redirects, when HTTP/3 is advertised/used there.
This PR adds the necessary configuration for proper HTTP/3 support (by
nginx
) (with HTTP/1/HTTPS/2 co-existence).nginx
documentation, forum threads (1; 2) are added to the configuration when HTTP/3 support is turned on.ferm
firewall is also configured to allow inbound UDP/433 for QUIC (HTTP/3). The approach is also used in the previous PR for HTTPS (https://github.com/roots/trellis/pull/1530).nginx
requires one (and only one listen quic directive to have thereuseport
option (only one listen quic directive can have thereuseport
option). As the listen quic directive requires a certificate, the first WordPress site ("vhost") that has HTTPS enabled, has thereuseport
option added to its listen quic directive.Additional notes (some may be useful in the documentation):
443
is actually not mandatory for HTTP/3 (to some degree, also depending on browser), but it is recommended to use the same port number443
as for HTTPS (TCP),nginx
then listens on443
/UDP
in parallel to443
/TCP
for HTTP/1/HTTPS/2.Protocol
column on).curl
/wget
HTTP/3 support is not a given in current stable Ubuntu. I used acurl Docker image with HTTP/3 support
.Useful resources
nginx
HTTP/3 example configurationcurl
with HTTP/3 supportnginx
add_header
inheritance/pitfallsnginx
HTTP/3 configurationnginx
ngx_http_v3
HTTP/3 module documentationnginx
with HTTP1.1/2/3 with some encountered issuesGSO