Nginx Security Configuration about SSL in the server _nginx

This article shows you how to set stronger SSL on a Nginx Web server. We are implementing this method by weakening the crime attack by invalidating the SSL. Do not use the vulnerable SSLv3 in the protocol and the following version and we will set up a stronger cipher suite in order to be able to implement forward secrecy where possible, we also enable HSTs and HPKP. This allows us to have a stronger, outdated SSL configuration and we get a level in the Qually Labs SSL test.

We edited the following in the Nginx Setup document

Copy Code code as follows:

/etc/nginx/sited-enabled/yoursite.com (on Ubuntu/debian)

or in

Copy Code code as follows:

/etc/nginx/conf.d/nginx.conf (on Rhel/centos).

For the entire documentation, you need to edit the server-configured server block and port 443 (SSL configuration). At the end of the documentation, you will find the configuration of the sample implemented.

Make sure to make a backup before editing!

Beast attack and RC4 algorithm

In short, it is through the tamper encryption algorithm CBC cipher block encryption mode, some of the encrypted traffic can be secretly decrypted. For more information, please refer to the above link.

A new version of the browser client can mitigate bease attacks. It is recommended that you disable all TLS 1.0 passwords and only use RC4. However, [RC4 has an ever-increasing list to prevent attacks], and (http://www.isg.rhul.ac.uk/tls/) Many of them intersect theory with reality. And that's why the NSA has cracked the RC4, what they call a "major breakthrough".

Disabling RC4 has several results. First, users using the bad browser will use 3DES instead. 3-des is more secure than RC4. But it means more expensive. Your server will be more expensive for such users. Second, RC4 can alleviate beast attack. As a result, disabling RC4 makes TLS 1 users vulnerable to attack by moving their AES-CBC (the usual server-side beast "fix" is the priority for above all RC4). I'm pretty sure that the flaws in the RC4 on the beast are significantly greater than the risk. Indeed, client-side mitigation (provided by both Chrome and Firefox) is no longer a problem beast. But the risk of growth RC4: More password analysis will be superficial over time.

Freak attack

Freak is an intermediary attack found in Inria, Microsoft researchers and Imdea in the cryptography Expert Group. Freak is "factoring Rsa-export Keys." The attack dates back to the the 8990s, when the US government banned the sale of cryptographic software to overseas, unless the encryption key in the output cipher suite was no more than 512 bits in length.

Proven to be some advanced TLS clients-including Apple's securetransport and openssl-have a bug in it. This bug causes them to accept the output level of the RSA key even when the client does not require RSA's key output level. The impact of this bug is still quite serious: if the client is vulnerable and the server supports the output of RSA, it allows a third person to attack the quality of the connection through an active attacker.

This is the "RSA output level" attack that two parts of the server must accept.

The MITM attack has been as follows:

• In the hello message from the client, it requests a standard "RSA" cipher suite.
• MITM the attacker to change the message in order to get "RSA output."
• The server returns a 512-bit RSA output key and is signed with its permanent key.
• Because OpenSSL and securetransport have bugs, the client accepts the weak key.
• An attacker analyzes the RSA module in order to recover the RSA decryption key while the communication is in progress.
• When the client sends the encrypted "prep master key" to the server, the attacker can now decrypt it to get the "master key" of TLS.
• From now on, the attacker will be able to see the plaintext and inject anything he wants.

The password package is available on this page but it supports the password output level. Make sure your OpenSSL is a recently updated version and that your client also uses the latest software.

Heartbleed (Heart bleed)

Hearbleed is a security vulnerability found in the April 2014 OpenSSL cipher Library, which is widely used in the implementation of the Transport Layer (TLS) protocol. Heartbleed may be used regardless of whether or not a vulnerable OpenSSL is used, such as on a server or client. It is in the dtls Heartbeat extension (RFC6520) by improper input confirmation (because there is no boundary check), so the name of this vulnerability is "heartbeat". This vulnerability is zoned as a reread buffer, with more than the allowable data being read.

Which versions of OpenSSL are affected by Heartbleed?

Different versions of the situation:

• OpenSSL 1.0.1 to 1.0.1f (including) is under attack.
• OpenSSL 1.0.1g is not under attack.
• OpenSSL 1.0.0 's branch is not vulnerable.
• OpenSSL 0.9.8 's branch is not vulnerable.

OpenSSL discovered the loophole in December 2011 and did not take any action until the OpenSSL1.0.1 was released on March 14, 2012. The openssl1.0.1g, released April 7, 2014, fixes the vulnerability.

By updating the OpenSSL, you can protect yourself from this vulnerability.

SSL compression (criminal attack)

In general, a criminal attack uses SSL compression to perform its magic. SSL compression is turned off by default in nginx1.1.6+/1.0.9+ (if you are using OpenSSL 1.0.0+).

If you are using Nginx or OpenSSL other earlier versions, and your distribution does not fetch this option, you will need to recompile OpenSSL that does not support ZLIB. This will prohibit the use of the deflate compression method to use OpenSSL. If you do this, then you can still use regular HTML deflate compression.
SSLV2 and SSLv3

SSL v2 is not secure, so we need to disable it. We can also disable SSL v3, when TLS 1.0 suffers a downgrade attack, you can allow an attacker to force the use of SSL V3 to connect, thus disabling "forward secrecy".

Edit this configuration file again:

Ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Poodle Attack and Tls-fallback-scsv

SSLv3 allows the use of the "poodle poodle" vulnerability, which is a major reason for disabling it. Google has proposed an expansion of a ssl/tls called tlsfallbackscsv, designed to prevent the imposition of SSL demotion. The following are the OpenSSL versions that are automatically enabled after the upgrade:

• OpenSSL 1.0.1 has a version of Tlsfallbackscsv in 1.0.1j and higher.
• OpenSSL 1.0.0 has a version of Tlsfallbackscsv in 1.0.0o and higher.
• OpenSSL 0.9.8 has a version of Tlsfallbackscsv in 0.9.8zc and higher.

For more information, see the Nginx documentation
Password Kits

Forward secrecy ensures the integrity of the session key in the event that the permanent key is compromised. PFS implementations are done by performing a new key that infers each session.

This means that when the private key is compromised, it cannot be used to decrypt the SSL traffic record.

The cipher suite provides Perfect Forward secrecy temporarily using the Diffie-hellman key Exchange form. Their disadvantage is that the overhead is large, which can be improved by using variations of the elliptic curve.

I recommend the following two cipher kits, which come from the Mozilla Foundation.

Recommended Password kits:

Copy Code code as follows:

Ssl_ciphers ' Aes128+eecdh:aes128+edh ';

Recommended Password Suite backward compatibility (IE6/WINXP):

Copy Code code as follows:

Ssl_ciphers "Ecdhe-rsa-aes256-gcm-sha384:ecdhe-rsa-aes128-gcm-sha256:dhe-rsa-aes256-gcm-sha384:d He-rsa-aes128-gcm-sha256:ecdhe-rsa-aes256-sha384:ecdhe-rsa-aes128-sha256:ecdhe-rsa-aes256-sha: Ecdhe-rsa-aes128-sha:dhe-rsa-aes256-sha256:dhe-rsa-aes128-sha256:dhe-rsa-aes256-sha:dhe-rsa-aes128-sha: ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256: aes256-sha:aes128-sha:des-cbc3-sha:high:!anull:!enull:! export:! Des:! md5:! Psk:! RC4 ";

If your OpenSSL is an older version, a password that is not available will be discarded automatically. Always use the full cipher suite to let OpenSSL choose what it supports.

The order of the cipher suite is important because it determines that the priority algorithm will be selected. The above recommendation attaches importance to the algorithm providing perfect forward secrecy.

Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ecdhe are quite near, rather than appearing in most versions of Ubuntu OpenSSL incidental or RHEL.

Precedence logic

• First select Ecdhe + aesgcm password. These are TLS 1.2 passwords and are not widely supported. These passwords do not currently have a known attack target.
• PFS cipher kits are preferred, ecdhe first, and then DHE.
• AES 128 wins AES 256. There is a discussion of whether AES256 additional security is worth the cost, and the result is far from obvious. At present, AES128 is preferred because it provides good security and seems to be really fast and more resistant to timing attacks.
• Backward-compatible cipher suite, AES priority 3DES. The violent attack AES is difficult to realize in the TLS1.1 and above, the alleviation and the TLS1.0. Backward incompatible cipher suite, 3DES does not exist.
• RC4 is completely removed. 3DES for backward compatibility.

Mandatory Discard

• Anull contains an unauthenticated Diffie-hellman key exchange, which is attacked by intermediaries
• Enull contains unencrypted password (plaintext)
• EXPORT is marked by U.S. law as a legacy weak password
• RC4 contains a password, using an obsolete arcfour algorithm
• DES contains passwords, using deprecated data encryption standards
• SSLV2 contains all passwords, defines the SSL standard in the previous version, and now discards
• MD5 contains all the passwords and uses the obsolete message Digest 5 as the hashing algorithm

Other Settings

Make sure you have added the following lines:

Copy Code code as follows:

Ssl_prefer_server_ciphers on;
Ssl_session_cache shared:ssl:10m;

Select a password when SSLv3 or this is the TLSv1 handshake, usually using the client's preferences. If this instruction is enabled, then the server prefers to use the server.

For more information about SSL preferserver passwords

More information about the SSL password
forward secrecy (Forward secrecy) and Diffie Hellman ephemeral Parameters

The concept of forward secrecy is simple: the client and server negotiate a reliable key and destroy it at the end of the session. The RSA private key in the server is used to sign the Diffie-hellman key exchanged between the client and the server. The secondary master key is obtained from the Diffie-hellman handshake and is used for encryption. Because the secondary master key is explicitly specific in the connection between the client and the server, and is used for a limited time, it is called ephemeral (ephemeral).

Because of the forward secrecy, even if an attacker holds the private key of the server, it is not possible to decrypt past sessions. The private key is used only to sign a DH (diffie-hellman) handshake, and it does not disclose the secondary master key. Diffie-hellman ensures that the secondary master key does not leave the client and server and is not intercepted by the middleman.

1.4.4 all Nginx versions rely on OpenSSL when entering parameters to Diffiel-hellman. Unfortunately, this means that ephemeral Diffiel-hellman (DHE) will use the OpenSSL flaw, including a 1024-bit exchange key. Because we are using a 2048-bit certificate, the Dhe client will use a weaker key exchange than a ephemeral client.

We need to produce a stronger dhe parameter:
Cd/etc/ssl/certs
OpenSSL dhparam-out Dhparam.pem 4096

Then tell Nginx to use it in the Dhe key exchange:

Copy Code code as follows:

SSL_DHPARAM/ETC/SSL/CERTS/DHPARAM.PEM;

OCSP Apply

When connecting to the server, the client verifies the validity of the server certificate by using a certificate revocation list (CRL) or uses an online certificate status Protocol (OCSP) record. However, the problem with CRLs is that the list items of CRLs are increasing and need to be downloaded continuously.

OCSP is more lightweight because it only gets one record at a time. The side effect, however, is that when you connect to the server, OCSP requests must be sent to a third party responder, which increases latency and the likelihood of failure. In fact, OCSP responders are manipulated by the CA, which is often unreliable, causing the browser to fail due to a timely response. This reduces security because it allows an attacker to perform Dos attacks on OCSP respondents to cancel authentication.

The solution is to allow the server to send cached OCSP records during the TLS handshake, bypassing the OCSP responder. This technology saves a round-trip between the client and the OCSP responder, known as OCSP closure (OCSP stapling).

The server sends a cached OCSP response only at the request of the client, declaring support through the Status_request TLS extension of client hello.

Most servers will cache OCSP responses to 48 hours. At regular intervals, the server connects to the OCSP responder of the CA to obtain the latest OCSP records. The location of OCSP respondents is obtained from the Authority Information Access field of the signing certificate.

HTTP Strict Transport Security

If possible, you should open the HTTP Strict Transport Security (HSTs), which instructs the browser to access your site only through HTTPS.

HTTP Public Key Pinning Extension

You should also open HTTP public Key pinning Extension.

Public key pinning means that the certificate chain must contain a key that is in the whitelist. It ensures that only CAs in the whitelist can sign *.example.com, not any one of the CAs saved in the browser.

I've written an article about it, including background theory and configuration examples for Apache, LIGHTTPD, and Nginx:https://raymii.org/s/articles/httppublickeypinningextension _hpkp.html
Configuration Example

Copy Code code as follows:

server {

Listen [::]:443 default_server;

SSL on;
SSL_CERTIFICATE_KEY/ETC/SSL/CERT/RAYMII_ORG.PEM;
SSL_CERTIFICATE/ETC/SSL/CERT/CA-BUNDLE.PEM;

Ssl_ciphers ' Aes128+eecdh:aes128+edh:!anull ';

Ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Ssl_session_cache shared:ssl:10m;

Ssl_stapling on;
Ssl_stapling_verify on;
Resolver 8.8.4.4 8.8.8.8 valid=300s;
Resolver_timeout 10s;

Ssl_prefer_server_ciphers on;
SSL_DHPARAM/ETC/SSL/CERTS/DHPARAM.PEM;

Add_header strict-transport-security max-age=63072000;
Add_header x-frame-options DENY;
Add_header x-content-type-options Nosniff;

root/var/www/;
Index index.html index.htm;
server_name raymii.org;

}

Conclusions

If you apply the above configuration file, you need to reboot the Nginx:

Copy Code code as follows:

# Check the config:
/etc/init.d/nginx Configtest
# Then Restart:
/etc/init.d/nginx restart

Now use the SSL lab test (SSL Labs tes) to see if you get a nice a. At the same time, of course, have a secure, reliable, as a future example of the SSL configuration.