
Web Encryption Gets Stronger and More Widespread: 2014 in Review - erkose
https://www.eff.org/deeplinks/2014/12/2014-web-encryption-roundup
======
Animats
HTTPS Everywhere forces large sites to use content delivery networks which act
as a man-in-the-middle for so-called "secure" connections. Cloudflare is doing
this for at least 36,000 domains. We know Cloudflare is an interception point.
([http://www.washingtonpost.com/blogs/the-
switch/wp/2013/09/12...](http://www.washingtonpost.com/blogs/the-
switch/wp/2013/09/12/cloudflare-ceo-says-insane-nsa-gag-order-is-costing-u-s-
tech-firms-customers/)).

What the EFF isn't pushing is MITM detection. There are ways to do that, but
the EFF is doing nothing in that area. This the TSA approach to security -
lots of visible activity, with big holes. I call the EFF initiative Security
Theater Everywhere.

Remember, the EFF brought us TrustE, which turned into a scam so bad the
Federal Trade Commission fined TrustE. ([http://www.ftc.gov/news-events/press-
releases/2014/11/truste...](http://www.ftc.gov/news-events/press-
releases/2014/11/truste-settles-ftc-charges-it-deceived-consumers-through-
its))

~~~
StavrosK
I don't understand this comment. HTTPS Everywhere _forces_ large sites to use
MITMs? No, it forces them to implement good security, which MITMs are
incompatible with. Companies just go "yeah we know that we need to be secure,
but we can't be bothered doing that because we like our CDN too much, so we'll
just put everything at risk with horrible hacks".

~~~
Animats
_" I don't understand this comment._"

A content-delivery-network using HTTPS _is a MITM._ Decryption occurs at the
CDN, and everything is in the clear inside the CDN's operation. That's a good
place for interception, lawful and otherwise, because so much can be captured
there.

It's a scaling problem. If you only use HTTPS for crucial items such as logins
and credit cards, the load is small enough that you don't need a content
delivery network for those pages. A small number of high-security machines can
handle the important stuff. The non-secure pages can go through a CDN, which
can cache them.

With HTTPS Everywhere, if you're big enough to need a CDN, and use the same
CDN for both secure and non-secure pages, you've exposed everyone's
credentials inside the CDN. How much do you trust your CDN? Are you feeling
lucky?

What we really need is less SSL and more page signing. There's a W3C proposal
for attaching the secure hash of a page to its URL, and validating that in the
browser. That guarantees the page you asked for is the one you get, while
allowing caching. The caching operation can't change anything without the
browser rejecting it. This catches tampering at the router level, the cache
level, and the ISP (we're looking at you, Comcast) level. So you can have the
performance gains of distributed caching without the risk of tampering.

~~~
toyg
_> There's a W3C proposal for attaching the secure hash of a page to its URL_

My google-fu seems weak, any chance you could link it? It sounds like a great
idea in principle (although you'll need buy-in from browser AND server
vendors).

~~~
Animats
[http://www.w3.org/TR/SRI/](http://www.w3.org/TR/SRI/)

It's called "subresource integrity". Mozilla and Google have reps working on
the spec. Example:

    
    
        <script 
            src="http://code.jquery.com/jquery-1.10.2.min.js"
            integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript">
    

Anybody in the transmission path can cache that, but they can't change it.
This improves caching performance in general, because you don't need timed
expiration. Load JQuery-1.10.2 once, and never load it again unless it
changes.

~~~
richbradshaw
Well, they can change it if it and the resource are not served over HTTPS by
changing both the hash and the response for the resource.

This doesn't add much unless at least the parent page is using HTTPS, else the
hash can simply be stripped anyway. If browsers had an HSTS type precache list
for sites that must use hashes, if they aren't using HTTPS then the resource
and the hash can be changed.

------
deanclatworthy
And this is only just the start. Hopefully the revelations this year and the
subsequent work by privacy activists and security professionals and especially
the EFF [1], have made the wider public aware of the extent to which their
communications and lives are being intruded on.

Once we start seeing free ssl next year [2], hopefully this will be a step in
the right direction to a more secure World Wide Web.

[1] [https://www.eff.org/](https://www.eff.org/) [2]
[https://letsencrypt.org/](https://letsencrypt.org/)

