Re: "Mixed Content" draft up for review.

On Jun 2, 2014 8:41 AM, "Devdatta Akhawe" <dev.akhawe@gmail.com> wrote:
>
> Hi
>
> > HSTS from a site operator is a clear indicator that all resources
should be
> > HTTPS, and thus failures to adhere to that policy are bugs by the author
> > that UAs should not try to cover up.
>
> Interesting. The key difference seems to be that you want HSTS to be a
> mechanism to protect against user mistakes (only) while I want it to
> also cover developer mistakes. I don't see what we win by only
> limiting HSTS to protect against user mistakes.
>

A decade+ has taught us that covering up developer mistakes - whether it be
the wrong mime type or the wrong tag formulation - creates more security
issues and makes the state harder to reason about.

In this case, users who have a fresh HSTS entry are protected, while those
with sale entries or that have never before visited, or that use a UA that
doesn't support HSTS, are not.

> I think HSTS is indication that all resources, even if URL says HTTP,
> should be accessed over HTTPS. By the explanation above, an anchor
> link is also a bug that the UA should not cover up. But, if I am not
> wrong, neither browsers nor spec mandate showing any warnings for
> that.

"Depends". This is where we get into the murky world of link hashes, SRI,
S-Links, and determining "who" sets policy for a domain.

If a third party links to your domain insecurely, it is their bug. But you
have no idea who is linking to you (where is your referrer now?), so you
can't contact every link, on every document past and present, and correct
them.

If you yourself link to your domain over HTTP, that is your mistake, as an
author.

However, this distinction is irrelevant for Fetch, as it is conceptually no
different than linking to a document that serves a redirect. The effective
browsing context active document is the result of evaluating all such
redirects, so It Just Works.

For sub resources, no matter how many redirects are involved, the effective
security of the Fetch is the lowest common denominator of security statuses.

>
> For complicated, big applications, there isn't a single "author."
> There is a big team of developers, who might screw up and type http
> once in a while in some corner of the application. There is also a
> whole team of security engineers. HSTS is an indicator that the
> security team requires all fetches to be over HTTPS. I think we should
> show some empathy for the security engineers and developers at
> awesomesauce email application :)
>

I empathize, but I also know compromises that have been made at "guessing"
intent or "hiding" mistakes have made the web security model vastly more
complex, and created plenty of amusingly cute exploits.

This is the same security team that has to deal and determine how UAs will
sniff mime types, to make sure they are sanitizing attachments. I think we
have given them enough heartburn and liver failure than to do it again with
the "guess if you're secure or not"

> Further, since showing the mixed content dialog is bad UX, I think "we
> will not show mixed content dialog if HSTS is on" is a great carrot to
> encourage HSTS adoption, which is what we all want.

I want HSTS adoption, but not at this compromise.

>
> Also, consider the state that the specs will end up at: If app.com has
> HSTS, <img src=http://app.com/foo.png> will show a mixed content
> warning. But, add a CSP 'img-src https://*', the warning goes away!
>
> cheers
> Dev

I consider that a great carrot for CSP - and the right tool for the
security team to elaborate what they expect of their authors, rather than
of their users.