An overview of secure usage of TLS

Here is a brief overview which describes how TLS can be used for establishing a secure TLS connection. First, we briefly discuss what SSL/TLS protocols are. Next, we’ll talk about secure TLS protocol versions and parameters. Finally, we’ll describe how TLS can be parametrized securely.

Securing TLS

What is SSL/TLS?

SSL stands for Secure Sockets Layer, and TLS stands for Transport Layer Security.

SSL/TLS is a family of cryptographic protocols which provide communications security over an untrusted network. The main goals of SSL/TLS protocols are the following:

  • Confidentiality by encrypting data with symmetric ciphers (for example, AES-256 in GCM mode)
  • Authentication of server (and client if required) by using using public-key cryptography
  • Data integrity by using MAC (message authentication code)

An SSL/TLS connection contains two main phases:

  • Handshake which allows client and server to:
    • netotiate parameters for an SSL/TLS connection such as encryption algorithm, authentication scheme, hash function, MAC algorithm
    • authenticate both server and client if necessary
    • securely exchange cryptographic keys
  • Secure application data exchange using encryption algorithms and parameters established during handshake

You can find more details about SSL/TLS protocols in Wikipedia, or refer to the corresponding RFCs for technical details (for example, RFC 5246 which defines TLS 1.2).

What SSL/TLS versions do we have?

At the moment of writing this post, there are several main SSL/TLS versions:

  • SSL 3.0
  • TLS 1.0
  • TLS 1.1
  • TLS 1.2
  • Draft of TLS 1.3 which is proposed as the next version of TLS protocol

Even if the differences between SSL/TLS versions above don’t seem to be huge, the protocols above are not compatible.

Which TLS versions should be used for a secure connection?

At the moment of writing this post, only TLS 1.2 protocol is considered secure. TLS 1.3 is the next TLS version, and should be considered secure once the protocol specification is approved (unless someone finds a critical vulnerability in the protocol right away after publishing :) Other SSL/TLS versions are considered less secure due to various vulnerabilities and weaknesses in the protocols. For example, discovering the POODLE attack resulted to prohibiting SSL 3.0.

Using TLS 1.2+ may not be enough for establishing a secure TLS connection. The following aspects need to be taken into account as well:

  • Only secure parameters of a TLS connection such as strong TLS cipher suites, strong key sizes and strong parameters for key exchange algorithms should be used
  • Lower protocol versions should be disabled to prevent protocol downgrade attacks
  • Insecure modes and features such as renegotiation and compression should be disabled
  • Server and client should use latest version of TLS libraries which contain security patches for discovered vulnerabilities in TLS implementations like Heartbleed

What parameters should be used for a secure TLS connection?

Client and server can use different parameters to establish a TLS connection such as cipher suites, keys lengths, initial parameters for Diffie-Hellman key exchange algorithm.

First, client and server should use a secure cipher suite which:

  • doesn’t use weak cryptographic algorithms such as RC4, DES, 3DES
  • uses an AEAD cipher such as AES in GCM mode
  • uses strong hash functions such as SHA-256
  • provides forward secrecy by using ephemeral Diffie-Hellman key exchange (EDH and ECDHE) with strong initial parameters

Here is a list of good cipher suites for TLS 1.2:

  1. ECDHE-RSA-AES256-GCM-SHA384
  2. ECDHE-RSA-AES128-GCM-SHA256
  3. DHE-RSA-AES256-GCM-SHA384
  4. DHE-RSA-AES128-GCM-SHA256

OWASP provides a good guideline for configuring cipher suites.

Second, a client should require server authentication, and then validate a server certificate chain including:

  • correctness of digital signatures
  • hostname validation
  • certificate expiration
  • revocation status
  • the chain ends with a trusted certificate

Clients need to make sure that a server certificate uses strong cryptographic algorithms with strong key sizes.

The features above should be provided by a good TLS implementation. It would not be worse to mention again that you should not implement your own cryptographic library. It’s not necessary to invent a wheel. Furthermore, implementing a cryptographic algorithms and protocols requires a solid knowledge in cryptography and paying attention to a lot of details. Just a single bug can ruin everything and make the implementation insecure. Instead, it’s recommended by experts in cryptography and software security to use well-known cryptographic libraries such as OpenSSL, NSS or JSSE which we’re going to discuss soon.

P.S. This is just an overview of secure usage of TLS butnot an ultimate guideline.

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Share

Leave a Reply

avatar
  Subscribe  
Notify of