HTTP downgrading attacks with sslstrip

There once was a magical time for the sniffing hacker – a time when only certain websites were protected with SSL sessions, so most browsing took place via easily intercepted and easily mangled HTTP packets. We could sit in a coffee shop and casually listen to the environment, sipping on a latte while watching URLs and content requests fly by. If we felt like being pranksters, we could use Ettercap filters to replace any JPG in a request with one of our choosing – sometimes a picture of a cow, or sometimes it was something more sinister.

It didn't take long before the industry noticed that some unpleasant individuals were sitting in coffee shops and replacing all the JPGs with pictures of cows, and as Wi-Fi, in particular became far more ubiquitous, technologies designed to provide a high level of confidentiality for even innocuous browsing became the norm.

Some of those coffee shop cretins simply started conducting SSL man-in-the-middle attacks. Normally, when a browser tries to establish a secured connection to a site, a certificate is transmitted that will prove the identity of the site. The certificate will have a digital signature on it, and as per the principles of public-key cryptography, we can verify the signature was generated by the true keeper of the private key. It's a sound principle, but for a while, the average end user was only looking for the https part in the address bar and not actually checking the signature. So, a proxying attacker can merely issue his or her own self-signed certificate, and then establish a new encrypted session with the target site using the legitimate certificate. It didn't take long before the industry saw that end users weren't noticing the bad certificates, so newer versions of all the popular web browsers started displaying very scary-looking warnings if any certificate issues were detected. Whereas it used to require an expert to know not to load a particular site, today it requires several well-placed clicks to load a site with a bad certificate (regardless of the actual reason for the problem). In my experience, I could only get away with the SSL man-in-the-middle attack in corporate networks between users and internal consoles that used self-signed certificates (for instance, the web interface for a security appliance); in this scenario, the user was already used to seeing the warning and clicked through out of habit.