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/ (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 (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?
Thanks for bringing this up. I noticed it also on: https://hstspreload.org (https://hstspreload.org)
getting:
QuoteThe HTTP page at http://domain.com sends an HSTS header. This has no effect over HTTP, and should be removed.
Quote from: psychofaktory on February 14, 2022, 08:01:15 PM
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/ (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 (https://datatracker.ietf.org/doc/html/rfc6797)
Quote from: psychofaktory on February 14, 2022, 08:01:15 PM
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 (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 (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.
Quote from: psychofaktory on February 14, 2022, 08:01:15 PM
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.
Thanks for your feedback
Quote from: fabian on February 14, 2022, 10:45:01 PM
I don't see that it is forbidden by the RFC: https://datatracker.ietf.org/doc/html/rfc6797 (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 (https://datatracker.ietf.org/doc/html/rfc6797#section-7.2)
QuoteAn HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
Quote from: fabian on February 14, 2022, 10:45:01 PM
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.
Hi
Quoterestructuring 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
QuoteHowever, 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)
Quoteadd-on module "nginx-headers-more"
yeah, it would be great!
Quote from: Fright on February 15, 2022, 12:26:58 PM
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?
what if you allow x25519 curve?
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?
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)
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.
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
yes, that's what I did.
QuoteTest 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?
@psychofaktory
sorry, too much "inside things" + custom templates :-[
will try to generate something "generic" on 22.1 test vm tomorrow
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.
QuoteOnly 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
Quoteremaining 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
Quotehich 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
Quote from: Fright on February 16, 2022, 06:36:15 AM
can't confirm. a change in any parameter in the settings of a specific server is immediately reflected in the ssllabs report.
I think I have been able to find out the cause.
I have set a server as "Default". TLS version and ECDH curves are always taken from this one. No matter what is set on other servers.
If I uncheck the "Default Server" the individual settings are active.
Quote from: Fright on February 16, 2022, 06:36:15 AM
-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
Thank you! That worked perfectly!
Quote from: Fright on February 16, 2022, 06:36:15 AM
only asking devs for adding "headers-more" support to the package imho
But didn't Fabian mean the module would be ready to be compiled and usable?
QuoteTLS version and ECDH curves are always taken from this one.
that's odd. any chance that the name of the checked host on ssllabs did not match the server name in the config? (and therefore the default site used by nginx)
will try to test this
QuoteThank you! That worked perfectly!
cool! )
QuoteBut didn't Fabian mean the module would be ready to be compiled and usable?
let's hope that
@fabian will comment, but I did not notice it as a module or a dynamic module (
Quote from: Fright on February 16, 2022, 09:35:01 AM
that's odd. any chance that the name of the checked host on ssllabs did not match the server name in the config?
No, I tested it with multiple hostnames and servers.
The hostname I tested was always the server where I changed the curves.
Maybe it plays a role that the server I had set as default and from which the curves were taken had a domain name as hostname and the servers where the curves were not taken were subdomains of it.
@psychofaktory
sorry for delay
QuoteTLS version and ECDH curves are always taken from this one
thanks for raising this question. did not pay attention before (use uniform parameters for published services)
it seems that everything is as you noticed. and an explanation for this - OpenSSL library.
https://mailman.nginx.org/pipermail/nginx/2014-November/045738.html
https://trac.nginx.org/nginx/ticket/676
so the only option imho is to make the server with the least restrictive settings the default server, and further restrict TLS params with the "ssl_ciphers" directive on individual servers (worked for me on test vm)
Looks like it is missing:
https://github.com/opnsense/tools/blob/master/config/22.1/make.conf#L99
Should contain this value:
HEADERS_MORE
@fabian
like a charm, thanks!
hope @franco doesn't mind adding this
will try to fr
Sure, why not.
Cheers,
Franco
yippee!
You guys make me happy ;D