Online security is a critical necessity in today’s world where everything seems to be connected with everything else. And in this highly connected world, the amount to data that gets transferred through the internet is simply staggering. But the data that is sent across this information highway is not always secure. Robert Love in one of his quora answers compared internet to a shared pipe and a postcard. Quite apt. Your personal data is sent as plain text on channel that you share with numerous people.
So a technology was required that kept data private, provided authentication and integrity for the IP packet. In walks SSL/TLS. Secure Sockets Layer and its successor, Transport Layer Security have been in place since the mid to late 1990s. It has been continuously revised and newer versions have come with TLS 1.2 being the latest.
There have been a couple of major TLS bugs in the past month (not a bug in the protocol, but the implementation thereof). The Apple TLS bug has been well documented. The CN (Common Name field) of Server’s x509 certificate wasn’t authenticated and it made Apple products vulnerable to servers with fake certificated. The GnuTLS bug “prematurely terminates code sections that are supposed to establish secure TLS connections only after the other side presents a valid X509 certificate signed by a trusted source.” [Arstechnica]. In essence, this bug resulted in a situation where the communication between two parties wasn’t encrypted using TLS.
So How Does It Work?!
Well, SSL/TLS is simple enough to understand, given a bit of background knowledge. Most of today’s online security depends on the difficulty of factorizing the product of two large (very large!) prime numbers . These large primes numbers and it’s product give us KEYS for encrypting data on the internet. Encryption can be of two types really :-
- One key for encrypting and decrypting the data. This would mean both the client and the server share a common key before they start data transmission. This is called symmetric cryptography. Eg. DES, 3DES, AES. The advantage for this method is that it is easier and faster. The downer is how do you share the key before hand?! Surely it can’t be plain text share, because that defeats the whole purpose.
- Two keys, one public and one private. The server’s public key is known to everyone while it’s private key is a secret. These keys are functionally inverse. That is, data encrypted by one key can be decrypted by the other key. This is called asymmetric cryptography. The advantage is there is no key exchange as one key is already known while the other is always a secret. The disadvantage is that this is slower and resource intensive. Eg RSA, DSA etc.
SSL/TLS uses a combination of both the above methods to work in a secure yet fast way. When the TLS session is brought up, Public key of Server is sent to Client and hence asymmetric cryptography is used to establish a secure connection. Then a number called the pre-master key is exchanged. This exchange is encrypted using asymmetric cryptography. Both Server and Client, independently, generate a master key. The master key is never sent on the link. Both Server and Client use the master key to do further data encryption using symmetric cryptography. Thus the initial handshake is done using say RSA, while further data encryption is done via AES. The key used by AES was exchanged via RSA encryption. Simple enough?
But how do you know whether the keys that you received were from the Server you wanted to contact to, and not some bogus keys by someone trying to hijack your session. That is where Certificates come in. More specifically x509 certificates. The way x509 certificates work depends again on public and private keys of the server. The x509 certificate consists of Server details (encrypted using server’s private key) and the server public key. The client can decrypt the certificate data using server’s public key and check if the certificate is authentic. [No one else except the owner of the corresponding private key could have encrypted the certificate. Thus you know the public key you have does indeed correspond with the private key of the server] . Most servers get their certificates signed by a central authority called the Certification Authority(CA). Browsers trust a bunch of CAs and if your certificate is signed by these CAs, the browser is very happy. If it isn’t, the browser will tell you that the server wasn’t authenticated and might not be who they say they are.
The google server sends a valid certificate and also mentions that data authentication happens using 128 bit AES while key exchange happened using Elliptic curve Diffie–Hellman Ephemeral DSA ie. the asymmetric cryptography is DSA and symmetric cryptography is by AES.
Let’s Try This Out
To understand how SSL/TLS works, I setup an https server(Basically SSL/TLS over HTTP) and did a packet capture. The https server was simple enough to setup in python. All you need is a certificate and private/public key pair. I used OpenSSL to generate both.
openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
This results is a cert.pem file that has the following structure
-----BEGIN RSA PRIVATE KEY----- #your private key -----END RSA PRIVATE KEY------- ---BEGIN CERTIFICATE----- # your certificate -----END CERTIFICATE-----
Using this cert.pem file, and python, I setup a rudimentary https server.
#!/bin/python3 import http.server import ssl IP = '192.168.67.141' HANDLER = http.server.SimpleHTTPRequestHandler httpd = http.server.HTTPServer((IP,443), HANDLER) httpd.socket = ssl.wrap_socket (httpd.socket, certfile="cert.pem", keyfile="cert.pem", server_side=True) httpd.serve_forever()
Start the server using nohup python3 https_server.py &
Once the server is up and running, access the server using your browser. Say “https://192.168.67.141:443“. Your browser will alert you about a security threat since it doesn’t recognize the certificate as it is self-signed.
Packet Capture of TLS
I captured a complete handshake in Wireshark.
After the 3 way handshake between client and server (SYN, SYN-ACK, ACK), the client sends a “Client Hello” where is sends its own details. It also sends a list of cipher suites it supports. Like TLS_RSA_WITH_AES_256_CDC_SHA means RSA for key exchange, AES for data encryption and SHA as a hash function.
The server replies with a TCP ACK that it has received the data. It then sends a “server hello”
The server tells the client that it is comfortable with TLS_RSA_WITH_AES_128_GCM_SHA256 cipher suite. It also sends its certificates which has fields like Common Name, Organization etc. When the client checks the certificate and is happy with it, we move on to “Client Key Exchange”
The Client sends a pre-master key encrypted with server’s public key. This pre-master can be decrypted only by the server since it alone has the private key. Now that both have a pre-master key, they can generate a master-key for 128 bit AES independently. Thus key got exchanged in a secure manner and now data encryption will happen with a faster AES using that key.