Various suggestions for improvement of Nginx

[psychofaktory]

Hello,

after setting up my web services via the nginx plugin as a reverse proxy, I examined them with various test tools.

Hardenzie.com states:
"Policy set on plaintext port: HSTS policies must not be transmitted over insecure channels."

I am aware that this does not cause any harm.
But restructuring nginx.conf could eliminate that:
https://codefaq.org/server/how-to-fix-warning-unnecessary-hsts-header-over-http-in-htstpreload-org/

Securityheaders.com states:
"server: This server header seems to advertise the software being run on the server but you can remove or change this value."

This could be changed via the add-on module "nginx-headers-more".
But this module would have to be compiled in:
https://serverfault.com/questions/214242/can-i-hide-all-server-os-info


Would it also be possible to implement HTTP/3, QUIC and CORS header support?

[RamSense]

Thanks for bringing this up. I noticed it also on: https://hstspreload.org
getting:

The HTTP page at http://domain.com sends an HSTS header. This has no effect over HTTP, and should be removed.

[fabian]

after setting up my web services via the nginx plugin as a reverse proxy, I examined them with various test tools.

Hardenzie.com states:
"Policy set on plaintext port: HSTS policies must not be transmitted over insecure channels."

I am aware that this does not cause any harm.
But restructuring nginx.conf could eliminate that:
https://codefaq.org/server/how-to-fix-warning-unnecessary-hsts-header-over-http-in-htstpreload-org/

I don't see that it is forbidden by the RFC: https://datatracker.ietf.org/doc/html/rfc6797

Securityheaders.com states:
"server: This server header seems to advertise the software being run on the server but you can remove or change this value."

This could be changed via the add-on module "nginx-headers-more".
But this module would have to be compiled in:
https://serverfault.com/questions/214242/can-i-hide-all-server-os-info

First of all, the module is actually compiled in and usable.
Second: The Server header is defined as follows by the RFC.
https://datatracker.ietf.org/doc/html/rfc2616#section-14.38
It is set to expose almost no backend (just that it is an nginx but no version, OS etc.) information and stripping the server header does not bring a lot unless also the headers are shuffled as you can fingerprint the web servers.

Would it also be possible to implement HTTP/3, QUIC and CORS header support?

CORS headers would be probably possible (if someone wants to implement it), but QUIC does not work as nginx does not support it itself as far as I know right now. This will likely come in the future.

[psychofaktory]

Thanks for your feedback

I don't see that it is forbidden by the RFC: https://datatracker.ietf.org/doc/html/rfc6797

At least, this is how point 7.2 could be understood:
https://datatracker.ietf.org/doc/html/rfc6797#section-7.2

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

First of all, the module is actually compiled in and usable.

How can I hide the server name with that module?
If I set "more_clear_headers Server;" in b205a06b-f3ea-4e6c-b68c-8a28f153f19b_post/*.conf, the Global Error Log says: "unknown directive "more_clear_headers" in /usr/local/etc/nginx/b205a06b-f3ea-4e6c-b68c-8a28f153f19b_post/settings.conf:5"

Regarding 0-RTT:
I have Zero-RTT enabled in the HTTP server settings.
the parameters "ssl_early_data on;" and "proxy_set_header Early-Data $ssl_early_data;" are also set in nginx.conf.
However, the feature still does not seem to be active.
At least that's what SSLlabs.com and sslyze says.

[Fright]

Hi

restructuring nginx.conf could eliminate that

imho add_header directive is already placed in the server block.
so if it seems that the warning is so important, then all that remains to be done is not to listen on plain http port

However, the feature still does not seem to be active.
At least that's what SSLlabs.com and sslyze says.

works for me. Might be worth checking other settings (TLS ver, ciphers list, ecdh curve)

add-on module "nginx-headers-more"

yeah, it would be great!

[psychofaktory]

Might be worth checking other settings (TLS ver, ciphers list, ecdh curve)

• TLS Protocols: TLSv1.2, TLSv1.3
• TLS ciphers: ECDHE-PSK-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384
• ECDH curves: secp521r1:secp384r1

Is there anything wrong?

[Fright]

what if you allow x25519 curve?

[psychofaktory]

OK, that's strange.
I have now set the ECDH curves to "X25519:secp521r1:secp384r1:prime256v1", saved the configuration and restarted the nginx service.
However, all test tools still show only "secp521r1:secp384r1" as used.
In the nginx.conf the changes were accepted.

I then changed the TLS ciphers for testing, saved again and restarted the service. This change was recognized by the test tools.
For testing I also deactivated TLSv1.2, so that only TLSv1.3 is active.
This was also applied in the nginx.conf after the change, but the test tools (tls.imirhil.fr, ssllabs.com, sslyze) still reported TLSv1.2 as active.

How can this come about?

[Fright]

sorry, don't know what to guess. for me, ssllabs immediately reacts to any changes in the nginx config (of course, clear the cache first)

[psychofaktory]

I don't think cache is here the problem.

I testet this with serveral tools and browsers. Even some that I had never used before.
The other adjustments, such as the change of the ciphers, were immediately recognized during the next test.

[Fright]

not the browser cache, sites results cache (like "clear cache" link on ssllabs page to the right of the asessed time mark). tested with TLS1.2 remove/add and cipher suits

[psychofaktory]

yes, that's what I did.

Test Time: Tue, 15 Feb 2022 15:41:17 UTC

Right after the adjustments

@Fright
Can you send me your config, so I can test it with my web services?

[Fright]

@psychofaktory
sorry, too much "inside things" + custom templates  :-[
will try to generate something "generic" on 22.1 test vm tomorrow

[psychofaktory]

OK, it seems I was able to find the error with 0-RTT and fix it for me.

The settings for 0-RTT were correct so far. But the set ECDH curves became active only when I enabled them for all web services.
Only for one web service alone it did not work.
Is this a bug?


Now the remaining questions are if the nginx.conf could be restructured in a way that the HSTS policies are not transferred via http, and which parameters should be set so that the server name is not included in the header.

[Fright]

Only for one web service alone it did not work.
Is this a bug?

can't confirm. a change in any parameter in the settings of a specific server is immediately reflected in the ssllabs report. obviously you are doing something wrong

remaining questions are if the nginx.conf could be restructured in a way that the HSTS policies are not transferred via http

nginx.conf is absolutely correct imho (and hstspreload.org message is a warning, not an error). if you need to get rid of hsts header in plain http you can:
-dont bind to plain http at all (just leave "HTTP Listen Address" empty).
-(optionaly) add separate http server w/o hsts header (and listen :80 only) that redirects http to https

hich parameters should be set so that the server name is not included in the header.

only asking devs for adding "headers-more" support to the package imho