W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: NTP vs. HSTS

From: Adam Langley <agl@google.com>
Date: Thu, 16 Oct 2014 14:28:38 -0700
Message-ID: <CAL9PXLx4yhqz37Mwfnh4Vss6xZbG1FJSjf5ogq9eq_-9WQXOtg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: John Kemp <john@jkemp.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Oct 16, 2014 at 9:01 AM, Adam Langley <agl@google.com> wrote:
> On Thu, Oct 16, 2014 at 8:11 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Thu, Oct 16, 2014 at 5:01 PM, John Kemp <john@jkemp.net> wrote:
>>> https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf
>> So the problem is that time synchronization does not happen over TLS.
>> That seems like a pretty big flaw in OSs. Hopefully someone audits any
>> other unauthenticated channels they may have.
> This is the motivation for things like tlsdate
> (https://github.com/ioerror/tlsdate) as used in parts of ChromeOS.
> However, in section seven, where the author claims that preloaded
> entries are added for 1000 days, that's only via the net-internals
> debugging interface. (The code screenshot shown is also of code for
> that debugging interface.) I believe that preloaded entries in Chrome
> will always be enforced, no matter what the system time is.

Someone pointed out that the author did a demo so there must be
something there.

So I went back into the source code and the author really is mistaken
by the 1000 days bit in net-internals. However, we do have a timeout
for HSTS preloads which git blame says that I added, although I don't
remember it. The timeout is the same as our pinning timeout, which is
10 weeks from the build timestamp.


Received on Thursday, 16 October 2014 21:29:25 UTC

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