TL;DR – Over the past few years, Internet users have been brainwashed into thinking SSL guarantees their safety and privacy. This is only partly true.
Sorry for the click baity title but this is an important topic. My recent conversations with friends and family led me to believe that most people associate HTTPS with absolute Security and Privacy. People tend to place faith in the friendly green SSL lock symbol on their browser. However, I realized that most people don’t really understand what SSL (https) guarantees. This post is dedicated to clearing that up for people who may not understand the nitty gritties of how SSL function and what it guarantees for a user’s Security & Privacy.
Let’s begin with understanding how the web came to be. In the very beginning, Computer Scientists and Engineers built systems that could talk to each other using analog signals. Later converted to digital signals. This was a very important change as it allowed very easy and quick development of higher level applications without changing the underlying circuits.
When the Internet was invented, it was different than most other conventional communication networks because it relied on a distributed network of nodes. These nodes could interoperate i.e. talk to each other as they all spoke standard protocols.
To achieve interconnectivity, each node on the Internet plays an important role. Packets of data would flow from the origin to destination nodes through intermediaries. These intermediaries participate in building the “Internet” and if they’re not the destination of the packet, they route it to a node that could help your packet reach it’s destination. This is the basis of the Internet even today.
The key takeaway here is to realize that when your computer is talking to a website, it is not directly physically connected to that website’s server. Your computer is talking to your ISP’s (Internet Service Provider’s) servers that are in turn talking to potentially hundreds and thousands of servers on the Internet to get your packets to the final destination.
In the course of reaching your destination your packets are probably handled by atleast 10s of servers. These packets are easy to read unless they’re encrypted!
You can easily find out the intermediate nodes between your computer and a website. Each line in the output below is a node on the Internet that helps route my packets to Google.
11:52 $ traceroute google.com traceroute to google.com (18.104.22.168), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 1.725 ms 1.675 ms 0.814 ms 2 22.214.171.124 (126.96.36.199) 10.422 ms 10.138 ms 10.144 ms 3 be-10009-sur03.sanjose.ca.sfba.comcast.net (188.8.131.52) 11.229 ms 11.320 ms 10.268 ms 4 be-231-ar01.santaclara.ca.sfba.comcast.net (184.108.40.206) 11.118 ms 10.448 ms 10.554 ms 5 be-33651-cr02.sunnyvale.ca.ibone.comcast.net (220.127.116.11) 14.141 ms 14.035 ms 13.659 ms 6 be-11025-cr01.9greatoaks.ca.ibone.comcast.net (18.104.22.168) 17.474 ms 14.338 ms 12.968 ms 7 be-12582-pe02.11greatoaks.ca.ibone.comcast.net (22.214.171.124) 12.879 ms 12.049 ms 11.414 ms 8 as15169-3-c.11greatoaks.ca.ibone.comcast.net (126.96.36.199) 12.076 ms 11.860 ms 20.062 ms 9 188.8.131.52 (184.108.40.206) 13.125 ms 220.127.116.11 (18.104.22.168) 12.962 ms 22.214.171.124 (126.96.36.199) 14.465 ms 10 188.8.131.52 (184.108.40.206) 12.900 ms 247.506 ms 220.127.116.11 (18.104.22.168) 95.563 ms 11 sfo03s06-in-f238.1e100.net (22.214.171.124) 13.361 ms 13.605 ms 12.515 ms
SSL in Practice
Until very recent, most big websites would use encryption to secure communication only for the most sensitive content like your email, bank accounts and financial transactions. But as most websites and apps require login and have some sort of personal data, many providers started encrypting every communication. This was a combination of protecting the user’s privacy as well as business interests (It’s a long and boring topic that I won’t go into right now).
Anyway, now that you understand that your communication is being routed through hundreds of nodes meant that it is open for inspection by any of the nodes that carry your packets. SSL only tries to protect against it. It establishes an encrypted session that obfuscates the contents of the packets but intermediate nodes still know the origin and destination. The way Internet is designed, you can’t really hide these addresses. You can potentially hide the “From” address if you don’t care about getting a response back. Anyway, for all practical purposes it’s impossible to hide the origin & destination.
Now that we’ve established that SSL only prevents intermediaries from snooping on the contents of your packets. Let’s come back to my original concern – the false sense of security it instills.
SSL Certificate Types
What most people don’t know is that there are different kinds of SSL Certificates – Domain Validation (DV), Organization Validation (OV) and Extended Validation (EV). Not all SSL certificates are equal. For instances DV certs are obtainable by anybody without any identity proof. OV & EV are harder. EV is hardest to obtain as it requires genuine paperwork. These are the most “secure” form of SSL certificates. However, most businesses do not obtain such certificates. At this time, I think other than Financial institutions like banks, brokerages, most sites on the Internet do not go through the necessary steps to obtain EV SSL certificates.
The browsers don’t do a great job in pointing out the differences between these certificates either. For example, DV/OV and EV certificates are displayed differently in the browser’s address bar. See below.
Here’s how Chrome displays DV / OV cert:
Here’s how Chrome displays EV cert:
But to an average user, what does it actually mean? In my limited sample set, users tend to treat the lock symbol equally. They think that some sites do a better job of displaying their name in the address bar. They cant tell the difference between the DV/OV certificate and EV certificate. They usually think that as long as the address bar shows ‘Secure’ & has a green lock, they’re the same thing. This was a very interesting and little scary find for me personally as there could be a world of difference between security practices of organizations. The browsers don’t do a good job of highlighting these differences and/or educating the user. In fact they actually exacerbate the problem by displaying them almost exactly the same barring one minor difference.
Time and again several websites that use SSL have been “hacked” and lost sensitive private user data, passwords and other information. There have been several data breaches in the recent past. An average Joe / Jane don’t really care the kind of SSL certificate that a website is using. They care about their safety. SSL certs do guarantee privacy & safety during transport with some caveats (See below). EV certs add a boat load of credibility around a website’s claim in it’s relationship with a business. However, it still does not give any guarantee around it’s data handling practices.
SSL Safety & Privacy Caveats
With the rise of SSL, IT organizations have started using SSL Interception proxies to monitor SSL traffic. They can fully decrypt and read it in plain text. It works because IT departments can install a Trusted Root on all IT issued machines. What this really means is, if it can work for your IT department, it can work for the Government or malicious attackers.
In closing, SSL is a big topic and overall it is better for everybody but it still has it’s flaws. My underlying point is, don’t trust SSL blindly. Just because you see the secure symbol on your browser doesn’t mean that the website is handling your data securely. Learn to distinguish between EV & DV/OV certs. EV certs at least guarantee some genuineness in the website’s claims.
P.S.: If you find factual inaccuracies in this article or have something else to add, please do comment and let me know. I will be more than happy to discuss it and update it.
Latest posts by Dinesh (see all)
- SSL is not secure! - August 13, 2017
- ESP8266: Snooping the I2C Bus for devices - July 31, 2017
- 10 easy steps to build MicroPython on macOS for ESP8266 - July 26, 2017
Also published on Medium.