TLS and SSL

Digital certificates allow for the secure exchange of public encryption keys over, otherwise, untrusted networks. Transport encryption technology, such as Transport Layer Security or TLS uses those certificates to facilitate secure communication over public networks. Let's explore TLS by describing the process that two systems follow when they wish to set up an encrypted session protected by TLS. First, the client sends a request to the server asking that the server initiate a secure session. This request includes a list of cipher suites supported by the client. Now, it's important to understand that TLS is only a protocol that uses other cryptographic algorithms. TLS is not a cryptographic algorithm itself. Therefore, you can't encrypt something with TLS. You can use TLS to apply other encryption algorithms. The listing of cipher suites sent by the client to the server is a laundry list of the encryption algorithms, hash functions, and other cryptographic details that the client understands. Those cipher suites are only as strong as the algorithms that they include. Therefore, it is possible to use TLS in an insecure manner by choosing a weak or insecure cipher suite. Once the server receives that request from the client, it analyzes the list of cipher suites that the client proposes and compares it to the list of algorithms supported by the server. It then sends a message back to the client with two pieces of information. First, the server tells the client which of the cipher suites it would like to use for the communication. Second, the server sends the client the server's digital certificate which contains the server's public encryption key. When the client receives the server's digital certificate, the client checks what certificate authority issued the certificate and uses the CA's public key to verify the digital signature on the certificate. It also verifies that the server name on the certificate matches the DNS name of the server, and that the certificate has not been expired or revoked. If all of those things check out, the client knows that it has the correct public key for the server. Once the client is satisfied about the server's identity, the client creates a random encryption key called the session key. This is a symmetric encryption key that will be used for this one communication session between the client and the server. The client then uses the server's public key to encrypt the session key, and sends that encrypted key to the server. When the server receives the encrypted key, uses its own private key to decrypt the session key. The two systems may then communicate for as long as they like using that session key. Once they close the connection, the session key is destroyed and the TLS handshake starts over the next time the two systems wish to communicate. One quick exam tip. Session keys are also known as ephemeral keys. If you see the term "ephemeral key" on the exam, they're just talking about session keys. You may also hear about an encryption technology called the Secure Sockets Layer or SSL. SSL was the predecessor to TLS and it works in a very similar way. However, there are known security flaws in SSL, so it should no longer be used. Unfortunately, many people use SSL as a generic term when they're really talking about TLS. This can be very confusing, so be careful to dig deeper whenever you hear the term "SSL" being used.