Slashdot Mirror
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?
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?
I have heard many times that some ISPs exploit that possibility by injecting their own junk in HTML pages. So if that can be avoided, HTTPS only makes everything better.
Value added? More like value subtracted for most of the things on your list.
Plus, you are ignoring the fact that nobody is planning to encrypt content like video streaming.
Only if you trust the entity doing the proxying, of course, but its not exactly rocket science to install the certificate of the proxy and have it decrypt and reencrypt the traffic on the fly. Probably expensive to do on a large scale as it will take a lot of juice, and definitely a niche application...but if you REALLY want to, you can.
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.
Oh, you mean like targeted ad injection and other MITM type garbage? That's fine, you can keep those anyway.
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
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.
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.
Caching is only a benefit if you are doing the same purely consumption things online that your neighbors are. Not a concern.
Proxying is an odd one to include, as it takes a whopping 3 seconds to set any web browser to use a proxy, so why should I be impressed that some ISP has a proxy in place whether I want it or not?
I have no reason to trust a third-party firewall.
"Parental control" software is a joke. It'll block the famous but tame sites and you'll find your kid watching things that make you physically ill to think about.
Etcetera may be useful, but since it is typically tossed in after someone is done with what they think are the good examples, I don't trust it either.
There are already some ways to get some of the benefits of https: without all of the costs, and I'm sure ingenious people will figure out other work-around as well. In the meantime, from where I sit the benefits of https: generally outweigh the costs.
Let's take caching as a trivial example that doesn't require much ingenuity to figure out:
Let's say I run an https: web site. Let's say I want to run a content-delivery-network for my images, ads, and most other content but I want to maintain control of the main index.html file and of a few other "embedded" items. The end user loads the https://.../index.html. Based on the customer's IP address the index.html file will include https: links to nearby CND-offered images, ads, etc. Since the CDN's URL will have a valid certificate, there won't be certificate issues for these items. As long as the end user's web browser tolerates an https: web site embedding content from a different https: web site this will work.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Presentation seems pretty weak. Probably not worth anyone wasting their time reading. Encryption does not negate caching ability. Generally, this looks like a non-tech made a tech presentation.
Yes. Please. HTTPS all the time, everywhere.
It's one thing when the free WiFi at the shady computer store down the street does it. But even for-pay WiFi hotspots are doing it now. (Looking at you, Southwest Airlines In-flight WiFi...)
Things like compression, firewalls and proxying definitely add value to me as a user.
But it's a value I'd happily trade in for the value of security and privacy.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
When will Slashdot catch up? I still can't use this site in HTTPS without subscribing. Being able to browse securely is a standard feature these days.
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.
in-network value added services, that are offered by middle-boxes
Dear god this summary reads like a stroke victim. Looks like the PHB is low on meetings today...allow me to take a moment to explain what the cryptography does in each case...
caching: is a relic from when switches were slow and data bandwidth was very limited. gigabit nics, CDN's and multi-gigabit switching has obsoleted it for the most part.
proxying: If we mean squid then true it will break, but otherwise this is kinda vague. my IRC proxy still works, and my SSL proxy is unaffected
firewalling: No. Firewalls will still work you ignorant walnut. things like DPI and injection might be hindered however, and those things are in point of fact not adding any value to anything.
parental control: Most sites your kid shouldnt be looking at are flagged for detection by the browser or add-on software, and when they arent the content displayed is in most cases detectable by third party software. DNSBL and null routing handles this more efficiently however, so i have a hard time declaring my ability to police my daughter "broken."
Good people go to bed earlier.
I've no doubt that the overhead of https can be more than paid for if website designers would lay off the Singing Flowers and Dancing Fairies. Toss the gratuitous multi-media. Especially the auto-playing stuff. It's cheap and cheesy and makes me seriously think of avoiding the site altogether, whether it's local content or 3d-party adverts.
And while you're at it, calculate the slow-filling parts of the page in advance so that the [censored] thing doesn't bounce up and down like a demented ping-pong ball as it loads. The only thing more irritating than having a page continually re-map itself while you're reading it is to have the stupid thing auto-reload and throw you back to the top of it.
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?
Proxying and caching was a huge win back in the analog modem days. These days it is still a win, but not as big. Looking forward, the costs associated with having a secure connection are only going down while the value of the secure connection is holding steady or maybe increasing.
Let's see, on the useful side we have compression/acceleration and parental controls. Would it also interfere with ad blockers and anti-malware? Those are also useful services. Services we as consumers don't want are those ads certain low-cost carriers insert in content - though if blocking those forces the carrier to shut down we might have a problem. And of course we also don't want those Big Brother services - governmental content blocking and monitoring.
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.
What would you think about a hardened web browser which would only allow HTTPS connections? It might be a feasible idea already.
I used to be able to surf the headlines of my morning list of websites before going to work on my iPad using a Verizon connection for about 10MBs. It now takes about 15MBs. That could be iOS8, HTTPS, the lack advertising blocking software and/or the increase in advertisements, or whatever. The point is megabytes is [now] money [that I have to pay for], and I don't get any say in controlling the amount of my data plan everyone sucks up -- if I still want to keep reading the same set of headlines in the morning.
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.
I work at a place with many distributed offices. A lot of these offices are large enough to have their own IT staff who make decisions locally.
Some of those bozos felt the need to have very aggressive caching servers. Aggressive enough that on any non-https website, it was impossible to differentiate between users or deliver new content. So any web apps we rolled out had huge problems if multiple users were logged in- or even better, a page would never update because it already existed in the cache. Essentially dynamic sites were completely unusable. Imagine going to a news site, and reading yesterday's news...because it had been cached less than 24 hours ago.
This problem started about 13 years ago- when HTTPS was far less common. So even on ecommerce sites users were having huge problems. Yes, a lot of ecommerce ran unencrypted 13 years ago.
So- every single site I ran (hundreds of sites....) had to run completely HTTPS- to avoid caching. Even the really simple line of business apps that were ridiculously basic and had no reason to be secure, had to run under HTTPS. Even public facing websites had to run under HTTPS, otherwise the local users would not see updates. (No, they did not see updates on sites I did not control...)
Sometimes IT people can be idiotic...but in their mind it cut down on bandwidth usage, which was a greater goal than having the web actually work.
Most of the people responsible for these caching servers have since retired or moved on...but still on a server delivering over 200 million public page views each year, it all runs encrypted because of their legacy.
But seriously...sometimes people have their nose stuck so far up IT minutia, that they can't see the forest through the trees.
No reason to lie.
the internet has never been end-to-end, its always been packets shovelled through a myriad of devices routing your packets to the destination.
Stuff like caching and proxying are useful to the well-being of the internet, if I am watching the same movie as the guy next door, we don't need twice the bandwidth to the datacentre that's located in god-knows-where. Local cache makes things work a lot faster.
I suppose Google can afford to puts its own caching proxies across the globe, so its not much of a problem for them, but it might be for everyone else.
Maybe we'd be better off without https and instead encrypt the underlying communication between the end-user and the ISP. https isn't going to stop the NSA after all, but it is a good thing to stop anyone sniffing all wifi traffic.
"in-network value added services"
I just read that as "advertising".
I read that as "ad jacking" (dns or dom insertion) by your isp.
Now, I'm not sure how HTTPS works, but when you use something like PGP, it first compresses the data in order to increase the entropy, making it harder to crack. So while we're spending more CPU cycles on compression and encryption, doesn't the reduced transmission payload more than offset the cost of the computation? In general, communication is WAY more expensive (in terms of energy) than computation.
Damnit, I'm going to have to read the article to find out if they did this right. :)
https://www.imperialviolet.org...
in short, there is no cpu overhead anymore, in today's compute systems. https is not a barrier due to processing, at least.
--
"It is now safe to switch off your computer."
That https, at least via wifi and at nation state level monitoring is useless.
"If any question why we died, Tell them because our fathers lied."
If it comes from an authoritative source, Slashdot is less likely to question it. If it comes from me, I'm an idiot trying to run a slow box in the 21st century.
Lots of people are commenting here about how they want to inject ads. No threads are blasting them for suggesting that HTTPS can slow your browsing experience.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Right, because children under 13 don't deserve any privacy anyway.
If children aren't submitting any personally identifying information (PII), what privacy is to be had? It's already illegal for a web site to collect PII from children under 13 without a parent's consent. If a parent consents to a site's collection of a child's PII, the parent can whitelist the site.
Or email.
The child clicks the send button in a native e-mail app on the computer (not webmail), and then the parent reads the outbox and approves each message as appropriate to be sent. Or the e-mail lands in the inbox, the parent reads it and approves it as appropriate to be received, and the child reads it.
Or game accounts.
The parent can whitelist any game that he or she has approved for a particular child.
I would say that any site that allows downloads of executable content also needs HTTPS.
I agree. So let's require parental elevation to download an executable until the child graduates from parental controls. The child won't have administrative privileges to install software anyway.
Clearly adding an "S" on the end will result in 5 letters instead of 4. That's a 25% increase!
More generally, CDNs aren't "in-network services" in the same sense as middleboxes and thus aren't hampered by TLS. When properly deployed they don't sit between the page server and the browser, but rather the page server links to CDN URLs for images, scripts, and other referenced content. From that standpoint they are essentially just another farm of web servers specialized for static content.
The "in-network services" TFA talks about can only work because they can freely inspect, collect copies of, transform, redirect, and generally tamper with the data streams without the end user explicitly opting into them. Most of these I have encountered primarily add value for the network owner, and more often than not actually subtract value for the individual user forced to go through them.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
And thus the beginning of the end of the RESTful fad. Not that there's anything wrong with RESTful architecture per se, but as a fad it has been shoe-horned by ideologues into so many inappropriate domains lately: embedded P2P, M2M spaces, etc. Sure, it makes sense for one-to-many patterns involving human-readable, human-discoverable resources, particularly of semi-static resources that can be cached and proxied by middle agents. But of course that later part only works for unsecured transactions. So now the exemplar of RESTful design itself, the WWW, is abandoning one of the key supposed benefits of being RESTful.
You can still compress the content sent inside of HTTPS just as you would with ordinary HTTP, it's just HTTP+SSL. But you can have that with or without HTTPS.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You can do caching, proxying, firewalling, parental control, etc with HTTPS. Create a certificate on those boxes and push it out to the client devices. You can then see all encrypted traffic. Problem solved.
"A plan fiendishly clever in its intricacies"- Homer Simpson
Sometimes https is needed to keep content confidential, but sometimes it is used just to ensure integrity. Some or all site content may be innocuous and not require confidentiality, but a man-in-the-middle corrupting data could change meaning or include malicious code. Maybe there should be an httpv -- http verified -- which includes signed hashes of each resource to offer proxy-friendly integrity and possibly lower overhead.
Stuff like caching and proxying are useful to the well-being of the internet,
Yes. That's true. But browsers do cache content sent by HTTPS, unless the content has settings which prohibit it, e.g. "Pragma: no-cache". Any dynamic content should have its pragma set so that it won't be cached, anyway. Anything else shouldn't, and the browser will cache it.
ISPs which put transparent proxies in usually aren't doing it to save bandwidth between them and the internet. It's usually done so that they can recompress the images sent to your browser to reduce the bandwidth on that link, to make your internet connection seem faster and reduce link congestion. That's especially true in mobile.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Compressed data leaks information. There have been many side-channel attacks using the resulting size of the data and figuring out what information is in there. Pretty much, statistical analysis.
I'm not sure how this is related to HTTPS. Are you saying that Verizon was previously running a transparent proxy that automatically munged the sites you browsed and made them smaller? Have you excluded the likelihood that they've just gotten even fatter over time?
Much of the daily-headlines stuff isn't encrypted anyway; but, even if it is, it is entirely possible to proxy, modify, and otherwise manipulate in-transit HTTPS traffic as long as your client(s) trust your proxy as a CA. It's not pretty; but it's entirely doable(and more than a few corporate firewall boxes do exactly that, with devices on the LAN side configured to trust them). If you want a box-in-the-middle to strip your morning headlines into lyxnvision, HTTPS isn't stopping you.
Within HTTPS, is HTTP - wrapped up in encryption. The HTTP still supports transparent compression.
I don't know. I thought encrypting everything ate up more bandwidth with more overhead, and I just notice the little padlock icon by the URL more and more. Something is sure driving up the number of bytes for basically an unchanged daily reading pattern. Don't notice it, of course, when using WiFi. Maybe it's just more cloudcrap going on, but that shouldn't have changed much, either, and it's megabytes. Darn NSA. I understand, except for my problem. :)
http://www.google.com/webhp?no...
-- Each tock of the Planck clock is a new world and here we are still life. --
[Whitelisting the Internet] Sounds like a great way to lose the trust of your child.
I don't see how. A lot of families didn't have Internet at home at all until long after 13. Or compare to life away from the keyboard, where kids can't choose where they can travel outside walking distance until age 16-19 depending on country (or never in the case of women in Saudi Arabia).
And that doesn't even account for the cost of man hours to support junk the NSA secretly pushes on us to get around the 'S'.
I just learned that the network guys at my company are looking in to horribly expensive Palo Alto Systems porn filtering for our entire network. Why? Because we got some federal funding and some recently passed law states that such funds can't be used to fund any network that transmits porn. So to check the box when applying for (or renewing) such grants, our lawyers say we have to actively filter out porn (or attempt to, since here on /. we all know that's a practical impossibility).
At first I though, no problem. Possibly they just run outbound web traffic through an anonymous proxy and/or return invalid DNS entries for known porn domain names. So we pay stupid amounts of money for some overpriced network junk. Doesn't affect me. But then I learned that it's actually very sophisticated over-priced network junk. It operates not just at the DNS or HTTP level, but actively filters ALL traffic. How you ask? We'll, my group will be tasked with installing special keys for all encrypted protocols (https, ssh), which the filter has a copy of, of course, on every single system that needs outbound access. Never mind the complete lack of privacy for reasonable personal use (such as doing some banking online during my lunch break instead of taking a whole hour to drive to the bank). Never Mind fact that we're all willing to bet the NSA has their filthy mitts on the filter equipment and does way more than "check for pron" -- all at the expense of my company (and probably the profit of Palo Alto systems, who I'm sure lines the pockets of our congress critters). I could live with all that. I got nothin' to hide.
But when the stick me with a bunch of useless busy work of maintaining a ridiculous infrastructure of compromised ssh keys and trusted ssl certs. When I can't just install the defaults and expect them to work. That pisses me off. Why, congress, why!?!
Mod parent up.
"HTTPS Everywhere" is security theater. Most stuff doesn't need to be encrypted. Worse, as the parent post points out, it causes the creation of security holes. This weakens security for the few things that need to be encrypted.
We don't need "value added services" in the middle of the network. Not for secure content, anyway. Perhaps some content should be signed, but not encrypted, so it can be cached, but not modified. Cloudflare, which decrypts everything that goes through it, is a huge security hole.
I'm all for HTTPS everywhere for all of the aforementioned reasons already posted, but especially to screw over Verizon and their HTTP tracking injection. For those unaware, Verizon Wireless is injecting headers into your traffic at the network level to track you for advertising purposes. You have the option to opt-out (you're opted-in by default), but that just supposedly prevents them from selling the information; the tracking header is still injected into your data stream and is visible to all sites you visit and on the server-side of any app you use that uses unencrypted HTTP requests. If the site you visit uses HTTPS (or use you a VPN), Verizon can't MITM you. Screw Verizon Wireless.
Hey, I've got plenty to hide - but precious little of it will be even ever be exposed by my Netflix viewing habits. For the most part even the best, most compelling mass-media available only ranks as "mostly better than staring at a blank wall when I don't feel like thinking". Any psyche profile built up around my choice of least-bad media is going to be laughably inaccurate. Hell, after years of watching Hulu they still can't even target me with marginally relevant advertisements.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
"the inability to offer any in-network value added services" - I was hoping you were referring here to injecting webpages with ads on mobile phones while browsing? Can that criminal behaviour be prevented by an all-HTTPS web?
We'll be moving all our clients to https-only within a couple of months. We have systems to deal with that!
--
no sig for you. come back one year.
Adding "s" to "http" means there is one more character added to every URI in the code. Although negligible in a smaller application code base, these additional characters can accumulate to cause a noticeable impact on storage and network usage in larger applications that have been highly optimized.
2. are you sure in-network value-added services does not really mean cookies and tracking, etc.?
Cookies and tracking work perfectly in https. Conversely, a proxy that blocks cookies and tracking before they even reach your browser is an "in-network value-added service".
"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." ... And that is bad? Oh right this is written from the carriers perspective. Personally I would prefer if the would stop DPI'ing all my traffic and doing 'value added' stuff. This is about resisting the dumb pipe scenario. I can think of a Canadian company (who Telefonica happen to be their largest customer) that would find their business model threatened by an all encrypted internet.
IMO, the carrier should have no place looking at the traffic I generate on their network. If I have to encrypt to guarantee it, then let's do it.
While compression may help prevent some types of attack (in particular known plaintext attacks) it also creates new avenues of attack. In particular it makes the message length dependent on the message content.
For something like human written pgp emails this is not a massive deal,the length variability of human written messages and the low message rate mean that the chances of useful information being leaked this way are negligable.
For things like VOIP this can cause information leakage even to a passive attacker as what people say will impact the compressibility of the data. http://www.esecurityplanet.com...
For things like https the message rate is too low and the content too variable for a passive attacker to stand much chance of exploiting the messsage length side channel but an active attacker can stimulate traffic with known characteristics and partially known content to effectively exploit the channels.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register