How to Implement SSL perfect forward secrecy Technology in NGINX website servers?

How to Implement SSL perfect forward secrecy Technology in NGINX website servers?

This article describes how to implement the Perfect Forward Secrecy (Perfect Forward Secrecy) and NGINX website server On Debian and Ubuntu systems. For other GNU/Linux systems, the entire process is slightly changed.

In short, perfect forward secrecy can ensure that "even if one piece of information is compromised, it will not drag other pieces of information into danger; it also ensures that no secret value will cause multiple messages to be compromised ." For more information, see http://en.wikipedia.org/wiki/forward_secrecy#perfect_forward_secrecy.

When the Heartbleed security vulnerability in openSSL was made public in early 2014, this fact becomes increasingly clear: for any system that uses SSL/TLS to a large extent, perfect forward secrecy is essential.

In case you want to compare your results with my results, can you in https://www.ssllabs.com/ssltest/analyze.html? D = indietorrent.org test my reference implementation method. The SSL certificate chain and the NGINX header sent can be viewed at the https://indietorrent.org.

In other words, you may wish to configure NGINX to implement perfect forward secrecy.

Go to the NGINX configuration directory first:

Cd/etc/nginx/

We need to generate the Diffie-Hellman parameter with sufficient security. Some people think that 4096 bits are too long to bring unnecessary burden to the system's processor, but it seems worth a try as far as computing power is concerned. For more information, see the "references" section below.

Openssl dhparam-out dh4096.pem 4096

If this configuration file is convenient, the file is dedicated to the tasks at hand and is divided into the include file. In this way, it is easier to implement perfect forward secrecy across a large number of systems.

Vi/etc/nginx/perfect-forward-secrecy.conf.

Paste the following content into the above file:

Ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Ssl_prefer_server_ciphers on;

Ssl_ciphers "EECDH + ECDSA + aesgcm eecdh + aRSA + aesgcm eecdh + ECDSA + SHA384 \

EECDH + ECDSA + SHA256 EECDH + aRSA + SHA384 EECDH + aRSA + SHA256 EECDH + aRSA + RC4 \

Eecdh edh + aRSA RC4! ANULL! ENULL! LOW! 3DES! MD5! EXP! PSK! SRP! DSS! MEDIUM ";

Ssl_dhparam dh4096.pem;

Modify the NGINX configuration to add the above files. Therefore, you only need to add the NGINX configuration at the end of the http {} code segment, insert the following line to the NGINX main configuration file (by default, the main configuration file is/etc/nginx. conf ):

# See: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

# This MUST come AFTER the lines that exist des.../sites-enabled/*, otherwise SSLv3 support may be re-enabled accidentally.

Include perfect-forward-secrecy.conf;

Restart NGINX to make the changes take effect:

Service nginx restart

If the test at https://www.ssllabs.com/ssltest/analyze.html shows the red Session resumption (caching) No (IDs assigned but not accepted), and the server implements the server name indication (SNI ), add the following content to the top-layer http {} code segment (that is, add to nginx. conf, as shown in the following figure ):

# See: http://forum.nginx.org/read.php? 2,152294, 152401 # msg-152401

Ssl_session_cache shared: SSL: 10 m;

Similarly, restart NGINX to make the changes take effect:

Service nginx restart

The above tests should no longer report this problem (although this problem does not reduce the overall test score ).

Further step: implement the HTTP strict Transmission Security (HSTS) protocol that lasts for a long time

This part is easy to implement. It is worth a try on the premise that:

1. For any host set for this header, You Want To forcibly require SSL to access all resources (that is, each webpage on the relevant website ).

2. You can endure SSL reminders that cannot accept or ignore any resources requested by any host set for this header, such as "Domain Name Mismatch. The nature of HSTS is that warnings and error conditions related to SSL certificates cannot be overwritten.

I searched online for information about whether setting this header may bring unnecessary impact to browsers that do not support the header. I found that the information was rejected. However, I was able to eliminate my concerns by testing this implementation method in a browser (such as IE 6). browsers that didn't implement HSTS completely ignore the header. Great!

Just add the following lines to the end of/etc/nginx/perfect-forward-secrecy.conf to save the changes:

Add_header Strict-Transport-Security "max-age = 31536000; includeSubDomains ";

# This will prevent certain click-jacking attacks, but will prevent

# Other sites from framing your site, so delete or modify as necessary!

Add_header X-Frame-Options SAMEORIGIN;

Reload (rather than restart) will force NGINX to adopt these special changes:

Service nginx reload

It can be confirmed that HSTS runs as expected, as long as it is verified at https://www.ssllabs.com/ssltest/analyze.html. If the HSTS has been correctly implemented, you should see a green box at the bottom of the score, showing "This server supports HTTP Strict Transport Security with long duration. grade set to A +. "indicates" the server supports HTTP strict Transmission security protocol for a long time. The score is set to A + ."

Congratulations!

Now you have one of the safest SSL/TLS implementation methods on the Internet.

References

Https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Address: http://www.howtoforge.com/ssl-perfect-forward-secrecy-in-nginx-webserver