The SSL/TLS family of protocols have been protecting internet communications since 1995, but there are still misunderstandings around what SSL/TLS is, not the least part because of the confusing terminology used. This post will not be in in-depth discussion of the specifics of SSL/TLS but rather a helping hand in decoding the jargon.
The name SSL/TLS is used for the family of protocols, however, it is also common to see both SSL and TLS names used on their own to describe the full family. From here on in the post we will use SSL/TLS for the family and will specify versions, for examples TLS 1.2, when talking about specific protocols from the family.
The following protocols currently form the SSL/TLS family:
Which version of SSL/TLS should we be using?
There are known vulnerabilities in all versions of SSL/TLS before TLS 1.2; SureCloud recommends only supporting TLS 1.2 and above; however there may be business reasons why support for earlier versions of TLS are required. A full discussion on cipher suite selection is beyond the scope of this post, however we will discuss some of the key points later.
What makes up SSL/TLS?
In this post we will discuss the various parts that make up SSL/TLS protocols, as well as few terms that are often discussed alongside SSL/TLS.
HTTPS is an extension to HTTP that uses SSL/TLS to protect web traffic. A URL like https://example.org will instruct a browser to connect to a webserver using HTTPS on the standard TCP port (443).
Requests and responses are still made using the HTTP protocol; they are just wrapped inside the SSL/TLS protocol which provides the encryption, integrity and attribution layers.
Ciphers and Cipher Suites
A cipher is an algorithm that takes a plain text message, in the case of HTTPS your unencrypted HTTP data, and scrambles it up to prevent a third party from being able to read it. Ciphers uses keys/shared secrets to decrypt and encrypt data, it is important that that only trusted parties know these secrets; the method used to decide on this shared secret is called key exchange is discussed further below.
There are a number of ciphers available to use in the various versions of SSL/TLS, to increase the number of clients who are able to connect it is common to support a number of different ciphers; however selecting the right ciphers very important, weaknesses have been found in some ciphers that were once considered secure, and some ciphers have become more vulnerable as computing power has increased. Different versions of SSL/TLS support different ciphers, and some clients may only support a subset of the ciphers supported by a specific version of SSL/TLS.
Choice of ciphers is beyond the scope of this post, however one important factor to consider with ciphers is if they support perfect forward security. TLS 1.3 the upcoming new version of TLS will only support algorithms have perfect forward security.
Cipher suites are a combination of ciphers, key exchange methods and MACs that are typically displayed together in the following format “DHE-RSA-AES256-GCM-SHA384.”
They key exchange algorithm is the method that SSL/TLS uses to decide on the key to use in the cipher. As with ciphers there are multiple key exchange algorithms that can be used, and different ciphers and different versions of SSL/TLS support different key exchange algorithms.
Message Authentication Code (MAC)
Message authentication codes are generated by algorithms and are used to ensure that the data has not been modified in flight. MACs are similar to error detection codes, however are based on cryptography and are designed to not be forgeable.
A cipher suite is SSL/TLS terminology for a set of cipher, key exchange algorithm, MAC code, and a pseudo random number function used to set up the secure communication. These are the strings that you often see when people are talking about SSL/TLS such as “TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.” A SSL server can have one or more cipher suites enabled and the SSL client and server will negotiate which suite to use when the connection is started, it is by this processes that clients that support older versions of SSL/TLS are still able to communicate new servers.
Certification is the process used to prove the identity of an actor in an SSL/TLS communication. Certificates can be used to prove the identify of both parties, however in HTTPS (one of the most common users of SSL/TLS) only the server is usually identified via a certificate.
Certification works via a tree of trust, a small number of parties own certificates that have been pre-trusted with browsers and operating systems. These parties form the root of the trust tree, and can sign certificates of other trusted parties, and these parties may be able to sign further certificates. By following the chain of trust back up to the pre-trusted root certificates it is possible to check the validity of any of any certificate.
There are number of types of certificate issues to websites; that vary in the amount of checks the issuer performs and thus the amount of trust they bestow, and what they can be used for.
One type of certificate you may have heard of is an Extended Validity (EV) certificate; these certificates require more checks, but provide one of the highest levels of trust. Sites using these certificates will receive the green bar in browsers which users are taught to look for.