Re: Subresource integrity and mixed-content warnings

On Mon, May 23, 2016 at 11:32 AM, Frederik Creemers <
frederikcreemers@gmail.com> wrote:

I'm aware that this only gives us the MITM resistance, and not the
> authentication and encryption offered by a fully HTTPS protected website.
> I'm also aware that my server then somehow needs to connect to the media
> server and calculate the checksum, and that a MITM attack could be
> performed there. But I really feel the need for a solution to include non
> HTTPS content on HTTPS pages, especially non-executable content like
> images, audio and video.
>

This question has come up before. Of the 3 security guarantees HTTPS is
supposed to provide — server authentication, data integrity, and data
confidentiality — the HTTPS main page + SRI'd sub-resources solution
provides only the first 2, and even then only if you (the site operator)
have some reason to trust the integrity of the resources you hash for SRI.
Potential reasons to trust that:

* You downloaded the resources onto your server at time T1, and computed
their hashes. For some reason, you consider T1 to have been "a good time";
SRI guarantees at least that the resources don't get worse after T1. People
using the site just have to trust that T1 was a good time.

* There is some reason to believe that the connection between the browser
and your server needs protection (e.g., it's the internet), but that the
connection between your server and the podcast servers is safe without TLS.
(Perhaps they're in your same data center on the same LAN, or something.
Even then, TLS would be good defense in depth and would enable new,
distributed deployment scenarios.) That doesn't sound like it applies to
your case; you're presumably gathering podcasts from all over the internet.

* Some other reason I can't think of right now.

So, those aren't really strong guarantees of safety, and in any case, the
browser cannot verify that they hold at run-time, based on what it can see
when loading your page. Additionally, although we humans know that
"podcasts are not banking", the browser cannot know that. It doesn't have
human-level AI, and so has to assume the worst. Finally, the person using
your app might really want confidentiality, which the HTTPS main age +
SRI'd sub-resources solution cannot provide. Again, the browser cannot know
whether the person cares about confidentiality for the sub-resources in
your app vs. all the other apps in the world. So, again, the browser must
assume that the person does care.

Thus, I don't think it's a good idea to relax the mixed passive content
warning for non-HTTPS but SRI'd sub-resources. SRI is great, but it just
can't make non-secure sub-resources TLS-equivalent. So we must tell people
so.