nginx security logging tls ssl – Log Used SSL/TLS Protocol and Ciphersuite in nginx

loggingnginxSecurityssltls

My goal is to ensure proper security for clients connecting to my nginx. I'm following Mozilla's guide to configure TLS properly on my nginx installation, but I don't have an overview of the actual protocols/ciphersuites being used in practice.

What I have now:

server {
    listen 443;
    ssl on;
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_dhparam /path/to/dhparam.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'the_long_ciphersuite_listed_there';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:50m;
}

With this, I'd like to log which SSL protocol was used for a connection and what ciphersuite was chosen after the client/server negotiated. E.g.:

10.1.2.3 - - [13/Aug/2014:12:34:56 +0200] "GET / HTTP/1.1" 200 1234 "-" "User agent bla"

10.1.2.3 - - [13/Aug/2014:12:34:56 +0200] ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 "GET / HTTP/1.1" 200 1234 "-" "User agent bla"

This way I can quickly identify clients which are using outdated browsers or automated machines which do not support PFS or other relevant security enabling technologies.

How do I configure nginx to log this information?

Best Answer

Add $ssl_cipher to your log_format configuration.

Refer to http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables for all SSL-related variables.

Example

Define a custom log_format in the http context (e.g. /etc/nginx/nginx.conf):

log_format combined_ssl '$remote_addr - $remote_user [$time_local] '
                        '$ssl_protocol/$ssl_cipher '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent"';

The above is based on the default combined format with an additional '$ssl_protocol/$ssl_cipher ' line.

Then add in a server context (with SSL enabled) the access_log directive with the custom log format:

server {
  listen 443;
  ssl on;
  access_log /var/log/nginx/access.log combined_ssl;
  [...]
}

After restarting nginx, logs appear like:

10.1.2.3 - - [13/Aug/2014:12:34:56 +0200] TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256 "GET / HTTP/1.1" 200 1234 "-" "User agent bla"

SSL v.s. TLS

As far as I'm aware, SSLv1 never left the labs. SSLv2 and SSLv3 were protocols developed by Netscape. SSLv2 has been considered insecure for a while, since it's prone to downgrade attacks. SSLv3 internally uses (3,0) as its version number (within the ClientHello message).

TLS is the result of the standardisation as a more open protocol within IETF. (I think I have read somewhere, perhaps in E. Rescorla's book, that the name had been chosen in such a way that all participants were equally unhappy with it, so as not to favour a particular company: this is quite common practice in standards body.) Those interested in how the transition was made can read the SSL-Talk List FAQ; there are multiple copies of this document around, but most links (to netscape.com) are outdated.

TLS uses very similar messages (sufficiently different to make the protocols incompatible, although it's possible to negotiate a common version). The TLS 1.0, 1.1 and 1.2 ClientHello messages use (3,1), (3,2), (3,3) to indicate the version number, which clearly shows the continuation from SSL.

There are more details about the protocol differences in this answer.

When do I use which? When do I not use which?

Use the highest version you can if possible. In practice, as a service provider, this will require your users to have clients that support these versions. As usual, it's always a risk-assessment exercise (preferably backed with a business case if appropriate). This being said, cut off SSLv2 anyway.

In addition, note that the security provided by SSL/TLS isn't just about which version you use, it's also about proper configuration: it's certainly preferable to use SSLv3 with a strong cipher suite than TLSv1.0 with a with a weak (or anonymous/null-encryption) cipher suite. Some cipher suites, considered too weak, have been explicitly forbidden by newer versions of TLS. The tables in the Java 7 SunJSSE provider (and their footnotes) can be of interest if you want more details.

It would be preferable to use TLS 1.1 at least, but not all clients support them yet unfortunately (e.g. Java 6). When using a version under 1.1, it's certainly worth looking into mitigating the BEAST vulnerability.

I'd generally recommend Eric Rescorla's book - SSL and TLS: Designing and Building Secure Systems, Addison-Wesley, 2001 ISBN 0-201-61598-3 to people who really want more details.

Implicit v.s. Explicit SSL/TLS

There is a myth saying that TLS allows you to use the same port whereas SSL can't. That's just not true (and I'll leave port unification out for this discussion). Unfortunately, this myth seems to have been propagated to users by the fact that some applications like MS Outlook sometimes offer a choice between SSL and TLS in their configuration options when they actually mean a choice between implicit and explicit SSL/TLS. (There are SSL/TLS experts at Microsoft, but it seems they weren't involved in the Outlook UI.)

I think the reason why this confusion happen is because of the STARTTLS mode. Some people seem that have understood this as STARTTLS = TLS, but this is not the case. The key word in STARTTLS is "START", not TLS. Why this wasn't called STARTSSL or STARTSSLORTLS is because these extensions were specified within IETF, which only used names used in its specifications (assuming that the TLS name would eventually be the only standing, I guess).

SSL on the same port as the plain-text service: HTTPS proxy.

Nowadays, most HTTPS servers can handle TLS, but a few years ago, most people were using SSLv3 for HTTPS. HTTPS (strictly speaking, standardised as HTTP over TLS) normally establishes the SSL/TLS connection upon TCP connection, and then exchanges HTTP message over the SSL/TLS layer. There is an exception to this when using an HTTP proxy in between. In this case, the client connects to the HTTP proxy in clear (typically on port 3128), then issues the CONNECT HTTP command and, provided the response was successful, initiates the SSL/TLS handshake by sending a ClientHello message. All of this happens on the same port as far as the connection between browser and proxy is concerned (obviously not between proxy and the target server: it's not even the same machine). This works just fine with SSLv3. Many of us in situations behind a proxy will have used this against servers that didn't support at least TLS 1.0.

SSL on the same port as the plain-text service: e-mail.

This one is clearly out of specifications, but in practice, it often works. Strictly speaking the specifications talk about switching to TLS (not SSL) after using the STARTTLS command. In practice, SSL often works too (just like the "HTTP over TLS" spec also encompasses using SSL instead of TLS too). You can try it by yourself. Assuming you have an SMTP or IMAP server that supports STARTTLS, use Thunderbird, go into the preferences, advanced options, config editor and turn off security.enable_tls. Many servers will still accept the connection, simply because their implementations delegate the SSL/TLS layer to an SSL/TLS library which will generally be able to handle SSL and TLS in the same way, unless configured not to do so. As the OpenLDAP FAQ puts it, "While the mechanism is designed for use with TLSv1, most implementations will fallback to SSLv3 (and SSLv2) if necessary. ". If you're not sure, check with a tool like Wireshark.

TLS on a distinct port.

Many clients can use TLS 1.0 (at least) for protocols where the secured variant is on a different port. Obviously, there are a number of browsers and web servers that support TLS 1.0 (or above) for HTTPS. Similarly, SMTPS, IMAPS, POPS and LDAPS can use TLS too. They're not limited to SSL.

When do I use which? When do I not use which?

Between explicit and implicit SSL/TLS, it doesn't really matter. What matters is that your client knows what to expect and is configured appropriately to do so. More importantly, it should be configured to reject plain text connections when it's expecting an SSL/TLS connection, whether it's implicit or explicit.

The main difference between explicit and implicit SSL/TLS will be in the clarity of the configuration settings.

For example, for LDAP, if the client is an Apache Httpd server (mod_ldap -- its documentation also mislabels the difference between SSL and TLS, unfortunately), you can use implicit SSL/TLS by using an ldaps:// URL (e.g. AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) or use explicit SSL/TLS by using an extra parameter (e.g. AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).

There is perhaps generally speaking a slightly lesser risk when specifying the security protocol in the URL scheme (https, ldaps, ...) than when expecting the client to configure an additional setting to enable SSL/TLS, because they may forget. This is arguable. There may also be issues in the correctness of the implementation of one versus the other too (for example, I think the Java LDAP client doesn't support host name verification when using ldaps://, when it should, whereas it is supported with ldap:// + StartTLS).

In doubt, and to be compatible with more clients if possible, it doesn't seem to do any harm to offer both services when the server supports it (your server will just be listening on two ports at the same time). Many server implementations for protocols that can be used with either modes will support both.

It is the responsibility of the client not to let itself being downgraded to a plain-text connection. As a server administrator, there is nothing you can technically do on your side to prevent downgrade attacks (apart from requiring a client-certificate perhaps). The client must check that SSL/TLS is enabled, whether it's upon connection or after a STARTTLS-like command. In the same way as a browser shouldn't let itself be redirected from https:// to http://, a client for a protocol that support STARTTLS should make sure the response was positive and the SSL/TLS connection was enabled before proceeding any further. An active MITM attacker could otherwise easily downgrade either connections.

For example, older versions of Thunderbird had a bad option for this called "Use TLS, if available", which essentially implied that if a MITM attacker was able to alter the server messages so that it didn't advertise support for STARTTLS, the client would silently let itself be downgraded to a plain-text connection. (This insecure option is no longer available in Thunderbird.)

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

Best Answer

Example

Related Solutions

Functional Implications of Differences Between SSL and TLS

SSL v.s. TLS

Implicit v.s. Explicit SSL/TLS

NGINX Redirect – How to Rewrite All HTTP Requests to HTTPS While Maintaining Sub-Domain

Correct way in new versions of nginx

Related Topic