Nginx Configuration

What is Nginx?

Nginx is a HTTP and reverse proxy server. It acts as a layer between the internet and our web apps, which run in Tomcat. In other words Guacamole runs within Tomcat and Nginx acts as a middle man to communicate information between the outside world (the internet) and Tomcat/Guacamole. Its responsible for enforcing HTTPS/SSL, changing the URL of the Guacamole website, security and more.

Goals of Nginx in the Guacamole Install script

One of my main goals with the script is security. As such, I measure the available configurations of Nginx within the script based on the potential in the Qualys SSL Test. I say potential as user choices during the prompts offered by the script can impact the possible score and level of security.

My aim is for all configurations to be capable of an A+ overall score and 90% or greater in each of the four categories graded. Be aware that scores and grades are not always the most important consideration. I simply use them as a means to measure and compare settings. Other considerations like compatibility and performance may be a factor in deciding what settings to ultimately use. To find out more about how Qualys determines scores see their SSL Server Rating Guide

Configuration Details

The script creates 2 Nginx configuration files. This makes it easier to see what settings apply to HTTP and which apply to HTTPS.

• /etc/nginx/conf.d/guacamole.conf
• /etc/nginx/conf.d/guacamole_ssl.conf

Any changes made to these files after the script completes will require restarting the nginx service using systemctl restart nginx

Nginx Configuration Options

The Apache Guacamole install script has two (2) levels of security, the default and a more secure one which uses only the strongest, greater or equal to 256 bit ciphers. Before discussing the differences, lets first look at the Nginx settings common to all choices.

Nginx Default Options (used by the script)

• Redirect to HTTPS. This is done via the return 301 line in guacamole.conf
• server_tokens off. Turning this off prevents displaying the Nginx version on error pages and in the "Server" response header field. Details on server_tokens
• ssl_protocols TLS1.3 TLS1.2. This forces using only TLS 1.3 or 1.2 to connect, in prefered order. TLS1 1.3 is a placeholder as the versions of Nginx and openSSL in RHEL/CentOS 7.x do not yet support TLS 1.3.
• ssl_ecdh_curve secp521r1:secp384r1:prime256v1. The curves to use with ECDHE ciphers in preferred order.
• ssl_prefer_server_ciphers on. This forces clients to use ciphers they are capable of using in the order provided by the server.
• ssl_session_tickets off. Disables session resumption via TLS session tickets.
• add_header Referrer-Policy \"no-referrer\";. specifies that no referrer information is to be sent along with requests made from a particular request client to any origin. The header will be omitted entirely.
• add_header Strict-Transport-Security \"max-age=15768000; includeSubDomains\" always;. Configures HSTS to avoid SSL stripping.
• add_header X-Frame-Options \"SAMEORIGIN\" always;. Prevents the site from being displayed in a frame or iframe unless the origin is the same as the page itself.
• add_header X-Content-Type-Options \"nosniff\" always;. Helps protect against MIME sniffing vulnerabilities.
• add_header X-XSS-Protection \"1; mode=block\" always;. This header enables the Cross-site scripting (XSS) filter built into most recent web browsers
• access_log and error_log are set so that Nginx can keep logs that can help with troubleshooting or audits.

Nginx Cipher Settings

There is a prompt when running the script to "Use only >= 256-bit SSL ciphers...". The default response is "no". When "no" is selected, the following ciphers are used by Nginx:

ssl_ciphers 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256'

These ciphers are all strong and secure at the time of this writing, despite including some 128-bit ciphers. Using these ciphers will result in a good balance of security and compatibility allowing for an A+ overall but a maximum score of 90% in Qualys's SSL Test for cipher strength.

When "yes" is chosen for the prompt, the following ciphers are used by Nginx:

ssl_ciphers 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384'

These ciphers are all 256-bit or higher and are at the time of this writing the most secure ciphers available in our setup. Using these ciphers will result in the maximum security but will reduce compatibility with older OS's and browsers. Using these will allow for an A+ with a 100% score for cipher strength on the Qualys SSL Test.

Note: Be aware that ciphers are/should be in order of preference. I have tried to place them in order of security. Some may decide to place them in order of performance, compatibility or other considerations.

Other Options that Impact Security

There are a few other options made when running the script that impact overall security and the potential score on Qualys's SSL Test.

First, I need to point out that Qualys scores are only possible when using a public domain.

These are the options that can further impact security and scoring:

• Let's Encrypt key-size. The default of 4096 bits should be very secure and will be capable of 100% key exchange score in testing. A 2048 bit setting will also be secure in most use cases and will be capable of a 90% key exchange score. I do not recommend lower than 2048 bit and have not tested higher than 4096 bit.
• "Use OCSP Stapling" in the Let's Encrypt menu of the script. When set to "yes", increases overall security and seems to impact the scoring of the test (however I am not sure how). This setting adds the required lines to the guacamole_ssl.conf file to use OCSP Stapling and the parameter --must-staple to the certbot command so that the certificate enforces OCSP stapling. I would recommend using this unless you have a specific reason not to.