Re: Blocking high-risk non-secure downloads

On Thu, Apr 11, 2019 at 2:55 PM Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Hi
>
> I realize the question was directed towards other browser vendors but I
> figured its on webappsec so I will chime in :)
>
> It is a bit weird that the platform will continue allowing http downloads
> from an http page; but not http download from an https page. If the https
> page includes a hash/fingerprint of the download and asks users to check
> it, you can imagine a world where this is a secure flow. Especially, if we
> can add support for downloads in SRI
> <https://github.com/w3c/webappsec-subresource-integrity/issues/68>. In
> contrast, there is no way for the http download from http pages to be safe.
>

Ignoring SRI, the distinction seems fairly theoretical to me because the
number of users who will actually check a hash is so small.

I would like to hear from developers if they are distributing downloads
that they can reasonably SRI but can't move to HTTPS. I know Mike and
others have argued vociferously in the past against allowing SRI to
substitute for HTTPS...


>
>
> Now, that might be fine---something is better than nothing. My worry
> though is that this could add more roadblocks for people trying to migrate
> to https. Further, if the download is really on a different server that
> doesn't even support HTTP (for whatever reason), then I also think a
> security engineer's time is better spent getting some sort of integrity
> check/verification than trying to get that page to support HTTPS.
>

That seems like a wasted effort given the small number of users who will
actually check a fingerprint. If the download really couldn't be HTTPS, I
would probably begrudgingly advise the security engineer to send the user
to an HTTP page first and then trigger the download from there. (And this
doesn't preclude distributing a hash on the HTTPS page before sending the
user away to HTTP.)

Re: roadblocks for migrating to HTTPS, I think this depends on the metrics.
The # of affected sites and navigations are looking small enough that we
think the overall user safety benefit of blocking the downloads is worth it
even if it discourages some small number of sites from migrating.
(Apologies again that we can't share our metrics quite yet; this thread was
meant to be more of a temperature check than diving into the specifics.)


>
> Has Chrome considered blocking HTTP downloads on HTTP pages first?
>

We could look at the numbers for this. But the particularly egregious thing
about HTTP downloads on HTTPS pages is that users currently don't have any
way to know that they were downloaded insecurely -- unlike HTTP downloads
on HTTP pages, which are getting labeled more and more aggressively. We
could do some new UI to label HTTP downloads on HTTPS pages, as Yan
mentions below, but there are various reasons we don't want to do that: we
don't think it would be particularly effective, and we don't want a
proliferation of connection security indicators all over Chrome.


>
> --dev
>
>
> On Tue, Apr 9, 2019, 2:00 PM Daniel Veditz <dveditz@mozilla.com> wrote:
>
>> On Tue, Apr 9, 2019 at 11:30 AM Emily Stark <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
>>
>