How Safe Are Encrypted Websites Really?

Question

I was at a coffee shop and had to (I mean had to) check something on my bank account and another account. I figured since the two websites I was viewing were encrypted, and because my computer (I'm on a Mac) has a firewall, and I don't share through a cloud or such, that my information is safe. Google is encrypted from the moment that you search, and I connected to the actual wifi of the coffee shop (I had to accept their terms in order to do so).

So I was using HTTPS the entire time. I contacted the bank tech support and they confirmed that their whole website is completely encrypted. Same with the other account. Was I safe? There was a person nearby who looked as if he was doing something suspicious on his computer as far as hacking/networking.

Answer 1

I'm an enterprise penetration tester for my company, and breaking into systems is what I do day in and day out. I'll share some of the techniques I use to perform man-in-the-middle attacks, to give you an idea of what to look for (as well as how to defend). If none of these scenarios sounds like something you encountered, then there's a significant majority chance that your encrypted communication wasn't compromised.

HTTPS is only as secure as the dependencies it was built on. In typical circumstances, HTTPS does its job just fine. However, when one of the foundational requirements isn't met, it is vulnerable. Breaking just one of the links in the chain can compromise the communication believed to be encrypted.

Attack using tools such as BEAST, CRIME, and/or BREACH tell us that knowing some plain text in the message being protected allow the encrypted tunnel to be reversed/broken.

Attacks involving the Heartbleed vulnerability are another example of a flaw in the SSL protocol that allows attackers to retrieve data which should have been encrypted.

Attacks using a rogue wireless access point and a tool like SSLStrip show us that just because we typed "HTTPS" doesn't mean it'll be there the next time we look. This is a very simple to implement attack scenario which returns a significantly high degree of success (I typically see ~90% success rate from the penetration tests I'm asked to perform).

Yet another way would be for a hacker (read: not a law-abiding penetration tester) to break into a certificate authority and generate working certificates for sites they wish to intercept communications for. A hacker a few years back who called himself "Comodohacker" compromised multiple certificate authorities, which are the businesses/organizations which issue SSL certificates for the websites we connect to via HTTPS.

Finally, a simple but incredibly effective attack would be to generate a self-signed cert. The cert will "technically" good, but the CA will be untrusted. From a computer user's perspective, all you will see is a message saying that the Cert is good and the CA is unknown, with a yes/no box asking "Do you want to proceed?". In an attack scenario, after the user clicks yes, they would see that the communication channel is HTTPS, but won't know that they are connected to a rogue internet proxy that's intercepting and decrypting traffic. (Note:: This technique commonly used for legitimate purposes as well, such as a corporate SSL proxy scanning all outbound communication for company IP and trade secrets. The difference there is that the org will typically add the signing authority to a list of trusted authorities on the company owned computers to prevent the message box from popping up.)

Of the scenarios above, the CA compromise is the worst one in this list due to it being undetectable directly. For that reason, and also since it's not very common anyway, I don't worry about it. The others are what need to be looked out for.

BEAST and successors are now client side attacks. Most of the vulnerabilities they exploit can be mitigated by keeping your operating system, internet browser, and other software up to date. This has to be done on a regular basis.

The Heartbleed vulnerability was more than just client side. Servers deployments of OpenSSL on every popular website were equally as vulnerable. If you're patching regularly, I also wouldn't worry too much about this one. Most successful attacks against this vulnerability were made against servers owned by websites (i.e. nothing we can do but change passwords).

The last scenario (the self-signed cert) is typically the most dangerous threat to look out for on this list. While there are legitimate uses for the technique itself, I personally do not care. I never click yes when asked to trust an unknown certificate authority, and I'd recommend anyone else do the same.

One side note in case it's relevant - I personally wouldn't use the Safari internet browser. Apple finally patched their browser in November of last year for the BEAST exploits, but it took them more than 2 years after the BEAST exploits were released to do so. Even though Safari is patched currently, I'm concerned about their lackadaisical approach to IT Security.

Answer 2

It isn't the web site that's encrypted (that wouldn't make much sense), but the connection between its web server and your computer.

That's what HTTPS means: secure HTTP, that is, HTTP over an encrypted connection, provided by the SSL/TLS protocol.

So to answer your question: If the connection was over HTTPS and you checked that the bank web site was the correct one, then you were safe. You just need to check the domain as well: Most bank certificates are Extended Validation (EV) certificates which most browsers display differently.

Answer 3

Long story short: your own laptop's physical and OS security, your computer usage and browsing behaviour, who you trust to use your computer safely, your use of passwords, and whether you sat near a reflective surface are all much more important security issues here, than the website's encryption. Generally user behaviour and social attacks are the biggest security risk.