Transport Layer Security (TLS) more commonly referred to as SSL, which is it’s predecessor, is a protocol for encrypting network communication. Whether we realize it or not we use SSL/TLS every time we open our browsers. Website owners and operators have an obligation to ensure they are protecting their user’s data by requiring strong encryption for all internet communications.
Establishing TLS encrypted communication does more than protect private data from eavesdroppers, it also detects if there were any disruptions or modifications to the data in transit, and more importantly it offers you assurances that the other party you are communicating with is who they claim to be.
This trust is established via the exchange of certificates between your computer, the server, and a trusted 3rd party the Certificate Authority (CA). Your browser has a predefined list of CAs that are known trusted sources for verification. In order for a server’s certificate to be accepted by your computer it must be digitally signed by one of these trusted CAs. This happens silently in the background as part of the TLS handshake (see below).
For most people the only indication they have that are using TLS encryption is the lock indicator on the browser address bar. Another indicator is that the protocol in the address bar will be https:// as opposed to http:// for unsecured communication but most modern browsers hide this by default, so it is less obvious now.
Clicking the lock will give you more information about the security and allow you to inspect the webserver’s public certificate:
The webservers certificate will contain within it the public key of the webserver. This public key, along with the webservers private key form an asymmetric key pair. What is encrypted with the public key can only be decrypted by the private key, and vice versa. This is critical in establishing trust by proving identities.
CAs will use their private key to add a digital signature / encryption to the certificate, which anyone can decrypt with the CAs public key. Because only the CA has access to that private key it proves the CA has verified the contents.
The public / private key asymmetric encryption is also used during the handshake for the client and server to create and exchange a session key.
When a client initiates communication with a server it sends a CLIENT HELLO message. This includes the URL of the website they are trying to reach, TLS versions and a list of ciphers they have available, as well as some random data to be used for session key generation.
The server responds with a SERVER HELLO message which contains the selected TLS version and cipher chosen by the server and some random data to be used for session key generation. If there are no commonalities among the versions or ciphers available to client and server then communication ends here unsuccessfully.
The server then responds with the SERVER CERTIFICATE for the client to verify with the CA and provide the servers public key as described above.
Both sides, using the random data from the hello messages, will generate a new, temporary public and private key, after exchanging the temporary public keys, each side will encrypt the others temporary public key with their own temporary private key which will create a symmetric session key; each side will be using the same key for encryption / decryption.
To ensure there has been no tampering with the process the client sends a HANDSHAKE FINISHED message which contains an encrypted hash of all of the messages so far.
The server responds with its own HANDSHAKE FINISHED along with the verification hash
The Client can now start sending encrypted data…
As mentioned above, TLS is the protocols for exchanging encrypted communications. The actual encryption is accomplished by algorithms called ciphers. Every weberver and browser have their own lists of ciphers that are available, and every version of TLS also has a list of which ciphers are strong or weak. Many browsers and webservers default to only allowing strong ciphers. The cryptographic strength is measured in bits, as in 128 bit, or 256 bit encryption. This means there are 2128 or 2256 possible keys respectively. 2128 is 3.40e38 or 340 undecillion.
The fastest super computer reported in 2019 it could calculate 1014 keys per second, to check every possible key by brute force would take 1.07e17 years. For comparison the age of the universe is 1.38e10. Also it is worth noting that 256 bit encryption is not twice as strong as 128 bit encryption, that would be 129 bit encryption. 256 bit encryption is 2128 times as strong as 128 bit encryption, and would take 2128 times longer to check every key. Realistically though you can estimate you will stumble across the correct key in about half that time.
Given the enormity of the task in brute forcing this encryption attackers instead look for other vulnerabilities in the algorithms or protocols involved. There have been a number of significant vulnerabilities discovered that weaken or break the security of TLS communication. Here of some of the more notorious exploits:
BEAST (Browser Exploit Against SSL/TLS)
An attack against TLS v 1.0 and older SSL versions. BEAST allows a man in the middle of the TLS communication to attempt to crack a cipher block one byte at a time, each block is 16 bytes long, normally this would take 25616 (2128) but BEAST allows the attacker to manipulate one byte at a time. Reducing the complexity to 256 for any byte. BEAST is technologically complex; it requires the attacker to already be in a position to perform man in the middle attacks and only works for highly predictable plaintext, like html code.
CRIME (Compression Ration Info-leak Made Easy)
CRIME exploits the data compression techniques in SSL / TLS. By forcing a user’s browser to send increasingly redundant information and observing the resulting size of the request the attacker will know when they have guessed a byte correctly.
Heartbleed
Heartbleed is a side channel attack against the popular openssl library used in most webservers. Versions 1.0.1 through 1.0.1f were affected. The heartbleed attack leaked information that was stored in the server’s memory at the time. This could leak cryptographic keys and other sensitive data.
