The Cost of the "S" In HTTPS 238
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.)
Not Slashdot! (Score:5, Funny)
Are we ready to accept it?
Slashdot certainly isn't ready!
Re:Not Slashdot! (Score:5, Funny)
Yes, clearly we must urgently encrypt all slashdot communication so that no-one can read the posts!
Re: (Score:3, Insightful)
Yes, clearly we must urgently encrypt all slashdot communication so that no-one can read the posts!
Given that this sites primary purpose is social commentary of the news, encryption's probably more important here than just about anywhere else.
Re:Not Slashdot! (Score:4, Insightful)
Worry not, Comrade!
HTTPS will come to Slashdot after UTF-8 arrives and the Usable Slashdot interface is retired.
In the meantime, why don't you come join us at https://pipedot.org/ [pipedot.org]? It has both UTF-8 and SSL support already.
Re:Not Slashdot! (Score:4, Funny)
And for that matter so does Soylent News [soylentnews.org], which is even based on the same codebase as Slashdot!
Re: (Score:3)
Those aren't the services you're looking for (Score:5, Interesting)
"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.
Re:Those aren't the services you're looking for (Score:4, Informative)
Re:Those aren't the services you're looking for (Score:4, Insightful)
Legitimate local proxies will have the clients configured to use them and will work fine with https.
Re:Those aren't the services you're looking for (Score:4, Informative)
In my experiance most proxies legitimate or otherwise just pass https through without caching it.
It's certainly possible to set up a proxy that decrypts and hashes https but it has a number of issues.
1: legal, in some jurisdications it may not be legal to interfere with the encryption of certain types of traffic or may make you liable if the information you decrypted leaks out.
2: client configuration, you have to explicitly add the certificate for every client. Having unmanaged client machines is not mutally exclusive with a legitimate desire to cache data.
3: security, your proxy just became a massive target for anyone wanting to attack your users.
Re: (Score:3, Insightful)
My experience with telephone company provided local caching is that it usualy makes the web unusable, If I can get at a service via HTTP or HTTPS then quite often the HTTPS works where the HTTP will either give you nothing, or just the start of the page,
(This was on Free Mobile, in France).
Re: (Score:2)
Caching at the phone company is kinda pointless. The time you want proxy caching is when you have a fast local network behind a slow wan and want to reduce the traffic over the WAN.
Afaict the purpose of the phone companies proxy's is not caching. It's purpose at least in my experiance is to reduce bandwidth on the mobile network by reducing image quality.
Re: (Score:2)
Netflix gives servers to ISPs to host inside their networks for "caching". It's not really caching, it's just distributing their servers more widely.
Re: (Score:2)
Let's generalize that. (Score:2)
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, trans
Re: (Score:2)
Good lord, with the IoT, and any other "value added" krap out there, are we to expect even a moment away from ads?
Re: (Score:3)
Breaking that shit isn't a cost of HTTPS, it's one of the major reasons
Value added? More like value subtracted. (Score:3)
Plus, you are ignoring the fact that nobody is planning to encrypt content like video streaming.
Re: (Score:2)
Plus, you are ignoring the fact that nobody is planning to encrypt content like video streaming.
Remind me again why big corporations have been making a huge uproar about allowing unencrypted content? Oh yeah, DRM. ;-)
Re: (Score:2)
Yes (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
You can even cache, if you have access to the certs on the client. Google "squid in the middle". Any school or work environment with legit reasons to filter or cache content still can.
Re:Yes (Score:5, Informative)
Proxying: Not just fine. You need a man-in-the-middle proxy for that and its root certificate installed on every client. Otherwise, it's just routing, not proxying.
Firewalling: Firewalling based on hostname / port, yes. Firewalling based on bad content (malware), no.
Parental control: Same as firewalling. And blocking this kind of content is not only done by IP address, but often also by words in the hostname. This cannot be done when you can't read the hostname in the HTTP request.
Re: (Score:2)
Sure, nothing on there is a static page, but if a million people are sharing the same 1MB image, you can still cache that. The text after "So and So shared..." will change, and the comments/likes will change, but somewhere there is a jpeg that keeps getting reused. Not everything makes sense to cache, but for things like images shared by George Takei, caching them once at the ISP or corporate network level could stop many gigabytes of external transfer.
Re: (Score:2)
Even for lower use images, caching them closer to the poster could be helpful given that their circle of friends is likely, statistically, to be in the same region. One image alone would not make much difference in this case, but millions of low use images mostly coming from caches closer to most of the people viewing them would make a huge difference.
Re: (Score:3, Informative)
Re: (Score:2)
Ad injection, webpage redirection. "Value add" for network owners, not end-users. Fuck em.
Use COPPA as an excuse not to encrypt (Score:4, Interesting)
Re: (Score:2)
Block executable downloads until age 13 (Score:2)
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.
Re: (Score:2)
Right, because children under 13 don't deserve any privacy anyway. Or email. Or game accounts.
Whitelisting (Score:2)
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 a
Re: (Score:2)
Re: (Score:2)
Except modern browsers and servers support SNI, so the hostname is now sent as plaintext on the network.
Re: (Score:2)
Euphemism: 'Value-added services' (Score:2)
Cost of certificates (Score:5, Interesting)
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 [letsencrypt.org] project is trying to make it free and easy.
Re:Cost of certificates (Score:4, Informative)
Re: (Score:2)
they're WAY more difficult to use than they need to be.
That's probably in order to justify the price, I mean for the non-free ones (to be recognized by most browsers)? A cert takes less than a $0.01 to be made, they're sold between $30 to $1000...
Re: (Score:3)
With StartSSL the actual cert generation is easier than that as they create the key on their server first and they ask for the forms on the site. No CSR is needed, though you can do it that way if you wish.
What is a tiny bit annoying is their authentication - you need a client authentication cert installed on your browser. Not hard in itself, but annoying if you have let the old one expire as they then need to review your request for a new one.
One other thing is verification that you own the domain, through
Aw man! I wanted to inject adverisments! (Score:2)
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...)
Slashdot? (Score:2)
Re: (Score:2)
We're still waiting for the Unicode support that was already implemented in slashdot.jp years ago.
Re: (Score:2)
Re: (Score:2)
What about the cost of NOT having it? (Score:5, Insightful)
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?
Re: (Score:2)
Oh, I get you! We should only put locks on specific areas of our house. Leave the front door unlocked, but perhaps have a lock on the bedroom and bathroom. After all, there should be no real reason why the contents of your fridge should be kept secure, and if your local supermarket was allowed send in staff members to people's houses at random (or targeted if they notice you haven't been shopping with them lately) to check where you have been shopping recently and what you have been buying, so they can deli
WTF... (Score:4, Interesting)
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.
Re: (Score:2)
You don't even need to know how to do it - Smoothwall automates most of the process so even an A+ certified tech could figure it out. Probably.
Re: (Score:2)
Re: (Score:2)
I've not seen any patential control software that runs as a proxy server. It's all browser plugin. I'm surprised at this - given that many homes now have several laptops, a few more tablets and a mobile phone each, maintaining one proxy is a lot less hassle than ten browser plugins across four different operating systems.
... Is about the least of it (Score:3, Insightful)
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.
Re: (Score:2)
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.
My very favoritest thing is when an element moves over just slightly just as I was about to click it, and I click its neighbor instead.
Hmmm. Not a hard tradeoff for me. (Score:4, Interesting)
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?
Look forward and the answer is clear (Score:2)
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.
Network services (Score:2)
Re: (Score:2)
It interferes with non-browser-based ad blockers. Which are common still on corporate networks, though rarely at home. You can still block by DNS even then, it's just not so fine-grained. Fortunately you rarely need fine-grained to stop advertising.
Drop HTTP completely? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Drop HTTP completely? (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
caching, proxying, firewalling, parental control (Score:5, Insightful)
Or as the rest of us like to say... stopping man in the middle attacks.
Caching (Score:2)
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. Ess
Re: (Score:2)
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.
If the server ignores your cache-pragma then the server is not just aggressive, it is broken. If you failed to set your cache-pragma then your app is broken, not the proxy. You didn't provide enough information to determine which was the case, and I wouldn't be surprised if some proxies ignored the pragma and some didn't.
Compression: Reduced RF energy (Score:2)
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. :)
Re: (Score:2)
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.
Re: (Score:2)
google's statement on https (Score:3)
https://www.imperialviolet.org... [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.
If it comes from an authoritative source... (Score:2)
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 [slashdot.org].
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.
Re: (Score:2)
So ends a fad (Score:2)
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 th
Re: (Score:2)
Middle Boxes (Score:2)
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.
Re: (Score:3)
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.
Re:"S" in quotes, but not services or value added? (Score:4, Insightful)
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.
Re:Sounds good to me (Score:4, Interesting)
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.
Re:Sounds good to me (Score:5, Informative)
Re: (Score:3)
Mod parent up. I was going to post the same thing. There are numerous appliances and software solutions used by enterprises to do this, but to do it seamlessly you have to install a new certificate on the client machine.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Sounds good to me (Score:4, Interesting)
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!"
Re: (Score:3)
Re: (Score:2)
What? I think this thread is going off track somewhat. I don't think Dave420 was talking about Client Auth certs. He was talking about root certs installed on the clients. Without the standard set of root and intermediate certs installed on the client (Installed by default on web browsers and some other clients such as Java virtual machines etc), TLS will not work (Well it will, but there will be warnings).
What Dave420 meant was that for the appliances and software solutions that cache/inspect the TLS traff
Re: (Score:3)
You need both at the same time to make a session that is MITM resistant.
Over the years I've run into more than a few people who think this. I don't know quite where the meme comes from yet I suspect it to be based on incorrect assumptions about how the technology actually operates.
If you are making a judgment the whole house of cards of hundreds of global CA is not worthy of your trust that is quite a reasonable and understandable position..
If you are saying the user will just click "continue" when they get a scary certificate warning this is also quite a reasonable and unders
Re: (Score:2)
in a corp network, you usually have laptops that are gen'd by the corp IT guys. that means - 99.9% of the time - they come pre-installed with evil certs. and a firewall that is surely a mitm node along your path.
10 yrs ago (or more) I was interviewing for netmgt jobs (this being my main field) and they were all about sniffing, dpi and mitm bullshit. really turned me off! but those were the jobs 10 yrs ago and they have not changed, over time. netmgt is still more about spying, these days, than true net
Re: (Score:2)
Yes. COX is an offender for certain.
Can you describe what you mean by this? I'm a Cox subscriber am unsure of your claims of them injecting "their own junk in HTML pages". I have Adblock and HTTPS everywhere extension on so maybe I don't notice it?
Re: (Score:2)
You can see it - look at arstechnica.com and if you view the html source you'll see a large comment section embedded in it advertising some braindeadpayments.com system.
It works as a little game apparently, so you can put tokens in the URL (of the advertised site, not the injected site) and it'll play some slots game.
I really doubt Ars put it there, so its been injected along the way.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There's absolutely no reason why it has to be, if it is indeed done that way.
No reason except for that's how SSL works... Otherwise you get no end to end encryption or assurance that some third party (like the CDN itself) hasn't modified the page. The CDN can't grab an SSL protected page from the host and serve it to browsers with having access to the unencrypted page.
The CDN could retrieve content over SSL, store it as plaintext, and reencrypt with a new ssl certificate (supplied by the host website) it before serving it to you but that's just a specialized case of MITM that many
Re: (Score:2)
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 f
Re: (Score:2)
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
Re: (Score:2)
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 i