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.
Certificate Authorities (CAs) are an important part of the TLS protocol. They are entities (like LetsEncrypt) that issue digital certificates which validate that a public key is owned by a legitimate organization. CAs act as trusted, independent third parties giving clients assurance that they are communicating with the right system, and that all parties involved will comply with the rest of the TLS protocol.
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.
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.