IT Admin's QuickStart
  1. Home
  2. TLS 1.2
  3. IT Admin's QuickStart

TLS 1.2 Configuration

What to expect:

For TLSv1.2, the following configuration settings will provide the best possible security (mitigation of all known vulnerabilties):
  • Enabling TLSv1.2 - First step is to ensure that your devices are configured for accepting and establishing TLSv1.2 connections. For security reason, it also needs to be further ensured that older versions of SSL/TLS are disabled. Server and Client must reject any connections offering SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
  • Cipher Suites: A configurable option that most product vendors provide with SSL/TLS is called the Cipher Suite. The cipher suite decides the key exchange, signature, encryption and hashing algorithm used with SSL/TLS. There are various options with all the above mentioned parameters and some of them have been marked as unsafe due to vulnerabilities found in recent times. Special care must be taken to ensure that TLSv1.2 is configured correctly and below are the recommended cipher suites. The recommendations are based on a recent attack called a ROBOT attacks.
  • DH Parameters: Diffie Helman Key Exchange protocol is a popular protocol option for exchanging keys between a server and a client in a secure fashion. SSL/TLS provides options to use DH but it should be ensured that the right kind of keys are configured for the protocol. The recommendations are based on the LogJam attack.
  • Type of Certificates: Certificates form the basis of authentication in SSL/TLS. Using certificates the client can authenticate the server and vice versa (although client side authentication using certificates is optional).
  • Key type and Size: Apart from DH keys, there are other keys that are used for digital signature purposes. Choosing the right kind of keys is important.

    • For the above settings, there have been examples mentioned below.

Concept: TLSv1.2 as a protocol is, as of now, safe. But, if configured incorrectly, your device can still be vulnerable. In this section, using a certain few examples explore how configuration is setup to enable TLSv1.2 with right settings. Since there are no vulnerabilities that have been found with this version yet, we cover as to how you can check if your connections are TLSv1.2. Again, note that enforcement of TLSv1.2 on all connections is recommended for security.

Note: Enabling TLSv1.2 on your device is the first step that is to be taken towards ensuring security. However, recent vulnerabilities discovered in certain options provided by the protocol mandate that the configuration of TLSv1.2 also follows certain guidelines.These recommendations have been mentioned in the later part of this section under General Recommendations of TLS .

Examples for Enabling TLSv1.2:

We have categorized the examples into three sections:- Webservers, Browsers and VPN.

    Webservers:

    Enabling TLSv1.2 under the web server’s SSL configuration settings is required. It is required to leave out vulnerable versions of SSL from the configuration so that legacy clients are not able to connect until an upgrade is performed. Here are a couple of examples from common webservers on how this can be done.

    Apache:
    To add TLSs1.2 you just need to add in your ‘https virtual host’ configuration: 
    ...
SSLProtocol -all +TLSv1.2
...
    Explanation:
    -all is removing other ssl protocol (SSL 1,2,3 TLS1)
    +TLSv1.2 is adding TLS 1.2

    For more browser compatibility you can use:- 
    ...
SSLProtocol -all +TLSv1.2
...
    Nginx:
    By default, the configuration file is named nginx.conf and placed in the directory /usr/local/nginx/conf , /etc/nginx , or /usr/local/etc/nginx. 
    ...
ssl_protocols TLSv1.2;
...


    Similar to the Apache config above, you will get TLSv1.0+ support and no SSL. You can check the config and restart. 
    
$sudo nginx -t
$sudo service nginx restart
    To enforce TLSv1.2: 
    ...
ssl_protocols TLSv1.2
...
    Tomcat
    The configuration file for Tomcat should be in
    TOMCAT_HOME/conf/server.xml

    Tomcat 5 & 6 (Prior to 6.0.38

    Within the server.xml find the sslProtocols entry and make sure only TLS protocols are specified: 
    sslProtocols = "TLSv1.2"
    Tomcat 6 & 7 (6.0.3.8 and newer)

    Within the server.xml file, find the sslEnabledProtocols entry and make sure only TLS protocols are specified: 
    sslEnabledProtocols = "TLSv1.2"
    Restart the Tomcat service to complete the changes.



    Browsers:

    Technically the attack is a client based and although ensuring servers do not accept SSLv3 connections, it is important to plug the problem on the client side as well. Here are some common browsers where configuration changes can be made so as to make sure that only connections on TLSv1.2 are accepted.
    To enable TLS 1.2 protocols on web browsers, see the list below.

    • Microsoft Internet Explorer
      • Open Internet Explorer
      • From the menu bar, click Tools > Internet Options > Advanced tab
      • Scroll down to Security category, manually check the option box for Use TLS 1.2
      • Click OK
      • Close your browser and restart Internet Explorer

    • Google Chrome
      • Open Google Chrome
      • Click Alt F and select Settings
      • Scroll down and select Show advanced settings...
      • Scroll down to the Network section and click on Change proxy settings...
      • Select the Advanced tab
      • Scroll down to Security category, manually check the option box for Use TLS 1.2
      • Click OK
      • Close your browser and restart Google Chrome

    • Mozilla Firefox
      • Open Firefox
      • In the address bar, type about:config and press Enter
      • In the Search field, enter tls. Find and double-click the entry for security.tls.version.min
      • Set the integer value to 3 to force protocol of TLS 1.2
      • Click OK
      • Close your browser and restart Mozilla Firefox

    • Opera
      • Open Opera
      • Click Ctrl plus F12
      • Scroll down to the Network section and click on Change proxy settings...
      • Select the Advanced tab
      • Scroll down to Security category, manually check the option box Use TLS 1.2
      • Click OK
      • Close and restart Opera

    • Apple Safari
      There are no options for enabling SSL protocols. If you are using Safari version 7 or greater, TLS 1.1 and TLS 1.2 are automatically enabled.

    VPN:
    The VPN gateway needs to be configured to only accept TLSv1.2 connection. Apart from configuration, patches provided by the software company should be installed with immediate priority.

    To verify: https://www.ssllabs.com/ssltest/index.html
Note: Configuring TLSv1.2 - After ensuring that your device is ready to accept TLSv1.2 connections. The next step is to ensure that TLSv1.2 connections are hardened in order to provide best security. A common misconception is why are we "reconfiguring" TLSv1.2 while it's already setup. It has to be noted that the first step was only to setup TLSv1.2, the first step is to ensure that your devices are configured to accept and establish TLSv1.2 connections. For security reasons, it also needs to be ensured that the encryption, key exchange and hashing methods are tweaked for maintaining confidentiality and integrity.

Guide to reading cipher from configuration files:

One of the most popular formats look like this: 
...
ECDH+AESGCM:ECDH+AES256
...

The above example shows two cipher suites separated by a ':'. The first cipher 'ECDH+AESGCM' specifies ECDH as the signature algorithm for TLS while the AESGCM specifies the encryption scheme with its mode of operation. The second cipher, ECDH:AES256 specifies ECDH being used as the signature scheme and AES256 talks about the encryption algorithm. The mode of operation will be whatever is the system default.

Recommended Cipher Suites

TLS Recommended Ciphers:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

Disable the following ciphers:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256

The problem with this is that using RSA for key exchange does not provide perfect forward secrecy since you are not using ephemeral “one-time use” keys which means they are susceptible to the ROBOT Attack.

Note:
More info on why not to use DHE and use ECDHE instead: The DHE ciphers are safe to use only if dh group 14 (2048 bit) key sizes are being used for key exchange. If a lower dh group size is used with DHE ciphers then your server will be susceptible to the Logjam attack. This setting may have to be set in the OpenSSL code. There is not a configurable option external to the openssl module. Apache allows for configuring the dh parameters via their management interface but extreme care should be taken in order to avoid unecessary implications by tweaking such settings. In order to keep things simple and safe, use ECDHE. There are other benefits which have been well described here. Here is another good write-up: Usage of non-ephermeral-dh vs dhe .

Upgrade/Patch Management

Concept: There are no notable patches or upgrades that are present for any of the popular products using TLSv1.2. But IT administrators should always keep a close watch on any patches or upgrade notifications from product vendors. The expectation is that these patches will not particularly target protocol vulnerabilities but rather implementation ones. For example, a software bug in Cisco product allows compromise of TLSv1.2's security. Understanding a newly released patch or upgrade should be possible by reading its respective documentation and queries of any sort should be clarified with the product manufacturers to ensure a smooth process with no adverse impacts.
Note: Keep an eye out for this section as it will be kept up-to-date with any major patches that are released.