Re: Redirects and HSTS

On Fri, Sep 26, 2014 at 5:26 AM, Mike West <mkwst@google.com> wrote:

> +sleevi
>
> On Fri, Sep 26, 2014 at 2:24 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>> On Fri, Sep 26, 2014 at 2:15 PM, Mike West <mkwst@google.com> wrote:
>> > Yes, I think that's true.
>>
>> Perhaps Gecko's stance that HSTS rewriting happens after Mixed Content
>> is correct. At least for non-same-origin HSTS. :-(
>>
>
> That's how Chrome implements it, actually. Ryan, et al, are dead-set
> against moving HSTS before mixed content checking, as he claims (correctly)
> that HSTS only protects those browsers that support it. If we don't throw
> errors, we're throwing Safari and IE users under a bus.
>
> -mike
>
>
Re-reading this thread, I'm not sure we're on the same page.

My understanding from the last time I sync'd with Tanvi was that Mozilla
was doing HSTS rewrites before Mixed Content detection/blocing, while
Chrome does it after.
For Chrome, this is tracked in a bug about our Extension API, but which has
similar behaviours to HSTS (see
https://code.google.com/p/chromium/issues/detail?id=122548#c26 )
For Mozilla, this is https://bugzilla.mozilla.org/show_bug.cgi?id=838395

That is, Chrome considers it a "Feature", Mozilla consider(ed?) it a "Bug"

However, this is a secondary discussion to Anne's original point, AIUI.

If I understand Anne's point, the question is: Can HSTS be used for
tracking? The answer is Yes, and this is (briefly) discussed in Section
14.9 of RFC 6797 ( http://tools.ietf.org/html/rfc6797#section-14.9 ), and,
as Chris notes later in this thread, expanded upon in the context of HPKP
to explicitly document the attack (as it also exists for HPKP, although
slightly differently)