Re: Blocking high-risk non-secure downloads

On Fri, 12 Apr 2019 at 05:06, Emily Stark <estark@google.com> wrote:

> "Ignoring SRI..."



If SRI was used, the browser would be able to check the hash automatically
- so that converts the "please check the hash" into something everyone
would actually be doing (as the browser could force it).

Admittedly it does not cover privacy, which HTTPS sort of provides (e.g.
malicious actors observing the network traffic could guess which download
it is based on file size).

But as a starting point... yes, block high-risk non-secure downloads,
but still allow HTTP downloads by simply adding an SRI hash... and of
course you will still allow HTTPS downloads, but maybe you could start with
a warning in the developer tools to push developers in to adding
the integrity attribute as well (e.g. your HTTPS CDN could have been
compromised).

:-)

Craig




On Fri, 12 Apr 2019 at 05:06, Emily Stark <estark@google.com> wrote:

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