W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2015

Re: HSTS, mixed content, and priming

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 25 Aug 2015 18:10:31 +0200
Message-ID: <CADnb78i1c-yAkoriYu=dpdKdvzPC+YFNG_c=mW2AwmSz6d8hDw@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: Brian Smith <brian@briansmith.org>, WebAppSec WG <public-webappsec@w3.org>
On Tue, Aug 25, 2015 at 5:02 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
> On Tue, Aug 25, 2015 at 2:24 AM, Brian Smith <brian@briansmith.org> wrote:
>> Why not send a GET request to https://example.com/foo/bar.js as though it
>> was already upgraded via HSTS, and then use the response if the response
>> includes an HSTS header? This would save one request/response and would
>> avoid the practical problems with using HEAD. (Although servers are supposed
>> to return the same headers for HEAD requests that they return for GET
>> requests, in practice many do not.)
> I think the worry here is leakage -- if the HTTPS site is actually
> different, then you're leaking request context in the GET.

So given a site A that accesses a site B that has an HTTPS site on the
same domain B'. The worry is that we're leaking to B' that the user is
visiting A, while only B (and all network attackers which we assume B'
is not part of) should know that?

Given that deprecating HTTP is a thing I think that should be acceptable.

Received on Tuesday, 25 August 2015 16:10:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC