Re: Blocking high-risk non-secure downloads

> On Apr 9, 2019, at 13:58, Daniel Veditz <dveditz@mozilla.com> wrote:
> 
> On Tue, Apr 9, 2019 at 11:30 AM Emily Stark <estark@google.com <mailto:estark@google.com>> wrote:
> Over in Chrome land, we've been considering how to drive down non-secure downloads, particularly high-risk ones like executables. I wanted to see if other browsers would be interested in joining us on this adventure.
> 
> I would be very happy to push in this direction, limited by the amount of breakage and user-pushback we can expect. Any statistics you can share would be a huge help. Insecure downloads from the secure sites of companies who ought to know better are distressingly common ("but the executables are signed!").
> -Dan Veditz

One of the reasons for using cleartext HTTP for downloads is to more easily permit distribution from a shared cache, which is an explicit feature of HTTP’s layered design. These sorts of downloads are frequently distributed from multiple untrusted sources, not just HTTP (over TLS, cleartext, or otherwise); and TLS only offers transport security, it does not verify the authenticity of the download.

If you’re trying to encourage people to adopt more secure distribution practices, requiring TLS is missing the point.

We should first look at how to continue to support HTTP’s design, including layered responses, otherwise we’re likely to see people implement workarounds that’s even worse than the cure.

For example, the “duplicate” link relation (described in RFC6249, <https://tools.ietf.org/html/rfc6249 <https://tools.ietf.org/html/rfc6249>>) allows a server to specify alternate download locations for a document, which can be verified against a hash specified with the Digest header.

But maybe even before that: Which attack, exactly, are we trying to protect against?

Cheers,

Austin Wright.