Hi,

What is the purpose of the HTTPS Redirection block starting on line 23 in nginx.conf?
Can we do without it?

Option 1: Use the dsaparam flag on generation.

The reasonable solution would be to add the -dsaparam option.

openssl dhparam -dsaparam -out /etc/ssl/private/dhparam.pem 4096

This option instructs OpenSSL to produce "DSA-like" DH parameters (p is such that p-1 is a multiple of a smaller prime q, and the generator has multiplicative order q). This is considerably faster because it does not need to nest the primality tests, and thus only thousands, not millions, of candidates will be generated and tested.

As far as academics know, DSA-like parameters for DH are equally secure; there is no actual advantage to using "strong primes" (the terminology is traditional and does not actually imply some extra strength).

Similarly, you may also use a 2048-bit modulus, which is already very far into the "cannot break it zone". The 4096-bit modulus will make DH computations slower (which is not a real problem for a VPN; these occur only at the start of the connection), but won't actually improve security.

To some extent, a 4096-bit modulus may woo auditors, but auditors are unlikely to be much impressed by a Raspberry-Pi, which is way too cheap anyway.

Source

Option 2. Use a service

curl https://2ton.com.au/dhparam/4096

Option 3. Install a randomness generator like rng-tools

See https://www.cyberciti.biz/open-source/debian-ubuntu-centos-linux-setup-additional-entropy-for-server-using-aveged-rng-tools-utils/

Expected behavior

Nginx does not publicly report its version.

Actual behavior

Nginx publicly reports its version.

Steps to reproduce the behavior

1. Request anything from an Nginx installation configured with Bubbly.
2. Check header "Server"

As Google is abandoning HPKP in favour of the Expect-CT header, we should implement that instead.

• https://www.theregister.co.uk/2017/10/30/google_hpkp/

This makes things much easier, as it works like CSP but for Certificate Transparency. No more hashing certificates and updating a file.

Expect-CT: max-age=0, report-uri="https://scotthelme.report-uri.io/r/default/ct/reportOnly"
Expect-CT: enforce,max-age=30,report-uri="https://scotthelme.report-uri.io/r/default/ct/enforce"

• https://scotthelme.co.uk/a-new-security-header-expect-ct/

• Add option with default socket location
• Are 7.0/7.1 still supported? If not, remove them as options.

Roadmap

• Generate hashes when the keys are updated.
• Replace hashes for automatic HPKP configuration in nginx-config/directive/bubbly_hpkp.conf
• Default to report only for safety, with documented options and warnings in-configuration.
• Secondary option with short life, due to short certificate life.
• Add documentation to README.md

References

• https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning
• https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning
• https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
• https://tools.ietf.org/html/rfc7469

Is your feature request related to a problem? Please describe.
Currently, no Feature-Policy is specified.

Describe the solution you'd like
Specify Feature-Policy in an allow-nothing state.

Additional context
No current options w3c/webappsec-permissions-policy#189

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

See https://scotthelme.co.uk/a-new-security-header-referrer-policy/

Expected behavior

There should be a CONTRIBUTING.md file within .github.

Actual behavior

There is not.

• Add a CONTRIBUTING.md file.
• Contributing Description
• Making Changes
• Filing an Issue
• Creating a Pull Request
• Current State
• Document Cipher Sources
• Document Headers
• Document contact points

https://github.com/h5bp/server-configs-nginx

Hello,
$ nginx -v
nginx version: nginx/1.15.12

$ nginx -V

built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4)
built with OpenSSL 1.0.2q  20 Nov 2018
TLS SNI support enabled
configure arguments: --add-module=../ngx_cache_purge --add-module=../nginx-rtmp-module --with-http_stub_status_module --with-http_ssl_module --sbin-path=/usr/sbin/nginx --lock-path=/var/run/nginx.lock --conf-path=/etc/nginx/nginx.conf --pid-path=/run/nginx.pid --with-pcre=../pcre-8.4* --with-zlib=../zlib-1.2.11 --with-openssl=../openssl-1.0.2q --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --user=nginx --group=nginx --with-http_auth_request_module --with-http_degradation_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_v2_module --with-stream_ssl_module --with-stream --with-threads --prefix=/etc/nginx

$ sudo nginx -t && sudo service nginx reload

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] zero size shared memory zone "servers"
nginx: configuration file /etc/nginx/nginx.conf test failed

PS: I do not see sites-enabled directory under /etc/nginx
Could you please let me know what I missed?

Thank you
Bombolini

This has been an outstanding resource. Thank you!

The nginx configuration seems to break down after one domain instance per server, though. For example, the configuration works (mostly) out of the box for domain.com. (I swapped SPDY for HTTP/2 and added WebSockets support, but that's it.)

If I apply the same procedure with blog.domain.com (with a different Let's Encrypt certificate, obviously) and run them simultaneously, I get this nginx alert:

 * Restarting nginx nginx
nginx: [emerg] duplicate listen options for [::]:80 in /etc/nginx/conf.d/wordpress.conf:3

What would you recommend to permit n servers with n certificates to run simultaneously and independently on SSL/{SPDY|HTTP2}?

Can renewals be done with certbot renew?

Seems like that would remove the need to edit the crontab file before importing it and just work for whatever setup you did manually the first time.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

We should have a small example site that shows off bubbly, maybe with some docs and screenshots of our A+ ratings on https://www.ssllabs.com/ssltest/ as well as https://securityheaders.io

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

The nginx configuration in this repo isn't valid when loaded into my copy of nginx (Ubuntu 14.04, v1.9.7). It complains:

nginx: [emerg] duplicate listen options for [::]:443 in /etc/nginx/conf.d/diplio.conf:21

I'm mostly an nginx n00b still, but at first glance I would agree with it: the second server block clashes with the third. Commenting out the second block works, and pages are served as expected.

(To be clear, this is with one server environment, unlike ticket #2.)

nginx: [emerg] invalid parameter "http2" in /etc/nginx/sites-enabled/nginx.conf:25
nginx: configuration file /etc/nginx/nginx.conf test failed

I do not support http2, so I disabled it

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

Then I got error

nginx: [emerg] unknown directive "ssl_session_tickets" in /etc/nginx/sites-enabled/nginx.conf:51

I also disabled them. Then got

# nginx -t
nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/%MYSITE%/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/%MYSITE%/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed

# nginx -v
nginx version: nginx/1.4.6 (Ubuntu)
# uname -a
Linux ubuntu-512mb-ams2-01-arendude 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux