Re: NTP vs. HSTS

Hi Adam, 

Speaking first hand, the demo involved resetting time using fake step NTP responses to various operating systems but I don’t remember which browser he was using at that time.  There were many quirks described by the author, but in general it seemed like a feasible attack.

A side note here - tlsdate won’t help much it’s one time sync tool while the problem is that client systems trustingly process the continuous NTP updates and that these messages are typically unsigned with Autokey (RFC5906). There’s interesting discussion in NTPv4 spec https://tools.ietf.org/html/rfc5905#section-15 

On 16 Oct 2014, at 23:28, Adam Langley <agl@google.com> wrote:

> 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


-- 
Pawel Krawczyk
pawel.krawczyk@hush.com +44 7879 180015
CISSP, OWASP