Re: [UPGRADE] upgrade-insecure-request-with-fallback

I do think this is interesting but I still think that the wide prevalence
of and bad outcomes with active mixed content are still such that I'm not
optimistic that a tool like Certbot can actually turn this on automatically
for sites without creating serious breakage.  (unless we introduce a third
state as proposed and for reasons discussed here
http://webappsec-test.info/~bhill2/DifferentTakeOnOE.html)

Assume we move forward with HSTS Priming, what is the expected incremental
benefit here?  Is there a guess or telemetry on how many sites have only
passive mixed content dependencies?  (remember if you have any critical
scripts that aren't served over https, you can't send visitors to the https
version of your site without breakage)

-Brad

On Thu, Jun 30, 2016 at 4:18 PM Tanvi Vyas <tanvi@mozilla.com> wrote:

> pinging this thread to see if there are others that would be interested
> in a fallback mode for upgrade-insecure-requests. Thanks!
>
> On 6/2/16 4:29 PM, Peter Eckersley wrote:
> > On Wed, Jun 01, 2016 at 02:56:42PM -0700, Tanvi Vyas wrote:
> >> upgrade-insecure-requests is a great way for sites to upgrade their
> >> subresources to https without having to change hardcoded http links.
> >> upgrade-insecure-requests provides a guarantee that no mixed content
> will
> >> load and degrade the security UI of a site.  In cases where an http
> >> subresource cannot be loaded over https, the subresource will simply
> fail to
> >> load and any functionality that it provided will be broken.  Some sites
> may
> >> appreciate this property and want assurances that third party content
> can't
> >> degrade the security of their site.  Others may feel that they can't
> afford
> >> to have potentially broken functionality.  Or they may know of a single,
> >> important subresource that isn't available over https and not want to
> spend
> >> the time and effort to upgrade the rest of their http links to https.
> This
> >> would prevent those sites from using upgrade-insecure-requests.
> >>
> >> I propose we add an upgrade-insecure-request-with-fallback option for
> sites
> >> and services that can't afford to break functionality but want the
> potential
> >> for increased security.  This fallback option can be either a separate
> >> directive or an attribute on upgrade-insecure-request.  We will have to
> be
> >> careful to ensure that we don't break backwards compatibility with sites
> >> that already set upgrade-insecure-requests and expect it not to
> fallback.
> >> Sites and services that opt into upgrade-insecure-request-with-fallback
> >> should be aware that they may have slightly decreased performance,
> because
> >> in the fallback case there will be two roundtrips for the same
> subresource.
> > There are really two versions of the above that could make sense.  One is
> > fallback for all subresources; the other is fallback for passive mixed
> content
> > only.
> >
> > I think it would be a huge win to offer fallback for passive mixed
> content as
> > a UIR variant, and it's something we've really been wanting for Certbot.
> > Fallback for active mixed content might also make sense (as a separate
> > directive from servers) and be a win but I expect we'll have to talk a
> lot
> > more about how to ensure that doesn't become a source of security holes,
> and
> > what the UI would look like.
> >
> > The case for passive mixed content fallback is simple: if
> > upgrade-insecure-requests works in that mode, then it is unambiguously
> > non-breaking to turn it on.  At present, upgrade-insecure-requests
> unbreaks
> > some script mixed content, and improves the security of some image loads,
> > while also breaking some other image loads.  As a result, it can only be
> set
> > if a careful site-specific analysis of the consequences has been made.
> If a
> > passive-mixed-fallback mode existed, we would likely start setting it
> for the
> > ~100,000 domains that currently use Certbot with an installer and
> request help
> > in redirecting traffic from HTTP to HTTPS.  I suspect this might also be
> of
> > use to platforms like Cloudflare or Wordpress.com that are trying to
> HTTPSify
> > millions of domains where they don't fully control the underlying web
> > application or HTML.
> >
> > The case for an active-content fallback seems more subtle: we know that
> mixed
> > content blocking has made HTTPS much harder to deploy, and there are
> *some*
> > sites where we'd probably rather have an imperfect deployment for content
> > confidentiality vs surveillaince, than no deployment at all. This
> stronger
> > form of fallback is pretty comparable to the "opportunistic encryption"
> > proposals that have been discussed at length, and would have to come with
> > strong incentives to make it a temporary arrangement. Those could
> include some
> > visible UI degradation, an instant F grade on Qualy's SSL Labs
> scorecard. Or
> > something more creative, like a requirement that CSP report-only mode for
> > mixed content be enabled at the same time, so the site has to learn
> about how
> > to start fixing its mixed content before enabling this comparatively
> insecure
> > option.
> >
>
>
>