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.)

Comments

Yes

[buchner.johannes]

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:Yes

[Aethedor]

Caching: You can cache Facebook's images, stylesheets and Javascripts just fine.
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:Yes

[Anonymous Coward]

It is disingenuous to make a blanket statement "you can not cache Facebook". After all, what takes up the most "data" on the page? It is between images and scripts. Neither of those is unique per user. When someone posts an image, all viewers of the image see the same image. It can be cached. Same with the javascript. It is just the unique parts of the page that can't be cached...

Re:Those aren't the services you're looking for

[yakatz]

It includes things like local caching which was once important, but probably isn't anymore.

Re:Sounds good to me

[Anonymous Coward]

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.

Re:Drop HTTP completely?

[bunratty]

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!

Re:Cost of certificates

[bunratty]

You can get SSL certificates for free, but they're WAY more difficult to use than they need to be. I've installed certificates before, and it's a bunch of tedious, boring, repetitive work. What are computers for but to automate tedious, boring, repetitive work!? The computer should handle all work for me, and all I should have to do is click a button, for chrissake! That's what Let's Encrypt does.

Re:Those aren't the services you're looking for

[petermgreen]

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.