It’s no secret the more we communicate over the Internet the more we need security. Ecommerce, Email, and user authentication are all examples of sensitive data that should be encrypted to protect the unwanted eavesdropping of third parties. Lucky for end users the community known as the Internet Engineering Task Force (IETF) developed the Secure Socket Layer and Transport Layer Security protocol also known as (SSL\TLS) to address the problem. SSL\TLS has been essential to businesses and consumers that rely on the everyday transmission of sensitive information. In this post, I will discuss the inner workings of SSL\TLS that make data encryption possible.
SSL\TLS started with a unique international community of network designers, operators, vendors and researchers known as the Internet Engineering Task Force (IETF). Their mission is to make advancements in Internet architecture and ensuring its seamless operation.
Among many of IETF’s technological advances, another well-known protocol created by this international community is the Transmission Control Protocol\Internet Protocol or TCP\IP. This protocol transports and route data over the internet. TCP\IP also allows protocols such as the Hypertext Transfer Protocol (HTTP) and the Internet Messaging Access Protocol (IMAP) to run “on top of” it meaning they all use TCP\IP to support application tasks (i.e. secure data transmission).
A few of the protocols SSL works with are TCP\IP, IMAP, and HTTP. The Green ‘padlock’ icon displayed in a web browser’s address bar such as Gmail indicates a user is securely sending email; this is an example of SSL “running on top” of IMAP. The ‘padlock’ icon may also be seen when using an e-commerce (e.g. banking) website; this is an example of SSL “running on top” of HTTP also known as HTTPS.
The overall concern with data transmission is that no one should be able to read or alter the data transmitted. Next, I will discuss how SSL provides Authenticity, Confidentiality, and Integrity between client\server communications.
As a security mechanism for client protection, a server must prove its authenticity to establish an SSL session. Malicious attackers have the capability to compromise servers to pose as legitimate websites, in order to lure a client in communicating as a method to steal sensitive information. For example, if I was a malicious attacker posing as http://www.realcomputers.com I could trick users into purchasing non-existent products from my website in order to steal their credit card information. To mitigate this problem server administrators will purchase and install ‘digital certificates’ from a reputable ‘Certificate Authority’ to prove a server’s identity.
Server authentication is when a client checks a server’s identity by validating the information within the server’s digital certificate. SSL client software uses public-key cryptography techniques to authenticate a server. Users often access servers from different machines and for this reason, SSL in most cases don’t require the client to have a certificate. To authenticate a server's identity the client will perform the following checks:
Is current date within the validated period specified on the CA certificate?
Is the certificate issued by a trusted CA? (client maintains a list of trusted CAs)
Does the CA public key validate the issuer’ digital signature? (If any information has changed since the certificate was signed with the server's private key or if the public-key doesn’t coincide with the servers private key used to sign the certificate it can’t be validated and the client will not procced.)
Does server have the same domain name as the domain name specified in the certificate?
If all of the above checks are OK the client will start the SSL handshake process. If not the client is presented with a WARNING and is informed that a secure connection cannot be established.
Servers are configured to use SSL connections to encrypt communication in order to protect the Confidentiality, Integrity, and Authenticity of data.
Authenticity – client is reassured that the data it transmits is to a legitimate server
Confidentiality – encrypted transmissions to protect sensitive information from eavesdroppers
Integrity – ensuring the data sent in transmission has not been altered by an unauthorized party
TLS sometimes referred to SSL 3.1 is SSL’s successor. Both are almost identical where users often use the terms interchangeable. The two are inoperable, they establish encrypted sessions using the same ‘handshake’ process but TLS has new security features. Servers should be configured to use the latest version of TLS which is 1.2 as the default connection method. This is advised because of its enhanced security feature and considering recent vulnerabilities discovered in SSL such as ‘POODLE.’ Most modern day browser supports the use of the TLS protocol.
How SSL Works
Two additional sub-protocols called the Record protocol and SSL handshake protocol work to establish an SSL session. The Record Protocol is used to define the format that will be used during transmission and the SSL handshake protocol uses the Record protocol to format the messages sent from client to server during the initial SSL connection. Messages transmitted between the client and server is used to perform the following:
Authenticate the server to client and on occasions vice versa.
Allow the client and server to negotiate cipher suites that both support.
Use the asymmetric key exchange to generate shared pre-secret and master secret keys
Establish an encrypted SSL\TLS connection
SSL begins with an exchange of messages called the SSL handshake protocol. The handshake uses asymmetric key (public key) and symmetric key encryption. During the handshake, Public keys equip the server with the ability to authenticate itself to the client and ‘occasionally’ the client will authenticate itself to the server. The handshake also provides the client and server the ability to work together to create symmetric keys. Symmetric keys are faster than asymmetric keys so encryption and decryption is much faster, additionally, symmetric keys are used to detect data tampering during the established connection.
A summary of the handshake process is detailed below:
1. The client initiates the SSL handshake session by sending the server a ‘Hello’ message. The client must transmit unique data to the server in order for communication. This unique data includes the client’s SSL version, cipher settings and randomly generated data with additional information needed for communication.
2. The server responds to the client with a ‘Hello’ message specifying its SSL version, cipher settings, randomly generated data, any other data needed to communicate with the client and provides its certificate to authenticate its identity.
3. The client validates the certificate sent by the server. If validation fails then the user is prompted that the SSL connection can’t be established (the user still has the option to proceed using an unsafe connection.) If the certificate passes validation then the client proceeds to the next step.
4. The data generated during handshake is used by the client with the help of the server (depending on cipher being used) to generate a premaster secret (randomly generated by the client) for the session. The client encrypts the premaster secret with the server’s public key and sends the encrypted premaster to the server.
5. The random value generated by the client or (premaster secret) is used to generate a master secret. The master secret is used by the client and server to generate symmetric keys also known as session keys. Session keys are used to encrypt, decrypt and verify the integrity (ensure data has not been altered) of information exchanged during the SSL session.
6. The client sends the server two messages. The first message notifies the server that messages sent going forward will be encrypted with the session key. The second message, which is encrypted, indicates that the client’s role in the handshake process is finished.
7. The server sends two similar messages to the client. The first message notifies the client that messages sent going forward will be encrypted with the session key. The second message is encrypted and indicates that the server’s role in the handshake process is finished.
8. The server’s encrypted message indicating that it has completed the handshake process confirms that the SSL handshake is complete. The SSL session begins and the session keys are used to encrypt, decrypt and verify the integrity of the data sent between the client and server.
Note: In this process, the server ‘occasionally’ requires the client to have a certificate to validate its identity. Client authentication is primarily used as a defense in depth strategy such as 2-factor authentication. This occurs after Step 4 from above. If so, the client signs a piece of data unique to the handshake and sends this data along with its certificate to the server. The server will attempt to authenticate the client using this data and if it is successful then the client generate keys to establish a connection and if it fails then the session will be terminated.