HTTPS != Security

SSL/HTTPS does not necessarily mean security! website screenshot

Look at the screenshot above. Is it a legitimate banking website? A phishing website?

More likely than not it looks like a phishing webpage. Notice the interface — no indication of the banking institution whatsoever. But… the URL — it’s https!

For the record, this is in fact a legitimate website used by TD Bank and its international subsidiaries.

I mean just look at their choice of domain names! Who came up with these?!

If I was to design a Natural Language Processing (NLP) phishing algorithm, probably all of these would be flagged as phishing.

And, as security community we did a sh*t job for decades — we trained the users and their mental model (HCI/UX context) of the world-wide web to believe that anything with SSL/“a padlock icon” and HTTPS:// is secure. And, to pay attention to the address bar. But, we didn’t quite define what we meant by secure. We didn’t distinguish clearly between secure — as in confidential (end-to-end security) vs. secure as in authentic. Because, sometimes SSL could mean both — see below.

Medium’s Extended Validation (EV) SSL ensures both authenticity, that you are on an actual Medium-owned webpage and confidentiality of the data in-transit. Those EV certs are pricey too!

SSL Extended Validation used by Medium

Fast forward today, initiatives like Google’s HTTPS Everywhere and Let’s Encrypt have now made it trivial to obtain SSL certificates at zero cost — for anyone, and the premise has changed. Instead of assuming that “websites with HTTPS are secure (secure as in authentic)”, the assumption has now been shifted to “let’s make all the websites transmit data between them and the user confidentially. (secure as in confidential between endpoints; not necessarily legitimate or authentic).But, how well has this change been communicated to the end-user?

My parents, for example, when looking at an HTTPS:// page would presume they are somewhat secure and looking at the right webpage.

Therefore, Odoo’s assumption regarding using valid SSL certificates to ensure security (authenticity) is only partially valid. Don’t expect users to click the padlock icon and further read the minute details of the SSL certificate either.

I felt like after engaging in a productive discussion with a commentator — who brought up some great points, I had to write this piece up quickly for security awareness. Although, chances it will reach the intended end-users are… slim.

Here’s the original discussion:

The takeaways are:

  1. HTTPS/SSL does NOT mean you are secure: A website could very well be using a legitimately-issued HTTPS certificate for that domain issued by Let’s Encrypt or any CA for that matter. Beyond ensuring that your data transmission between the source and the destination — between you and that website is protected from interception only in transit, the burden to verify whether the very website you are on is authentic or not is upon you — the user.
  2. Phishy-sounding domain names may not always be phishy: As observed in the examples above, those domains are some of the very legitimate domains used by popular banking institutions. And, yes, this makes it difficult to further distinguish between what is phishing and what isn’t.
  3. Open Redirects: I don’t know what to say here. If you read the discussion above on open-redirects, it is rather easy to trick unsuspecting users due to various factors: the legitimate cases when open redirects are used (URL forwarders/redirectors), the confusion arising from “padlock” icon/SSL, and the very names of the domain the user may be redirected to. I think… probably everyone needs a non-existent college-level class on SSL evolution and Phishing methodologies alone.

© 2018. Akshay Sharma. All Rights Reserved.