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.

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:

An SSL/TLS connection contains two main phases. The first phase is handshake which allows client and server to:

The second phase is secure application data exchange using encryption algorithms and parameters established during the 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:

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:

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:

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

OWASP provides a good guideline for configuring cipher suites.

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

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.

Originally published at on April 21, 2018.

I write about Java, security, electronics and DIY

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store