What is HTTPS?

If you are not keen of technical details, you may just skip to the next section where the strengths and weaknesses of using HTTPS are discussed. If you are a geek you may add up to this article by looking into the resources provided at the end of the article or just by finding more information on the Internet.

Getting down to our business: what is SSL, or what is going on when we enter a URL like https://somewhere.in.the.net? Leaving out network details

1) A client sends a signal to a web-server telling him: “Hello Mr. Server. I’d love to talk with you about something, but, hush! Firstly, we need no one to listen to our conversation and, by the way, how can I be sure you are Mr. Server and not Mr. Hacker?” Going into that some deeper we can see that your browser negotiates encryption protocols it can use with the server. So it does for many other parameters. Everything here is going in open, so no information critical to the client or the server is passed.

2) At this step both peers also exchange a shared secret which is later used to create encryption keys. This information is encrypted and decrypted with the public/private key pair, so this part of data exchange is ciphered using asymmetric key.

3) Next, the client (i.e. browser) receives from the server some information which proves that this is the server client wants to be connected to. This is, leaving out some wicked cryptography and mathematics, an open key of the server, which may be validated by the client using the preconfigured trust list together with even more complicated math. Generally speaking the open key of the server has to be signed by a certificate which the client trusts already. Those who want to know more may try to look for “Certificate Chain Validation”. Besides checking if the certificate is issued by a trusted authority it goes some other checks like if the certificate was issued exactly to this server. At this very point the client may authenticate himself to the server if it wants to. This exchange is also protected by asymmetric keys.

4) The next step is to construct a symmetric key (that is the key which is the same for both sides) from a data received during the previous steps and then the actual data exchange begins.

Of course all that is much more complex (for example the full description of the Microsoft implementation of the protocol, what and how it does takes more than 40 pages) but what stated above can deliver the very basic understanding of what is going on when someone connects to a secure server.

Really, due to item 3 we have strong belief that our browser talks to the server we want. And everything is ciphered with good enough protocols to be sure that no one is eavesdropping our conversation. Why not to celebrate the resounding victory over hackers of all shapes and sizes? There are reasons for this, unfortunately.

Firstly, if user is working from a computer which is not under the user’s control, suppose it is in an internet cafe or is contaminated with a virus, then user cannot be sure in answers to any of the following questions:

1) Who is on the other side of his communication? Really, if it is not yours computer you cannot know what changes were made to its software. You cannot be sure that the list of trusted certificates on this computer is intact and don’t contain any unauthorized by you changes. So your computer may occur to trust any of hacker sites.

2) Is the user’s traffic being eavesdropping? If it’s not a computer of yours or it is contaminated then there are different possibilities to read your data exchange:

1. There may be installed key loggers which are able to read your data input from the keyboard, including web-bank credentials if your bank accepts them as a keystroke.
2. There may be installed a software which reads data before it gets encrypted or after it is deciphered.
3. If your trusted root certificates are modified you may become a subject to so called HTTPS forward inspection, which provides the hacker with the possibility to read traffic between you and your “secure” server.

3) Is that really the server user wants to communicate with? Again, your trusted certificates list may be changed and even connecting to the rogue server you won’t receive any warnings.

So the solution is obvious: do not work with important information on the computer which doesn’t belong to you, be careful about viruses and do not let anyone to access your computer. But there are threats even to people understanding and following these rules:

1) The user can go to the wrong site, typing it with a mistake or following rogue link. Suppose you go to https://www.mlcrosoft.com – it’s not always easy to distinguish it from https://www.microsoft.com which is the right URL. And mlcrosoft.com (with L instead of i) may belong to the hacker, who bought a proper certificate to the site. Proper does mean that it registered to mlcrosoft.com and is issued by a trusted certification authority like VeriSign. So if you go to the fake site you won’t be given any warning and may easily to post you credentials or your data to the hacker.

2) The site itself may be hacked even if it is really an official one. So even accessing the right site with a proper certificate you may receive harm from it.

3) Even your own computer may be contaminated by virus which prevents the protection from protecting anything.

So take care of your data and try to follow simple rules at least when you are working with a sensitive data:

1) Do nothing with the sensitive data on computers which don’t belong to you.

2) Do not allow other people to get physical access to your computer or access with administrative privileges over network. From the rule follow the necessity to keep strong password, install and maintain some firewall solutions, etc…

3) Protect your computer as long as it is possible from malware.

4) When accessing the site always check the URL thoroughly. Most of modern browsers help to do so by highlighting the high-level domain name of the site so that you now clearly see that you are accessing www.microsoft.com.hacker.com rather than www.microsoft.com.

5) Do not ignore ay warnings about certificate checking errors. Some of them tell you that the site is, at least, configured wrong.

RFC 2246: The TLS Protocol

Description of SSL/TLS implementation by Microsoft