You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked.

You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.

And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.

For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack.

NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.

Unless you use SNTP on your servers. Don't do that. Ever.

In practice, there are systems that use SNTP or regular NTP with periodic calls to ntpdate. Ubuntu does the latter, by default, and is thus susceptible to the attacks I described,

That's a bug with Ubuntu. That mode of operation is for devices without persistent real time clocks or personal laptops where time isn't that important. If you sync your time at reboots you will screw up ntpd's clock drift calculations.

Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.

Ubuntu accepts arbitrary time jumps, the attack was presented live at BH with an Ubuntu System.

so you can see Ubuntu so it is 03:14 UTC on 19 January 2038? That might be bad, how big is their time_t?

This kind of attack should be difficult, because NTP clients should be configured to ignore large offsets. See the (dangerous) -g option in the ntpd manpage, for example.

There is still a lot of crypto out there that works off of using the current timestamp as a seed.

Being able to control he time could theoretically let you control any PRNGs that rely on it.

I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?

Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.

You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server.

There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.

Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.

It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).

The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

> The much bigger issue is with hardware that doesn't have a local clock/battery.

Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway.

> Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).

The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually.

Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.

If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications.

Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.

Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).

Accurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.