Re: attacking hsts through ntp

[Hanno Böck <hanno () hboeck de>]

I'm CC-ing Adam Langley, don't know if he is on this list.

Am Thu, 16 Oct 2014 13:45:16 -0700
schrieb Michal Zalewski <lcamtuf () coredump cx>:

> 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.

Something can't be correct here. In the talk the attack was presented
directly with chrome + google mail (which is one of the preloaded
entries). Either he cheatet or the 1000 days limit applies to them, too
(haven't done any tests myself).

But basically, it may be debatable if browsers should consider
preloaded entries as "forever". Independent of that I think the
quesiton how date/time can be made more secure is worth investigation.
tlsdate etc. certainly seem like a good idea to me. The OS default
should be a secure timesetting method.

If I understand it correct tlsdate uses the timestamp field of normal
tls connections while ntp is a timesetting protocol on its own. I'm not
into that stuff, can ntp be retrofittet with tls? Is that a good idea?
Has it advantages/disadvantages compared to tlsdate?

Still open is obviously the question: Who do you trust with your time?
If your timeserver is compromised you still have an attack vector.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno () hboeck de
GPG: BBB51E42

Attachment: signature.asc
Description: