Think HTTPS is secure? Not always (Part 1)
HTTPS has become more and more ubiquitous. However, few people realize that not all HTTPS connections are equal, and that there are several ways to break them.
In this series of articles I will go over several ways an attacker can try to break HTTPS. The goal is NOT to cover all possible attacks, but the most common to the best of my knowledge.
The challenge
The goal of HTTPS is everything but easy : on a network where an attacker can intercept and modify any message, either establish a secure connection between two parties (who may never have talked to each other before), or detect any attempt to thwart that secured connection.
Man-In-The-Middle attacks (MiTM) are particularly easy to conduct on a public Wi-fi network (hotel, convention, coffee shop, etc.) as you share your local network with complete strangers - who sometimes don't even need to authenticate.
Attack #1: Hope the user just won't care
A few attacks impersonate the Website the victim is visiting, using a fake SSL Certificate. Sure, HTTPS is designed to detect the fraud. But just because the Web browser displays an error doesn't mean users will heed the advise. "I just want to login for a quick change." "I'm sure it's fine."
The browser's user interface also plays an important role. For instance, Chrome pretty explicitly says when it detects an invalid certificate. But the impatient user may be tempted to go past the warning "just to look". And when looking for further information, Chrome provides conflicting messages. One the one hand it says "This page is insecure", but it also says "The connection to this site is using a strong protocol version and cipher suite" and "All resources on this page are served securely." What Chrome really means is that the data is properly encrypted BUT we don't know who owns the key.
The worst browser in that respect may be Safari on iOS. Notice on the screenshot below how the option in bold is "Continue". And once the user has pressed that option, the HTTPS padlock is displayed as if there was no problem:
What about mobile apps?
Sadly, the same thing can happen with mobile apps (and PC apps for that matter). Both iOS and Android SDKs make mobile developers jump through hoops if they want their application to proceed despite an invalid SSL certificate. But some developers just do that, for example for some internal testing (and then forget to remove the vulnerability). When conducting an MiTM attack on my own devices, I quickly found that I could decrypt data sent by an iOS mobile app from a popular Website (to its credit, the publisher was quick to respond and fixed the problem) and the desktop app of a popular device manufacturer (whom I never heard back from)
What HTTPS does not cover
If HTTPS encrypts communication, it does NOT mask the Website you are communicating with. So if you do not want network eavesdroppers to know what Website you are visiting, HTTPS alone won't cut it.
What can you do?
The obvious answer is: don't go past a browser error.
Aside from that, one way to protect yourself is to use a VPN, as it encrypts all communications going in and out of your device. If you are looking for some affordable offers, Cult Of Mac / Cult Of Android regularly resells lifetime subscription to some VPN services (disclaimer: I am NOT affiliated with those sites, nor do I know the quality of the services sold)
In the next article I will talk about another form of attack targeting users.