Jacob Baytelman - CTO, founder, blogger
HTTPS and Privacy
3 days ago I tweeted a few provocative thoughts regarding TLS (transport layer security), HTTPS (secure hypertext transfer protocol) and privacy. I could have never expected such an attention from security experts and those who believe they are.
To my big surprise, many techies lack understanding of privacy and actually sink in a mixture of privacy, security and safety concepts. Most popular statement: if we encrypt data in transmission, we gain its integrity and even ensure privacy. The argument: https (encryption of data in transit) protects from MITM (man in the middle) attacks.
True, and though MITM attack is only one of many risks and https has its own flaws, the real problem is this: encrypted transport does not necessary mean encrypted storage after delivery, it has little to do with compliance to privacy regulations or devotion to privacy ethics.
I wonder who of my pro-encryption opponents encrypts data in their databases - because of the hurdles with search queries, who salts hashes, who encrypts images in file storages, I can continue the list.
Techies know that TLS is nothing more but a technical means to solve one single task, namely encrypt data in transit, but they rarely understand that TLS is unreasonably believed to magically cure a whole bunch of other problems. End users are not technically savvy, when they see "Secure" message in the browser, they believe their data is safe always, not only in transit. So false expectations are created.
Google's Chrome helps fostering such false expectations and general user ignorance. Google tries hard to resemble a privacy advocate, the easiest way for them to do it appears manipulating with grammar constructions and design. A lot of my opponents think this message means "your information is private during the transmission". I wonder how well they did at school (perhaps I was unusually lucky with my English teachers and expect too much from others) and why they do not see the difference between "when it is sent" and "when it is being sent". I reiterate it once more - correlating privacy with encryption creates a false sense of safety and move other critical issues out of focus. Sometimes such hidden issues have dangerous consequences.
Google wants all websites to be accessible via HTTPS. No doubts, HTTPS is a must for websites where users input sensitive data, e.g. passwords or credit card details, because HTTPS encrypts traffic from users to the server and vice versa. Here lies the real importance and the main task of secure transport: users' input must be protected by all means. HTTPS was designed to protect requests from clients to servers: our passwords, credit card details, commands to the bank to transfer funds, etc. Albeit no decent bank or other online service relies on HTTPS only: now industry standards require 2 step authentication in conjunction with location checks.
What about static websites? Why do static websites seem to be windmills for "security experts" to tilt? Visitors can only read them, so why should we encrypt such static content? Because Google says so? Because of possible MITM attacks aiming to modify content or inject malicious scripts or ads? But who would be interested in such MITM attacks? Authoritarian regimes? These guys can cut the Internet off completely or make all their citizens use a special browser with built it mechanisms for censorship, tracking and reporting. Airlines, hotels and other public WiFi providers? Really? Should they want to be legally sued for that (especially if we pay for the access)? Please do not tell me nonsense about mining of crypto currencies in the web, mining requires huge resources, hardly ever achievable with distributed calculations in the web. (In fact, some of your CPU time can be stolen by malicious javascript for other tasks, which does not sweeten the pill.)
Lastly, what about millions of widgets for weather, stocks, ads, video, etc being eagerly embedded in websites? How can you know they do not track you or modify your content or inject anything? Such javascript widgets are executed on the client side, when content has already been loaded via an open or encrypted connection. Protect the pipe though water is already poisoned.
Another point is hiding URLs when you navigate to HTTPs websites. Excuse me, hiding from who? ISPs? Our ISPs already charge us for the service, which is their primary and almost always the only business model. They neither need our history nor want it. Stop, whose business model is not really defined or known to us? Who wants our history, who has already got full access to our history, devices, browsers, who insists on HTTPS for all websites and thus makes it harder for any 3rd party to get it? Could it be Google? What about Facebook, Apple, Twitter? Why Twitter, Facebook and LinkedIn mobile apps open URLs in their own built-in browsers by default and bury an option to switch this feature off deeply in the settings? What about cookies for tracking your browsing history? Have you heard about tracking pixels? Does TLS protect from them? No.
So why do you good guys blame me for my refusal to https my static blog and accuse me of my denial to protect visitors from possible MITM attacks of uncertain bad guys with uncertain goals and at the same time you quietly allow your privacy to be screwed by the big bosses of the Internet?
I am not trying to skimp on SSL, 70 bucks per year are quite affordable. But what for? To protect from unlikely MITM attacks on my blog's content when accessed via public WiFi? In this case let me suggest that paranoiacs should pay for VPN rather than I for SSL on my static blog.
As to free SSL, how can we trust them? With all respect to volunteering, good initiatives and all those lets-make-the-world-a-better-place, I wonder what their business model is. How can they ensure keeping keys safe if they do not even make money of it? Will they be trustworthy tomorrow, next month, next year? Do they provide any insurance? That's why I buy SSL certificates for my services with user input and enjoy old kind plain http for static content.
A bonus for lovers of conspiracy theories: both Google and Apple require HTTPS for all traffic between mobile applications and servers, otherwise your application will not be accepted to app stores. Does this at first glance good security precaution mean that the giants can possibly decrypt HTTPS traffic if they need it and thus they want us to use HTTPS rather than our own encryption? Have a think :)
Another bonus for those who has successfully struggled through my post up to the end: I can install a SSL certificate on this site, it would certainly do no damage, but I so much admire some guys' very basic understanding of engagement in social networks and how quickly they lose control when the shit hits the fan. Indeed, "I wish I was like you, easily amused".
Many thanks for a significant increase of traffic to this website, the pleasure was all mine. Let's repeat, get your fans ready :)
| J.Baytelman | July, 2018 |
