RE: Upgrade mixed content URLs through HTTP header

The problem with option 1 is that you are still vulnerable to active MITM attackers. Attackers can easily identify TLS connections to third party websites and reset them. With Option 1, browsers fallback to HTTP, which is the same result as not setting the CSP header. So I think we'd better go with either option 2 or 3.

Best,
Xiaoyin Liu
________________________________
From: Tanvi Vyas<mailto:tanvi@mozilla.com>
Sent: ‎2/‎6/‎2015 14:30
To: Mike West<mailto:mkwst@google.com>; John Wong<mailto:gokoproject@gmail.com>
Cc: Devdatta Akhawe<mailto:dev.akhawe@gmail.com>; Alex Russell<mailto:slightlyoff@google.com>; Joel Weinberger<mailto:jww@google.com>; Emily Stark<mailto:estark@google.com>; Jim Manico<mailto:jim.manico@owasp.org>; Ryan Sleevi<mailto:sleevi@google.com>; public-webappsec@w3.org<mailto:public-webappsec@w3.org>; Anne van Kesteren<mailto:annevk@annevk.nl>; Adam Langley<mailto:agl@google.com>
Subject: Re: Upgrade mixed content URLs through HTTP header

Reading through all three[1] threads, I see two proposals and have
questions around how each should be implemented - with a fallback to
HTTP or without?

The first proposal it to use a CSP directive.  Websites can opt-in to
autoupgrading subresources using a CSP directive
"upgrade-insecure-requests".  Assume such a website is HTTPS and has an
HTTP subresource.  The user agent will try the HTTPS version of the
subresource first.  If it succeeds, then it will load without any
security UI degradation or mixed content warning.  What happens if it fails?

* Option 1 - Fallback and try the HTTP version; the mixed content
blocker will be invoked and the content will be blocked if it is
blockable with an option for the user to override the blocking (shield
shows up in Firefox and Chrome) or loaded if it is optionally blockable
with a degraded security UI.
* Option 2 - No attempt to access the HTTP version and no mixed content UI.

Option 2 will result in a user experience that is worse than the current
experience with mixed content blocking.  Also, with Option 2, sites may
be less likely to set the CSP directive because it could potentially
break their site. Hence, I like Option 1 where we fallback to the HTTP
version.  But this could cause performance issues since in the fallback
case we are doing two resource loads instead of one.

We could also have Option 3 - only fallback for optionally blockable
subresources, since many users don't click the shield and override
protection anyway and hence end up with a similar user experience.

The second proposal is to use HSTS as an indicator that HTTP
non-same-origin subresources should be autoupgraded.  Same
questions/concerns here.  We don't want to make the experience worse for
sites that have already set this header, and hence we should only go
with Option 1 if we pursue this proposal.

Thanks!

~Tanvi

[1]
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0037.html
"An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs
through HTTP header)"
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0023.html
"[MIX] 4 possible solutions to the problem of Mixed Content Blocking
stalling HTTPS deployment"
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0006.html
"Upgrade mixed content URLs through HTTP header"

On 2/6/15 12:12 AM, Mike West wrote:
> On Fri, Feb 6, 2015 at 7:21 AM, John Wong <gokoproject@gmail.com
> <mailto:gokoproject@gmail.com>> wrote:
>
>     My 3.1415 cents basically say CSP-based reporting is very helpful
>     even with the noise. I always think there should be one single
>     reporting mechanism for all the security headers, rather than
>     asking developer to write code and detect the UI/Browser warning
>     and find their code is causing trouble. And this needs to be
>     outside of CSP, a superset reporting mechanism that CSP can
>     forward to. I tend to think of it like shipping logs to logstash.
>     This can be a whole different header...
>
>
> Sounds like an interesting proposal! Perhaps we could flesh it out in
> a separate thread?
>
>     Now is auto-upgrading sub-resources a good security measure. I
>     agree with some of the concerns raised in Devdatta's bugzilla
>     report (https://bugzilla.mozilla.org/show_bug.cgi?id=776278). I
>     apologize if i am really shifting the main attention, and please
>     excuse my inability to keep up with the latest development:
>
>
> I think the major difference between the current proposal and Dev's
> bug is the word "auto".
> If the site needs to opt-into the behavior, then it's significantly
> less likely that doing so will expose the kind of `http://forbes.com/`
> <http://forbes.com/%60> vs `https://forbes.com/`
> <https://forbes.com/%60> discrepancies; those sites will simply not
> opt-into the behavior.
>
> -mike
> --
> Mike West <mkwst@google.com <mailto:mkwst@google.com>>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
> Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)