Lately a lot of people have been asking the question – whether their private message on the internet could be decrypted by a third-party if the latter intercepted their internet traffic?
The past few days, on several occasions, the former CEO of Mauritius, when addressing to journalists, he alleged that the private messages (email, Facebook, etc...) could be decrypted by someone who intercepted the internet traffic at the Baie Jacotet Submarine Cable Landing Station. This statement has been blown out of proportion and to add more fuel to the fear mongering, some IT expert who intervened in a radio programme even said that during a penetration testing exercise, data captured can be decrypted using "some software".
In order to understand whether the encrypted internet traffic can be decrypted by someone who sniffed your ISP's network, we should first understand how cryptography works with internet communications. So, let's dig.
If you're interested in the cryptography part only, then head to lesson no. 3 directly.
Two weeks ago I published a blog post explaining about Internet Protocol (IP) addresses and network packets. I explained how every file transmitted on the internet is first broken into pieces called packets and each packet has a header and payload.
Internet Protocol (IP) packet headers contain the source and destination addresses. When all the units of a packet reach their destination and are reconstructed into one data packet, the receiving device needs to know what application should handle this packet. This is what the Transmission Control Protocol (TCP) does.
TCP's role is to ensure reliable transmission of packets. TCP is used on top of the Internet Protocol and they are commonly referred to as the TCP/IP suite. When a packet is sent over the internet, the data portion of an IP packet is wrapped in a TCP segment.
Thus, the data packet now has the additional information about source port number and destination port number. Before we understand what is the meaning of these two additional source/destination values, let's have a look at how a TCP connection is made between two devices.
Because packets can sometimes get lost in a network, TCP has to establish a reliable connection between two devices. These two devices can be a smartphone and the facebook.com server for example. TCP ensures the reliable connection by doing a three-way handshake. What does that mean?
The above image shows the TCP header with the ACK and SYN bits in red. These two bits are turned on and off to start the three-way handshake. The smartphone sends a packet to facebook.com with the SYN bit on. This basically means that the smartphone wants to synchronise with the facebook.com server. The server will respond by sending back a packet with both the SYN and ACK bits on. Upon receiving this, the smartphone will send another packet to the facebook.com server with the ACK bit on. The successful delivery of these packets concludes that each of them are able to establish a reliable communication and thus a TCP session starts between the two devices.
SYN means synchronise, ACK means acknowledge and when I say the bit is turned on, I mean the value of this bit is 1 instead of zero.
Once a TCP session is established, data packets can be sent back and forth for communication.
Quick recap, the IP header contains the source IP address and the destination IP address, while the TCP header contains the source port number and the destination port number.
These port numbers refer to application layer protocols. A web server, like Apache, serves webpages using the Hypertext Transfer Protocol (HTTP) over the TCP port 80. The same web server will use the Hypertext Transfer Protocol Secure (HTTPS) protocol over the TCP port 443.
Therefore, when the smartphone establishes a TCP session with facebook.com and sends a request to visit https://facebook.com, the TCP packet will check the destination port and deliver the packet to the web server listening on TCP port 443.
However, in order for Apache to deliver a secure transmission it makes use of another protocol called the Transport Layer Security (TLS). Here comes encryption!
The Transport Layer Security (TLS) is a cryptographic protocol designed to render our internet communication secure. It does so by encrypting our internet traffic.
Encryption is the process of converting human readable plain text to completely incomprehensible text.
The above diagram depicts a symmetric encryption process and perhaps a lot of people are thinking that encryption of messages on the internet occurs this way. Thus, someone getting the « key » could basically decrypt all encrypted messages. Encryption of internet communication is a lot more complex that this.
TLS 1.0 was defined in RFC 2446 back in 1999. Currently, the latest recommendation for TLS is to implement version 1.2 and 1.3 and to completely drop the use of the Secure Sockets Layer (SSL) protocol, the predecessor of TLS.
Despite the deprecation of SSL, it still lives in the security jargon and is found in the names of major security-related applications, e.g OpenSSL, SSL certificate providers etc.
An RFC is a document that contains technical specifications for the internet. RFC documents are produced by the Internet Engineering Task Force.
Let's talk about TLS encryption now.
Encryption of internet communication over HTTPS is achieved by applying the TLS protocol using a combination of symmetric and public-key cryptography.
In symmetric cryptography the key to encrypt and the key to decrypt is the same, whereas in public-key cryptography the encryption and decryption keys are different.
To better understand public-key cryptography, have a look at the above diagram. Then, imagine someone communicating on Facebook. The way the encryption works here is that Facebook has two keys – a public key and a private key. The private key is stored on the Facebook servers and it is never shared or transmitted on the Internet while communicating with Facebook.
Facebook sends its public key to a user, using which the latter can encrypt a piece of information and send back to the Facebook servers. This encrypted information cannot be decrypted using the public key again. It can only be decrypted using the private key that only Facebook holds.
If someone intercepts the internet traffic and gets a copy of the encrypted information intended for Facebook, then that person cannot read the actual information. The captured data will be useless.
Symmetric cryptography is fast. It can complete an operation within nanoseconds. Public-key cryptography is slower, taking microseconds to milliseconds per operation.
Therefore, TLS uses both to ensure that data transmission is secure, reliable, cannot be decrypted in trasit and at the same time transmission is fast.
It does so by initiating a public-key exchange to securely share a secret key. That secret key is then known only to the user and the receiver, e.g Facebook. The use of public-key cryptography for sharing session secrets (keys) ensures that the secret won't be captured and decrypted while in transit. Thus, further communication between the user and Facebook can be done using symmetric cryptography once the shared secret is exchanged using public-key cryptography.
The strength of encryption depends on the cipher user. A cipher is an algorithm that performs that actual encryption. A cipher itself is based on mathematical formulae. For example, the Diffie-Hellman key agreement algorithm is considered a major breakthrough in cryptography. It is widely used in public-key cryptography. Weak ciphers can be broken using fast computers. It's very common for organisations to carry out a vulnerability assessment of their IT infrastructure to find such weaknesses and apply the industry best practices.
So far we've seen how TLS sessions ensure secure communication. But what about trust? How can we be sure that the server presenting itself as facebook.com is actually Facebook's server and not a cybercriminal diverting the internet traffic to another server that pretends to be Facebook.
This is achieved by establishing a chain of trust through a Public Key Infrastructure (PKI).
A Public Key Infrastructure governs the issuance and management of digital certificates. These certificates follow the X.509 standard for public-key certificates defined by the International Telecommunication Union (ITU).
What you should know about this is that there are organisations called Certificate Authorities (CA) and they issue certificates to other organisations who need to certify their domain names as secure. These CAs are recognised by the operating systems (e.g Microsoft Windows, Apple macOS, Linux distributions) and browser makers. Therefore, when a certificate is presented by a web server to a browser, ascertaining a domain name, the browser looks at who issued the certificate first. If that Certificate Authority is in its trusted list then only it'll trust the website and display the secure padlock in the address bar.
Otherwise, the website or application throws an error and complains about untrusted connection.
In Google Chrome, if you click on the padlock, then click Connection is secure > Certificate is valid, a window pops up showing the details of the certificate, like when it expires and which Certificate Authority issued the certificate.
In the above screenshot, you can see that the certificate was issued by DigiCert intermediary CA for the facebook.com domain. DigiCert is also the Root CA in this chain. Google Chrome trusts the DigiCert Root CA and hence trusts the chain that follows.
DigiCert verifies the domain ownership before issuing certificates. It's not like anyone can just buy a certificate for any domain on the internet.
Therefore, if someone else generates a certificate for facebook.com and presents itself as facebook.com to Google Chrome, then the latter will prompt the user that the website cannot be trusted.
Finally, in this blog post, if you read the whole of it and the one I wrote about network sniffing, then by now you must know how secure internet communications occur and why it is not just something that one can break or decrypt.
Therefore, summarising it, remember that the Internet Protocol (IP) is responsible for addressing on the internet. It specifies the source and destination address of packets. These packets are able to travel the world and reach their intended destination reliably thanks to the three-way-handshake defined in the Transmission Control Protocol (TCP). To secure the communication over TCP, web servers use the Hypertext Transfer Protocol Secure (HTTPS) and Transport Layer Security (TLS) to encrypt information using a combination of symmetric and public-key cryptography. The strength of the encryption depends on the cipher that is used. Lastly, X.509 formatted certificates are used to help browsers and mobile applications trust the domains that host the websites and other content on the internet.
I created the cryptography diagrams using Figma and images from flaticon.com.