The Cost of the "S" In HTTPS
An anonymous reader writes Researchers from CMU, Telefonica, and Politecnico di Torino have presented a paper at ACM CoNEXT that quantifies the cost of the "S" in HTTPS. The study shows that today major players are embracing end-to-end encryption, so that about 50% of web traffic is carried by HTTPS. This is a nice testament to the feasibility of having a fully encrypted web. The paper pinpoints also the cost of encryption, that manifests itself through increases in the page loading time that go above 50%, and possible increase in battery usage. However, the major loss due to the "S" is the inability to offer any in-network value added services, that are offered by middle-boxes, such as caching, proxying, firewalling, parental control, etc. Are we ready to accept it? (Presentation can be downloaded from here.)
Are we ready to accept it?
Slashdot certainly isn't ready!
"in-network value added services"
I just read that as "advertising".
Besides, I though most of the internet traffic was netflix now. Is that all done https in a way that distributed caches are infeasible? I understood that the caching was pretty robust for their traffic.
Is it just my observation, or are there way too many stupid people in the world?
Caching: You can not cache Facebook for example, because the content is generated differently for every user. Youtube goes through great lengths to prohibit caching (e.g. with Squid) in the first place.
Proxying: You can proxy https just fine.
Firewalling: You can firewall https just fine.
Parental control: You can block websites just fine, either via DNS or IP.
I suspect they mean snooping for "copying that companies don't approve of" and "freedom fighters" here. And child pornography. It's kind of the point of HTTPS that it should be private. So yes, I can accept these costs.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
The other cost of the S is the difficulty in obtaining and using certificates that are recognized by browsers without bothering the user. That's why the Let's Encrypt project is trying to make it free and easy.
What a fool believes, he sees, no wise man has the power to reason away.
What is the cost to the user of having their communications intercepted, banking details stolen etc etc.
That's like saying that putting locks on your doors has an added cost of you requiring more time every day getting in and out because you have to take time to turn a key. It also means that local corporations can't send people by to inject "value added" services into your home without your consent! Are you ready to accept locks on your doors?
Stupid article. Making a mountain out of a mole hill.
How hard is it to push a certificate to your clients so they trust your proxy? How hard is it to setup a cache there? And monitoring/filtering? Not very hard.
We do this at work, and it is dead simple for halfway competent admins to implement.
What this really does is stop telecoms from monkeying with their users' traffic. By default, anyway.
Most ISPs provide Windows installers/optimizers to their users, which their users dutifully click through without understanding. So they could just install their certificates and continue business as usual---with very little effort, all things considered. They might need beefier proxies to handle encryption, but CPU time is cheaper than ever.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
The tradeoff is between a little more time, and a little more resources, against the benefit of keeping my communications private and unaltered by all of the middlemen through which my communications pass. That's a no-brainer for me.
In the days before the exposure of Verizon's (and others) schemes to actually interfere with the content of communications from their customers passing through their network (I'm talking about the physical modification of the communications content, and not just traffic management/prioritizing), I may have had a different opinion about the tradeoffs. But now that the "common carriers" have shown that they have no morals what so ever with respect to the content of traffic they are carrying through their networks, SSL encryption is simply a necessary function to prevent interference.
Today that interference may be limited to tracking user activity using an additional HTTP header that the user never knows exists. Who knows what packet re-writing magic might be used by the carriers in the future to completely "customize" each user's experience interacting with third parties to the benefit of the carrier?
Yes. COX is an offender for certain.
An interesting thing of it though, it's possible to man-in-the-middle HTTPS. It requires one to be a router in-stream, and to proxy the traffic, and to report one's own SSL information to the web client, then to decrypt, and re-encrypt when proxy-requesting from the server.
This is actually normal behavior on corporate networks. Cisco has products that are specifically designed to do this. An interesting way to see if it's going on is to use a new browser with HTTPS Everywhere running with the SSL Observatory turned on in the wild, then use it on a corporate network and see if one gets warnings.
Do not look into laser with remaining eye.
Then block all HTTPS until age 13. The only sites you need HTTPS for are the ones that require a login, and COPPA and foreign counterparts make it very hard to offer logins to children under 13.
To do this, the client must have a root certificate installed by the man-in-the-middle meddler that spoofs all domain names. Not an easy task unless you're a corporation providing a computer to your employees.
The problem with HTTP is that a middleman can see and alter content. If a browser doesn't warn when it encounters a self-signed certificate, then HTTPS would be no more secure than HTTP -- all the middleman has to do is use a self-signed certificate to decrypt/encrypt packets as needed. So browsers do prefer HTTPS, when the certificate can be verified. If you're using HTTPS and the certificate can't be verified, it's no more secure than HTTP unless the user is warned, and in fact it's a way of detecting that a middleman may be present. That's the whole reason for the death warning!
What a fool believes, he sees, no wise man has the power to reason away.
Or as the rest of us like to say... stopping man in the middle attacks.
I'm a good cook. I'm a fantastic eater. - Steven Brust
There's also a point to be made that while many somebodies would, just on general principles, love to know everything you watch on Netflix, etc, in most cases the actual privacy invasion of such knowledge is almost certainly far lower than would be gotten from library records in days of old. We're talking about what mass-market pablum you choose to waste your time with - it may help somewhat in building a psychological profile, but it's unlikely to reveal many details. So leaving such high-bandwidth mass-distributed data unencrypted could allow us to still use caching for the data which benefits most.
On the other hand, your YouTube watching habits are potentially far more revealing. But by the same token the viewership for any given video is generally far lower, and with it the benefits of caching, so the cost/benefit ratio probably comes down strongly in favor of encryption there. If the NSA wants to know my viewing habits, let them buy the data from Google. And Google, I'm counting on you making a tidy profit selling that data. Don't cheap out on me. The expense needs to be enough to that they only buy the data on the specific individuals they're already suspicious of.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
This is an easy one.
User: "Hi, I'm getting an error message when I go to my bank site."
Tech Support: "Oh, that's normal. Just click here, check that box, and then OK. In the mean time, go to our Internet troubleshooter. It will make sure you never see this error again."
User: "Thanks! You've been exceptionally helpful and I'm going to send your supervisor a positive review!"