Re: HSTS priming vs preloading

On Mon, Feb 1, 2016 at 3:56 PM, Richard Barnes <rbarnes@mozilla.com> wrote:

>
>
> On Mon, Feb 1, 2016 at 3:50 PM, Ben Wilson <ben.wilson@digicert.com>
> wrote:
>
>> Excuse my ignorance, but does this mean that there is consensus that
>> preloading HSTS should occur before checking for mixed content?
>>
>
> I'll assume that by "preloading HSTS", you mean "HSTS upgrades".  In that
> case, I wouldn't say there's consensus yet, but that's where we're trying
> to get.
>
>
>
>> Also, I’m assuming that this discussion is related to the proposal found
>> here - https://www.w3.org/TR/upgrade-insecure-requests/.
>>
>>
> This is the better one.  Still very much at draft stage:
>
> https://mikewest.github.io/hsts-priming/
>

I think we've established in this discussion that implementing HSTS priming
would mean that preloaded HSTS sites would all "just work" because the
browser would never have to send out the priming request.

However, the underlying issue driving HSTS priming (and why the HSTS check
currently comes after mixed content checking) is to make it so users have
deterministic and consistent experiences. Since preloading also guarantees
that consistency, you could also imagine an interim step being taken,
before this priming proposal is finalized and before the priming ping is
implemented anywhere, where preloaded HSTS is put ahead of mixed content
checking.

-- Eric


>
>
> --Richard
>
>
>
>> Is there somewhere else I could look to read more about this interesting
>> topic?
>>
>> Thanks,
>>
>> Ben
>>
>>
>>
>> *From:* Jim Manico [mailto:jim.manico@owasp.org]
>> *Sent:* Tuesday, January 19, 2016 9:49 AM
>> *To:* Richard Barnes <rbarnes@mozilla.com>
>> *Cc:* Eric Mill <eric@konklone.com>; Mike West <mkwst@google.com>; Jim
>> Manico <jim@manicode.com>; public-webappsec@w3.org
>> *Subject:* Re: HSTS priming vs preloading
>>
>>
>>
>> I am just looking for (or am considering creating if none exists) a test
>> to see how browsers handle HSTS and mixed content decisions. I just want to
>> understand current behavior today access all browser that support HSTS.
>>
>> - Jim
>>
>> On 1/19/16 11:46 AM, Richard Barnes wrote:
>>
>> Which "this" do you mean?  If you mean "taking HSTS into account for MIX
>> decisions", then you're not going to get much, since AFAIK no browser has
>> implemented it yet.
>>
>>
>>
>> On Tue, Jan 19, 2016 at 10:00 AM, Jim Manico <jim.manico@owasp.org>
>> wrote:
>>
>> Does anyone have an online test for this? I think understand and
>> standardizing this behavior is important.
>>
>> - Jim
>>
>>
>>
>> On 1/18/16 3:11 PM, Eric Mill wrote:
>>
>> On Mon, Jan 18, 2016 at 7:11 AM, Mike West <mkwst@google.com> wrote:
>>
>> On Mon, Jan 18, 2016 at 1:05 PM, Jim Manico <jim@manicode.com> wrote:
>>
>> Forgive this indulgence, but does HSTS preloading have the same benefits
>> of HSTS priming since preloaded HSTS would occur before the mixed content
>> check?
>>
>>
>>
>> Yes. Basically, we'd only do a priming ping if the origin being requested
>> wasn't already marked as HSTSized in the user's local browser. The fact
>> that we _would_ do a priming ping for non-secure origins that aren't in the
>> local browser's HSTS list ensures that we can do the upgrade without
>> breakage.
>>
>>
>>
>> I may be remembering wrong, but I didn't think HSTS alone (preloaded or
>> dynamic) would resolve mixed content issues.
>>
>>
>>
>> The stated concern with allowing HSTS to affect mixed-content rendering
>> is that it would create different experiences per-user/session, and
>> preloading does mitigate this concern, but I didn't think there was an
>> actual code path in Chrome (or other browsers) where it decides to allow
>> HSTS to override mixed content if the HSTS policy was preloaded.
>>
>>
>>
>> -- Eric
>>
>>
>>
>>
>>
>>
>>
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>