Re: Subresource integrity and mixed-content warnings

Hi Chris,

Thank you for the reply, it makes total sense. It looks to me like the
biggest issue here is transparency to the user. Security and privacy are
complicated, even for tech savvy people, and you can't expect most people
to take the time to overthink what security guarantees a particular web
application they're using does and does not offer, so I understand browsers
want to give users a very clear "this website is secure" or "this website
is not secure" signal. Your response has also made me realize that there's
no workaround for this that I can implement, as there's nothing that I can
set up to magically make the connection between the user's browser and the
podcaster's server secure (authenticated and encrypted).

I guess the only thing I can do is hope that media servers start accepting
secure connections as quickly as possible.

Best regards,
Frederik

On Mon, May 23, 2016 at 8:49 PM Chris Palmer <palmer@google.com> wrote:

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