Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nginx: http2 configuration deprecation notice #1528

Closed
strarsis opened this issue Jul 19, 2024 · 11 comments
Closed

nginx: http2 configuration deprecation notice #1528

strarsis opened this issue Jul 19, 2024 · 11 comments

Comments

@strarsis
Copy link
Contributor

strarsis commented Jul 19, 2024

Summary

After updating the Ubuntu LTS packages I noticed a nginx notice during reload:
http2" directive is deprecated, use the "http2" directive instead

The current nginx site configuration use the old, deprecated directive for enabling http2:

server {
  listen [::]:443 ssl http2;
  listen 443 ssl http2;

Instead of using http2 in the listen directive, the http2 directive (http2 on) should be used instead:

server {
  listen [::]:443 ssl;
  listen 443 ssl;
  http2 on;

Additional context

Blog post about the deprecation

@swalkinshaw
Copy link
Member

The directive was added in 1.25.1 which was released a year ago. But because we use the PPA it should be fine?

@swalkinshaw
Copy link
Member

@strarsis want to do the PR?

@strarsis
Copy link
Contributor Author

strarsis commented Jul 21, 2024

@swalkinshaw: Sure! The addition could require a check whether SSL/TLS is enabled, as nginx appears to need TLS/SSL for HTTP1.1 support when HTTP2 is enabled, the corresponding ticket was closed though: https://trac.nginx.org/nginx/ticket/808 (by https://trac.nginx.org/nginx/ticket/816).

So should http2 on only be added when ssl_enabled is enabled, which would reflect the current behavior - or is http2 to be enabled independently?

@retlehs
Copy link
Member

retlehs commented Jul 21, 2024

@strarsis
Copy link
Contributor Author

strarsis commented Jul 23, 2024

PR ready: #1529

@retlehs: Indeed, it appears that http3 can be just enabled out of the box for that nginx package.
As some may still be hesitant to enabling HTTP 3 support in nginx, the
option for HTTP 3 in that PR is turned off by default and can be turned on manually.

@swalkinshaw
Copy link
Member

Closed by #1528

Thanks!

@strarsis
Copy link
Contributor Author

strarsis commented Jul 25, 2024

🤔 Additionally to enabling HTTP/3 support in nginx, the firewall (besides a potential cloud/hardware firewall) also has to be configured to accept incoming UDP requests on port 443 for HTTP/3 (QUIC).
https://github.com/roots/trellis/blob/v1.22.1/group_vars/all/security.yml#L3

ferm_input_list:
[...]
  - type: dport_accept
    dport: [https]
    protocol: udp
    filename: nginx_accept_http3
[...]

Also HTTP/3/QUIC needs a service negotiation HTTP Header:
https://github.com/yurymuski/nginx-http3/blob/master/example.nginx.conf#L23

@swalkinshaw
Copy link
Member

@strarsis want to add those as well? 😄 I think the ferm rule can just be added unconditionally since https already is

@strarsis
Copy link
Contributor Author

strarsis commented Jul 29, 2024

@swalkinshaw:

can just be added unconditionally since https already is

(roles/ferm/tasks/main.yml)

For HTTPS:
(roles/ferm/defaults/main.yml):

sites_using_ssl: "[{% for name, site in wordpress_sites.items() | list if site.ssl.enabled %}'{{ name }}',{% endfor %}]"
- name: allow inbound HTTPS
  set_fact:
    ferm_input_list: "{{ ferm_input_list + [ ferm_dport_nginx_https] }}"
  when: sites_using_ssl | count
  vars:
    ferm_dport_nginx_https:
      type: dport_accept
      dport: [https]
      filename: nginx_accept_https

For HTTP/3 (QUIC):

- name: allow port UDP/443 for HTTP/3 (QUIC) support
  set_fact:
    ferm_input_list: "{{ ferm_input_list + [ ferm_dport_nginx_http3] }}"
  when: nginx_http3_enabled and (sites_using_ssl | count)
  vars:
    ferm_dport_nginx_http3:
      type: dport_accept
      dport: ['443']
      protocol: udp
      filename: nginx_accept_http3

(The https part would be removed then).

Is the potentially improved security worth the added complexity?

@swalkinshaw
Copy link
Member

That's not so bad I guess, good thinking. I'd be up for that 👍

@strarsis
Copy link
Contributor Author

strarsis commented Jul 29, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants