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?
Yes.
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.
The S in HTTPS really means security. The "services" provided by middle-boxes rarely provide anything "value added" to the user.
"the major loss due to the "S" is the inability to offer any in-network value added services, that are offered by middle-boxes"
Someone seriously just figured out what the end-to-end part meant? What the actual fuck.
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.
present participle of "to firewall"
how is "s" preventing firewalling?
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.
1. have you read all the pieces about "in network buffering" and how it is screwing up the way the internet was designed?
2. are you sure in-network value-added services does not really mean cookies and tracking, etc.?
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...)
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.
Imagine You cross a bunch of cockamamy with trolling and F.U.D. The end result would be called "crud" and that's what this summary's "Are we ready to accept it?" is.
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 read that as "censorship".
"Parental control" (blocking websites) can be done using hosts files (it's how I block ads + get more reliability (vs. downed or redirect poisoned DNS servers)).
Safer, faster, & more reliable websurfing is achievable using 1 native file you already possess, that operates in Ring 0/kernelmode/RPL 0, as an integrated part of the IP stack itself (1st resolver queried too).
APK
P.S.=> Of course, there *IS* this "shameless plug" in that regards - as to HOW I create such custom hosts files AND what they can do for you - also:
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?o...
Which gets its data vs. known malicious sites/servers from 12 reputable sources in the security community to do all that's enumerated on that download page... apk
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
Parental control: You can block websites just fine, either via DNS or IP.
The biggest problem is large complex sites like reddit, imgur, google, bing, etc. Do you have any idea how effective Google Images and Bing Video are at finding porn? When running a web filter at something like a grade school (which I have), you have no choice but to ban the websites entirely, or force all devices to have your own root CA to do SSL inspection.
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.
"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. :)
honestly it is completely dumb for most of the internet. Slashdot does not need to be encrypted, blogs, etc...
the problem is that sysadmins and web developers are to underskilled to figure out how to do it properly.
Do not look at laser with remaining good eye.
http://www.quintolabs.com/ (Diladele) is what I use at home to manage safe surfing for my family. Works great and is free.
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."
I'm "FED"UP with ISPs thinking they have a right to inject BS into our Intertubes we are paying increasingly insane sums of money for thanks to the steady devolution of a competitive ISP market. Denying service providers the capability to implement RFC6108 (F UUUUU Mr. Livingood) in and of itself makes SSL worth doing.
You can still operate content filters either with a middle box you trust, by explicitly installing a CA certificate or by handling decision making in-browser as an extension/plugin.
Anyhow don't forget to enable HSTS after you get your certs installed kids. Don't let HTTP fallback be an option.
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.
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.
Within HTTPS, is HTTP - wrapped up in encryption. The HTTP still supports transparent compression.
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).
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?
F F uckin yes....
I blame it on all these websites that want you to sign up for no reason. I always give these idiots fake information anyway.
"that manifests itself through increases in the page loading time that go above 50%"
50% of what? WTF? Typical Slashdot summary.
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!?!
"Parental control" + "firewalling" (blocking host-domain/subdomain names) can be done using hosts files (it's how I block ads + get more reliability (vs. downed or redirect poisoned DNS servers) AND to stay safe vs. known malicious sites & servers)).
Safer, faster, & more reliable websurfing is achievable using 1 native file you already possess, that operates in Ring 0/kernelmode/RPL 0, as an integrated part of the IP stack itself (1st resolver queried too).
APK
P.S.=> Of course, there *IS* this "shameless plug" in that regards - as to HOW I create such custom hosts files AND what they can do for you - also:
APK Hosts File Engine 9.0++ 32/64-bit:
http://start64.com/index.php?o...
Which gets its data vs. known malicious sites/servers from 12 reputable sources in the security community to do all that's enumerated on that download page (which is FAR MORE than what I just listed above)... apk
APK
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.
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.
Nowhere in the paper does it mention firewalling. The submitter's just making shit up.
"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?
Caching works fine with cloudflare, they are proxy and cache in the middle.
With cloudflare, they tend to establish their own secure connection to your website, then cache that content on their service, and users who use HTTPS will establish their own HTTPS connection directly with cloudflare.
So HTTPS and caching still works just fine.
I do love the security of HTTPS because if the system isn't set up like this, but it is possible a transparent method might work like this, um, it prevents man in the middle from caching, blocking, or identifying your traffic, and it prevents most forms of snooping, and it prevents NSA from getting access to the unencrypted stream - and trust me, NSA is secretly intercepting all content, encrypted or not, so you better at least try to protect yourself by using some encryption.
The worst thing about NSA spying today is that the unencrypted internet is fully open to them. They nab HTTP headers which contain a lot of information plus the content of the transferred data; The HTTP headers will contain PUT, GET, COOKIE, POST information, including unencrypted passwords and usernames and social security numbers and other information. This allows NSA to directly track all Internet users and the information is available to agents of the government when they want to hack an account or be abusive or even get into things illegally.
Not to worry, this is not even their most invasive surveillance method - they also have a series of mind reading satellites so they can decode your thoughts directly from space and radar, and it's fully patented stuff, been in deployment since the 1970s. The technology is ground and building penetrating too, so they can even take scans of your ass and tits from space, this technology is called interferometry or ground / building penetrating tomography.
http://www.myronmays.com/
That is all.
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.
Another hidden cost is that it really sucks over a satellite link.
Not everybody lives in a city or within 5 miles of the CO.
Well we can do without parental censorship er... control for a start.
"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