Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Cost of the "S" In HTTPS

Posted by timothy on from the not-insignificant dept.

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

3 of 238 comments (clear)

  1. Yes by buchner.johannes · · 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.

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    1. Re:Yes by Aethedor · · Score: 4, Informative

      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.

      --
      It doesn't have to be like this. All we need to do is make sure we keep talking.
  2. Re:Sounds good to me by Anonymous Coward · · Score: 5, Informative

    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.