W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Re: HSTS priming vs preloading

From: Jim Manico <jim.manico@owasp.org>
Date: Tue, 19 Jan 2016 10:00:27 -0500
To: Eric Mill <eric@konklone.com>, Mike West <mkwst@google.com>
Cc: Jim Manico <jim@manicode.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <569E4F8B.20203@owasp.org>
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 
> <mailto:mkwst@google.com>> wrote:
>
>     On Mon, Jan 18, 2016 at 1:05 PM, Jim Manico <jim@manicode.com
>     <mailto: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
Received on Tuesday, 19 January 2016 15:00:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:17 UTC