Re: attacking hsts through ntp

[Michal Zalewski <lcamtuf () coredump cx>]

> The reason: HSTS preloaded sites are handled exactly the same way as
> normal HSTS sites - they can expire.

I haven't looked at the actual code, but Adam Langley said this on
another mailing list:

---------- Forwarded message ----------
From: Adam Langley <agl () google com>
Date: Thu, Oct 16, 2014 at 9:01 AM
Subject: Re: NTP vs. HSTS
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 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.


Cheers

AGL