- From: Adam Langley <agl@google.com>
- Date: Thu, 16 Oct 2014 14:28:38 -0700
- 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. Cheers AGL
Received on Thursday, 16 October 2014 21:29:25 UTC