What is Transport Layer Security (TLS)?
TLS, or Transport Layer Security , is a widely used cryptographic protocol that ensures data security during communication over a network. The TLS protocol, like its predecessor SSL (Secure Sockets Layer), is primarily designed to enable reliable, authenticated, and secure communication between two or more computer applications. In modern browsers, connections secured with TLS are usually indicated by a lock icon next to the URL.
We won't go too deep here (there are whole books written on the subject!) but at its most basic, cryptography is the study and practice of techniques for secret communication between two or more parties. Everything from kids' invisible ink to the Enigma encryption machine used during WWII are parts of cryptography.
When it comes to the internet, usually cryptography is applied to creating sets of rules (protocols) that allow secure, encrypted communication over a network.
Sending data over a network is like sending a postcard. Once you've mailed the postcard, there are a lot of people who have the opportunity to read what you've written...postal workers, mail thieves, anyone who gets their hands on the card. If you want to send something private on a postcard, you need to obscure the message. The same is true of data sent over the internet: it is possible for unintended audiences to peek at that data while it is in transport.
In the early days of the internet, there were fewer people with the access, motivation, or the knowledge to snoop on this data in transit. But as the internet became a larger part of daily life, internet users needed a way to ensure data security over a network.
In the early 1990s, Netscape developed the first transport layer protocol designed for network security — Secure Sockets Layer (SSL). The internet widely adopted this protocol and it saw numerous iterations over the next few years, until it was completely overhauled to become TLS in 2006. Today, TLS is a key requirement of most network connections and SSL has been completely deprecated.
There are two primary types of cryptography we'll talk about here: "asymmetric" and "symmetric". Asymmetric cryptography (or "public key cryptography") is facilitated by pairs of keys, one public and one private. The message recipient shares their public key with a message sender. The message sender uses the recipient's public key to encrypt their message. When the recipient gets the message, they use their private key to decrypt the message. Other than verifying that the public key belongs to the legitimate recipient (see Certificate Authorities, below), no secure key exchange is required. However, generating and using the public key is slow because the key needs to be very large to support this scheme.
Symmetric cryptography only requires one shared key that is used to encrypt and decrypt messages back and forth. This scheme is faster because the key can be smaller, but presents a kind of chicken and egg problem. How do you securely share a secret key to enable encrypted communication?
TLS uses a combination of these schemes to solve the key exchange problem and facilitate the private connections needed for sending sensitive data.
The TLS handshake is the start of secure communication over a network. It is a series of steps in which the client and server negotiate the parameters of their secure connection and generate and exchange their symmetric encryption keys. Here is a simplified overview of the steps involved in a TLS handshake:
- A client indicates to a server that it wants to connect and sends some information about which "cipher suites" it supports and prefers. "Cipher suites" are sets of encryption algorithms that the parties can use to generate keys and encrypt data.
- The server then presents the client with their certificate (from the CA, described above) and public key, which the client can validate by referencing known lists of trusted CAs and by validating a certificate with a CA directly.
- Optionally, the server might also ask the client to send back a certificate to verify itself.
- Next, the client generates a "session key" (the symmetric key that the server and client will use for symmetric encryption) and encrypts it using the server's public key (shared in step 2).
- The client sends the encrypted session key to the server.
- The server already has the private key required to decrypt the session key.
- Now both parties have a securely-shared key that they can use to encrypt and decrypt messages! As a final step, the client sends the server an indicator that it is ready to begin using only encrypted communication and an encrypted message, which the server verifies it can decrypt. The server repeats this process in the opposite direction.
- The TLS handshake is complete! All communication between the client and the server from this point forward is encrypted.
- The session key is short-lived and the communicating parties will repeat the TLS handshake the next time they need to connect if the session key has expired or been discarded.
As of June 2019, the Twilio REST API only supports connections that use TLS v1.2. It is important to stay up-to-date on security updates for the Twilio REST API to be sure that your applications built with the Twilio API are secure and trustworthy.
Find more information about how to monitor updates to the Twilio REST API security settings here.
Find tips on how to upgrade your environment to support the latest TLS requirements here.