How HTTPS works?

Vikram Rao on SSL HTTPS Security 5th March, 2015 • 3 mins

How does https benefit us? How does it make our internet surfing and transactions more secure? A brief post here that tries to transcend all the areas of HTTPS protocol briefly with pictorial explanation.

What is HTTPS?

HTTPS stands for http over SSL/TLS. It is the normal http protocol but where the transport layer uses SSL/TLS (here in after called simply SSL) encryption to provide necessary security to the conversation.

Why do we need HTTPS?

By default, when using HTTP protocol, all the information we exchange from the browser with remote servers are visible to some one with right tools, as it travels through the internet. So when we shop, the credit card number is visible and gives way for potential mis-use. So do the passwords to various web sites that we send to log-in. Not only do the sensitive information become visible but are also modifiable - what is called MITM (Man in the middle) attacks - such that both server and client might be seeing something other than what was sent. There are two problems to solve here -

1. Make sure that the information sent or received is from the source we believe it should come from.
2. Make sure that the information transmitted is not visible to any one else other than the intended recipient and is not altered in any way.

Encryption

Encrypting the content seems like the logical solution to both the problems above. There are two kinds of cryptography we might use here -

• Symmetric cryptography - Same key is used to encrypt and decrypt the message

• Asymmetric cryptography - Different keys are used for encryption and decryption - also called public key cryptography.

Symmetric cryptography cannot be used easily as the key has to be shared some how with the client and in a public web site, that is a touch task since a secure connection is not yet established and transmitting it over an in-secure connection would enable an imposter to grab that key and masquerade as the server itself.

Asymmetric cryptography would be the perfect solution, but the problem lies in how do we get hold of the server’s public key. If the public key is published in a known location, it still does not solve all the issues mentioned above. For example, while the content might be encrypted, it is still not certain if it is being sent to or received from the right (intended) server. Public key distribution is a big problem and the question always lingers that if the key is the correct key (of the intended server and not from an imposter). Some one with a malicious intent can intercept the public key request and send a different public key (whose private key they would have with them) and then be able listen to and decrypt messages and re-encrypt a modified message and send over to the other end at free will. The way HTTPS solves this is through certificates.

Identity and Certificates

In order to ensure that the communication is happening with the intended server, in HTTPS, the server sends a certificate to the client that not only has its public key but also has a piece of encrypted message (digest) which comes from encrypting a text like “this is from xyz server”. The message is encrypted by a known trustable source whose own certificate is already available to the browser (bundled with it). This source is called a Certifying Authority or commonly CA. A CA’s certificate can be further certified by another CA and so on building a chain of trust. If the browser cannot trust the CA (Does not have its public key), it looks for its parent CA in the chain until the browser can find a CA that it can trust. The root CA in the chain would off-course have a self signed certificate and its public key would definitely be available with the browser as an implicitly trusted CA or else the entire chain would not be trustable. There are handful of such root CAs whose certificates are packaged with http clients (aka browser) like Verisign, Thawte, Comodo, GoDaddy etc. These CAs hold their private keys in secret and guard it well.

If a private key of a CA is compromised then all the certificates signed by it can be faked by an imposter and pass the certificate validation in the browser. That fake certificate would have a its own public key instead of the real public key of the website and that when used for any encryption can be decrypted by the imposter and thus read and modify the communication. If such a rare thing does happen (CA cert compromised), then it’s certificate would get added to a “Certificate Revocation List” (CRL) which is regularly downloaded by browsers. Any certificate issued by that CA would be deemed invalid there on. There is a chance that until that list is downloaded, a compromised certificate can be trusted for a brief period causing un-intended consequences.

Compromise of private key of a CA is rare and is a nightmare when that happens. There have been instances when CA servers have been breached and hackers have issued fake certificates (but not got hold of the private key of the CA itself). There is a case with Comodo (one of the largest CAs in the world), where one of its reseller systems were compromised. Similarly DigiNotor was compromised and it did not even inform the users for a month after the break-in. When the issue became public, it was catastrophic on the company and it went bankrupt in weeks.

SSL Protocol Handshake

Here is a 3 step SSL protocol handshake presented concisely. More happens in these steps, then has been described here, but it gives an idea.

1. Say Hello SSL Handshake begins with client sending a ClientHello to the server with information necessary to execute the handshake including the maximum SSL version it supports and ciphers it can handle. The server responds with a similar ServerHello message.

2. Certificate Exchange The server sends its certificate and is validated by the client. In some case (very rarely) if the server has to identify the client then it might request the client to send its own certificate too.

3. Key Exchange Now that the public key of the server is available to the client (browser) and that the public key is certain to be from the intended server, client sends another key to be used for encryption during the rest of the SSL session to the server. This key exchange is done by encrypting/decrypting the messages using asymmetric cryptography. Only the server will be able to decrypt this message that client sends and thus server gets the new key. Once the key has been agreed upon, the client and server use symmetric cryptography to exchange data hence forth encrypted by this new key, until the SSL session is terminated.

SSL Handshake In Action

HTTPS in public WIFI

Is https communication in public wifi readable by an imposter? The answer is NO. One might read all the data and possibly get to know the size of the data being exchanged, but cannot decrypt it. This is assuming that an imposter does not have physical access to your device, more on which below.

Who can read my HTTPS communication?

There are two ways by which SSL communication can be compromised -

1. If the imposter gets the access to private key of the server or the access to systems of a CA issuing certificates. This is a scenario illustrated above in case of DigiNotor. But a government with muscle and prosecution power can also coax a CA or the server to give away its private key or access to its systems as in the case of Lavabit.

2. Some one with access to your computer (physical or remote), like your company, might install a self signed certificate as a root CA in your system and then intercept all certificate requests, sending its own certificates signed by its self signed root certificate. Since the root certificate from the company is trusted by the system, it passes the check during SSL handshake and your company can read the SSL transmission while both the client and server would never know that it is happening. In all issues of security, preventing access to your computer is very important. This is also precisely what can happen in a coffee shop when you leave your computer un-attended while paying the bill or going to a loo.

Conclusion

SSL provides part of the solution for secure internet transmission but there are other issues that SSL by itself does not address. Bugs in the SSL libraries can compromise the encryption/decryption process and leak information. OS and system library vulnerabilities can also compromise an SSL transmission.

Adios…