Re: attacking hsts through ntp

[Adam Langley <agl () google com>]

On Thu, Oct 16, 2014 at 2:07 PM, Hanno Böck <hanno () hboeck de> wrote:
> > 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).

Ah, so 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.

There are other tricks that can be played with the system time: roll
the time back and use an "expired" certificate which has been pruned
from the CRLs for one. I'm sure that there are others.

That's why we have tlsdate in ChromeOS. It does, indeed, use the
timestamp from a TLS handshake. In the case of ChromeOS we depend on
the timestamp from Google, which makes sense for a ChromeOS device
that already trusts Google. If one was to design a secure timestamp
system one could do much better (Ed25519 signatures, batching of
requests into a single signature etc). But we already have TLS running
which means that there's no incremental operational overhead, which is
very attractive.


Cheers

AGL