Thursday 9 July 2015

Mitigating recent TLS vulnerabilities

Recently discovered vulnerabilities in TLS (also known as SSL -- the protocol implementing secure web browsing and securing other activities such as email) can and should be mitigated by appropriate server configurations. Existing defaults and previously-recommended configurations may require attention to address these issues. While these vulnerabilities have been addressed in recent versions of major clients, not everyone runs up-to-date versions and not all access is from major clients.

Vulnerabilities addressed by this advice include 'POODLE' (CVE-2014-3566), 'Freak' (CVE-2015-0204), and 'LogJam' (CVE-2015-4000).

What represents a 'best' configuration depends on the capabilities of the servers involved, and of their expected clients. The best security can only be obtained on up-to-date software and only with configurations that may exclude some older clients. The following advice will provide a reasonable level of security but should be reviewed in the light of specific requirements.

The following advice is intended to be generic; specific configuration advice for some platforms appears below.

Suggestions (in order of importance):

1) Ensure that the SSLv2 and SSLv3 versions of the protocol are disabled.

Note that IE6 on Windows XP will be unable to communicate with servers that don't support SSLv3, but given its age this should be acceptable -- many major services already disable SSLv2 and SSLv3.

2) Adjust the cryptographic suites supported to exclude the following:

  • all 'export' suites
  • any using symmetric encryption with keys less that 128 bits
  • any using signatures based on the MD5 hash algorithm
  • any using symmetric encryption based on the RC4 algorithm

3) Configure Diffie-Hellman (DH) key exchange to use at least 2048-bit groups. Additionally generate a unique 2048-bit group for use in Diffie-Hellman key exchange on each server. As an alternative, it may be appropriate to disable all cryptographic suites that rely on Diffie-Hellman key exchange. Plan to upgrade systems that can't be appropriately configured.

Note that this advice does not apply to Elliptic-Curve Diffie-Hellman key exchange (ECDH) which does not currently have any known vulnerabilities. Note also that Java 1.6 and 1.7 clients may be unable to communicate with servers offering Diffie-Hellman key exchange using groups over 1024-bits long.

4) Support TLSv1.2 - plan to upgrade any systems that can't do so.

One way to test your configuration is to use the SSL Labs server test page. Aim to eliminate any issues flagged 'VULNERABLE' or shown in red, and to reduce or eliminate any marked 'WEEAK' or shown in orange. It should be possible to achieve an overall rating of at least 'B' and preferably 'A' but don't be guided entirely by the overall rating shown. The 'Handshake Simulation' section of the report can be helpful when evaluating the impact of any configuration change on clients.

Implementations:

Apache:

Add the following directives to httpd.conf or equivalent and ensure that they are not being overridden elsewhere:

    SSLProtocol all -SSLv2 -SSLv3
    SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!RC4

TLSv1.2 is automatically available on systems running OpenSSL 1.0.1 or above but not otherwise - plan to upgrade systems that include only lower versions

By default Apache 2.2 only supports a fixed 1024-bit Diffie-Hellman group - plan to upgrade it. Apache from 2.4, and patched versions of 2.2 in some Linux distributions, support longer fixed groups. Unique groups can be created with the command

    openssl dhparam -out dhparams.pem 2048

and loaded into patched versions of Apache 2.2, and into Apache 2.4 with the directive

    SSLOpenSSLConfCmd DHParameters dhparams.pem

Restart Apache after making these changes.

IIS:

See elsewhere for instructions on disabling SSLv2 and SSLv3.

To set cryptographic suites:
  • Open the Group Policy Object Editor (i.e. run gpedit.msc in the command prompt).
  • Expand Computer Configuration --> Administrative Templates --> Network --> SSL Configuration Settings.
  • In the right pane, open the SSL Cipher Suite Order setting.
  • A reasonable cipher suite list (from Bulletproof SSL and TLS, Ch 15) would be:

      TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
      TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
      TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
      TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
      TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
      TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 
      TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

    If this excludes some old but necessary clients then consider adding:

      TLS_RSA_WITH_AES_128_CBC_SHA
      TLS_RSA_WITH_AES_256_CBC_SHA
      TLS_RSA_WITH_3DES_EDE_CBC_SHA
      TLS_RSA_WITH_RC4_128_SHA

Reboot after making these changes

nginx

The Nginx project have published instructions on how to disable SSLv3 on Nginx.

To configure cipher suites place the following in the website configuration server block in /etc/nginx/sites-enabled/default (see the LogJam pages):

      ssl_ciphers 'ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!RC4';

Custom Diffie-Helman groups can be created with the command:

      openssl dhparam -out dhparams.pem 2048

and loaded into nginx with the following configuration:

      ssl_dhparam dhparams.pem;

Tomcat

See elsewhere for instructions on disabling SSLv2 and SSLv3.

Configuring cipher suites (see Bulletproof SSL and TLS):

* With the APR/Native connector
  •  Set the 'SSLCipherSuite' attribute of the 'Connector' XML element in your $TOMCAT_HOME/conf/server.xml file:

    SSLCipherSuite = "ALL:!aNULL:!eNULL:!LOW:!EXP:!MD5:!RC4
* With the JSSE connector
  • Set the 'ciphers' attribute of the 'Connector' XML element in your $TOMCAT_HOME/conf/server.xml file:

    ciphers = "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
    TLS_RSA_WITH_AES_128_CBC_SHA,
    SSL_RSA_WITH_3DES_EDE_CBC_SHA"

Saturday 31 January 2015

Information Systems - what we do

Building on yesterday's list of technologies use by the Information Systems team here at the University, here are some of the services that we run. Much of this will probably only make sense to people inside the University.
In addition, we contribute to a number of services run by other parts of UIS:
So now you know.

Friday 30 January 2015

An Information Systems colophon

I've followed the work of Government Digital Service (GDS - the people behind GOV.UK) for a while. It seems to me that an organisation dedicated to “leading the digital transformation of government” probably knows a thing or two that's relevant to the digital transformation of a university.

GDS have a blog, and their list of technologies that they use is interesting. Work I've been doing recently means that I've created a similar list of the technologies used within my Information Services team here at the University. For what its worth this what it looks like:

Core servers
Base software products
  • Some services are based on existing software, including phpBB and Mediawiki
  • The Web Search service is provided by Funnelback
Technologies

We rely on, and in some cases also support, a range of technologies:
Applications (incl. Frameworks, etc)
Database and other storage
Monitoring, managing and alerting
Supporting Tools
  • Central RT system for support tickets
  • Trac and Mantis for bug tracking
  • We've been experimenting with LeanKit and Asana for program and project management