We all use HTTPS and vaguely understands it as a more secure form of communication. This article is aimed at better understanding of HTTPS and how secure it is.

How HTTP works

  1. The client sends the request for example.com
  2. After getting IP address and making a further request to IP address, client gets a final reply, Hi, I am example.com, and this is the data you asked for [the homepage] The client blindly trusts that the other party is genuine example.com and no one else impersonating it.

** **Two major problems with HTTP

  1. Eavesdropping Eavesdropping can be done by anyone who has access to the medium. For example, if you are in a company who has taken a connection from BSNL. Then data transmitted from your system to example.com through company’s router(s), ISP (say BSNL) router(s) and following a long-chain of routers finally reach example.com. Any of these routers can be utilized for eavesdropping on the data being transmitted.
  2. Man-in-the-middle Attacks DNS translates Domain-names to IP addresses. So, a maliciously configured DNS can route example.com to IP address of an evil server which talks to a client on one side and (say) example.com on the other. In plain HTTP implementation, there is no way of verifying whether we are communicating with real example.com or a fake one.

How HTTPS works

  1. The client sends a request for https://example.com
  2. After getting IP address and making a further request to IP address, the client gets a reply. Hi, I am example.com, My public key is d9 27 c8 11 … It is certified by (say) Verisign Inc. [and a lot of other things like when it expires etc.]
  3. The browser verifies[pdf] the key to ensure that it is issued to example.com and is not tempered.
  4. Then it uses this public key to encrypt a secret key and sends the secret key(encrypted) to example.com [this key will be used for encrypted communication using symmetric key encryption]

How HTTPS solves the problems

  1. Eavesdropping is solved since the communication is encrypted before transmitting any sensitive data (say username/password to example.com)
  2. Man-in-the-middle is solved if and only if we trust the certifying authority(CA), eg. Verisign for the verification. (Here is an underlying assumption that HTTPS algorithm is not breakable and its implementation is not having any flaw)

So, the safety of HTTPS primarily reduces to how trustable are the Certifying Authorities [which our web browser recognize] “Who are these certificate authorities? At the beginning of Web history, there were only a handful of companies, like Verisign, Equifax, and Thawte, that made near-monopoly profits from being the only providers trusted by Internet Explorer or Netscape Navigator. But over time, browsers have trusted more and more organizations to verify Web sites. Safari and Firefox now trust more than 60 separate certificate authorities by default. Microsoft’s software trusts more than 100 private and government institutions.” [/source]

Now, as EFF has pointed out that how big a mess is this certification process especially since a few certifying authorities have delegated their task of certification to some not-so-trustable companies like Etisalat, UAE.

So, for example, if someone sitting in Dubai or now even in India accesses the Internet through the network owned by Etisalat, who once installed spyware and copied emails of all BlackBerry customers to private email addresses. The routers can redirect a person visiting example.com to a malicious look-alike website and since it shows a valid certificate[with its own public key not the actual public key of example.com]. It will appear genuine and will not raise any flags in the browser. As pointed out, Commercial products based on getting forged certificates already exist.

Note:

  1. For the paranoids, there is a Firefox addon which warns the user if a website presents a certificate different than last time.
  2. The ideas presented are simplified for the sake of understanding, the actual implementation are more involved but based on the same ideas.