English: Netguru, translation: Open Source Chinese translation
www.oschina.net/translate/nginx-tutorial-ssl-setup
Everybody is good! Sharing is caring, and we are happy to share some other knowledge with you. We have prepared a guide to Nginx, divided into three series. This is great if you already know something about Nginx or want to expand your experience and knowledge.
We will tell you how Nginx works, the concepts behind it, and how to tune Nginx to improve application performance
We hope that, first, as a reference book, we can quickly find solutions to related problems (such as GZIP compression, SSL, etc.), and directly read the full text. For better learning purposes, we recommend that you install Nginx on your native machine and try it out.
The SSL and TLS
SSL (short for Socket Secure Layer) is a protocol that provides Secure connections over HTTP.
SSL 1.0 was developed by Netscape but was never publicly released due to serious security vulnerabilities. SSL 2.0 was released in 1995, and it had some problems that led to the final RELEASE of SSL 3.0 in 1996.
The first version of TLS (short for Transport Layer Security) was written as an upgrade to SSL 3.0. Then TLS 1.1 and 1.2 came out. Now, shortly after, TLS 1.3 is coming out (which is really worth looking forward to) and is already supported by some browsers.
Technically, SSL and TLS are different (because each protocol describes a different version of the protocol), but many of the names used are interchangeable.
Basic SSL/TLS configuration
To handle HTTPS traffic, you need an SSL/TLS certificate. You can generate a free certificate by using Let’s Encrypt.
Once you have the certificate, you can easily switch to HTTPS by:
-
Start listening on port 443 (the default port the browser will use when you type https://sample.co)
-
Provide the certificate and its key
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/nginx/ssl/netguru.crt;
ssl_certificate_key /etc/nginx/ssl/netguru.key;
}
We also want to adjust the configuration to:
-
Only TLS is used. Due to a well-known vulnerability, all SSL versions will no longer be used
-
Use pre-defined secure server passwords (similar to protocol situations – these days only a few passwords are considered secure)
Keep in mind that the above Settings are always changing. It’s a good idea to refresh from time to time.
Ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH CHACHA20:EECDH AES128:RSA AES128:EECDH AES256:RSA AES256:! MD5;
ssl_prefer_server_ciphers on;
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/nginx/ssl/netguru.crt;
ssl_certificate_key /etc/nginx/ssl/netguru.key;
}
TLS Session Recovery
To use HTTPS, you need to add a TLS handshake on top of TCP. This significantly increased the time it took for actual data to be transferred. Suppose you request /image.jpg from Warsaw and plug into the nearest server in Berlin:
To save one Roundtrip time during a TLS handshake, as well as the computational overhead of generating a new key, we can reuse the session parameters generated during the first request. The client and server can store session parameters after the session ID key. During the subsequent TLS handshake, the client can send the session ID, and if the server still has the correct entry in the cache, the parameters generated by the previous session are reused.
server {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
}
OCSP Stapling
SSL certificates can be revoked at any time. To know if a given Certificate is no longer valid, the browser needs to perform additional queries through the Online Certificate Status Protocol (OCSP). Instead of the user performing the specified OCSP query, we can do this on the server, cache its results, and provide the OCSP response to the client during the TLS handshake. It is called OCSP Stapling.
server {
ssl_stapling on;
ssl_stapling_verify on; # verify OCSP response
ssl_trusted_certificate /etc/nginx/ssl/lemonfrog.pem; # tell nginx location of all intermediate certificates
Resolver 8.8.8.8 8.8.4.4 valid = 86400 s; # resolution of the OCSP responder hostname
resolver_timeout 5s;
}
Security headers
There are some headers that are really worth adjusting to provide greater security. For more information about headers and their details, you should definitely check out the OWASP project’s Security headers.
HTTP Strict-Transport-Security
Or HSTS for short, forces the user agent to use HTTPS when sending requests to the source.
add_header Strict-Transport-Security “max-age=31536000; includeSubdomains; preload”;
X-Frame-Options
Indicates whether the browser needs to render the page in a frame, an iframe, or an object label.
add_header X-Frame-Options DENY;
X-Content-Type-Options
This option prevents the browser from sniffing the file when determining the file type. The file will be translated in the format declared in the Content-Type header.
add_header X-Content-Type-Options nosniff;
Server tokens
Another good practice is to hide information about the Web server in the HTTP response header field:
Server: nginx / 1.13.2
This can be done by disabling the server_tokens directive:
server_tokens off;
Appendix :: Let’s Encrypt
The installation
The latest installation package can be found here.
Rate limits are not excluded for testing using a staging environment.
Generating a new certificate
certbot certonly –webroot –webroot-path /var/www/netguru/current/public/
-d foo.netguru.co
-d bar.netguru.co
Make sure you update correctly.
certbot renew –dry-run
Make sure you add automatic updates to crontab. Run crontab -e and add the following line
3 * * * /usr/bin/certbot renew –quiet –renew-hook “/usr/sbin/nginx -s reload”
Check that SSL is working properly with SSLLabs.
If there are any improper articles, please correct them. You can also follow my wechat official account: Learn Java well and get high-quality video tutorial resources.