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