Scalable, Lie-Detecting Timeserving with Roughtime(int08h.com)
int08h.com
Scalable, Lie-Detecting Timeserving with Roughtime
https://int08h.com/post/to-catch-a-lying-timeserver/
12 comments
What would the magnitude of effort to actually replace ntp with another solution be? Even in low-level programming, I mostly take for granted that it occurs, but it's regular enough that there's an ntpd on any machine I connect to.
What does someone stand to gain by lying about the time?
Lots of automation executes on a schedule. If you control time, you can cause something to happen (or not happen) as you like.
Use your imagination. Don't forget to combine this with other attacks - if you compromise something your target talks to, for instance, or with non-technical actions - shorting a stock, maybe.
More generally, the two major assumptions that a lot of complex systems depend on are time and identity. There are a lot of games you can play controlling one of those. (Controlling both is better, of course.)
Use your imagination. Don't forget to combine this with other attacks - if you compromise something your target talks to, for instance, or with non-technical actions - shorting a stock, maybe.
More generally, the two major assumptions that a lot of complex systems depend on are time and identity. There are a lot of games you can play controlling one of those. (Controlling both is better, of course.)
Say you've gotten your hands on an old, expired TLS certificate (or cracked one using old crypto). Then, if you can convince a client it's in the past, you can use that to mount an attack.
Tor has a related problem where the Tor consensus is only valid for a specific time window - if you use the consensus outside that time window you may end up using a completely different set of nodes than what everyone else is using, potentially greatly reducing your anonymity.
For most crypto applications like certificate expiry, you don't need a particularly accurate clock - +- a day or two is fine - but with Tor the devs have to balance being able to frequently update the consensus with clock accuracy; IIRC the maximum allowable clock skew in Tor is about six hours.
Of course, note how even in that case, if user-experience wasn't an issue you'd be better off telling the user to just look out the window to set their clock than using Roughtime. :)
For most crypto applications like certificate expiry, you don't need a particularly accurate clock - +- a day or two is fine - but with Tor the devs have to balance being able to frequently update the consensus with clock accuracy; IIRC the maximum allowable clock skew in Tor is about six hours.
Of course, note how even in that case, if user-experience wasn't an issue you'd be better off telling the user to just look out the window to set their clock than using Roughtime. :)
Robust cryptography tends to depend on having accurate-enough time.
Aren't all the goals already met by e.g. http://phk.freebsd.dk/time/20151212.html ?
httpstime is interesting, but roughtime seems to have a few additional features:
* stateless operation (via UDP)
* no reliance on SSL/TLS or PKI
* ability to catch incorrect servers (assuming no collusion)
I think it's a very interesting take on time services, without being something quite as heavy as PTP/IEEE1588. The stated goals of fixing wildly incorrect clocks over ultraprecise timing [0], preventing clock-source tampering, and keeping largely in-line with the original design concepts of ntp (while solving a number of security shortcomings) seems to be targeted squarely at user devices, and much less so at service providers or operators that require precision timing for log stamping and the like.
Additionally, if you need a roughly-correct clock for validating HTTPS certificates, and you have to connect to an HTTPS server to update your time to be roughly correct, how do you trust the server? Sure, you can simply connect to something with a self-signed cert, but then you're putting the trust squarely back in the hands of that single server, without any method of verifiability. Turtles all the way down.
[0]: "The Roughtime creators state that 25% of Chrome’s certificate errors are caused by incorrect local clocks (off by days or more). A local clock within a few seconds of reference time is good enough."
* stateless operation (via UDP)
* no reliance on SSL/TLS or PKI
* ability to catch incorrect servers (assuming no collusion)
I think it's a very interesting take on time services, without being something quite as heavy as PTP/IEEE1588. The stated goals of fixing wildly incorrect clocks over ultraprecise timing [0], preventing clock-source tampering, and keeping largely in-line with the original design concepts of ntp (while solving a number of security shortcomings) seems to be targeted squarely at user devices, and much less so at service providers or operators that require precision timing for log stamping and the like.
Additionally, if you need a roughly-correct clock for validating HTTPS certificates, and you have to connect to an HTTPS server to update your time to be roughly correct, how do you trust the server? Sure, you can simply connect to something with a self-signed cert, but then you're putting the trust squarely back in the hands of that single server, without any method of verifiability. Turtles all the way down.
[0]: "The Roughtime creators state that 25% of Chrome’s certificate errors are caused by incorrect local clocks (off by days or more). A local clock within a few seconds of reference time is good enough."
I was typing up a response, but yours is great. You nailed it.
The only thing to add is that a tlsdate-like approach will not work consistently with TLS 1.3 as the standard makes time in the handshake OPTIONAL.
The only thing to add is that a tlsdate-like approach will not work consistently with TLS 1.3 as the standard makes time in the handshake OPTIONAL.
It's been a couple of years since I was really immersed in the operational aspects of NTP/PTP - glad to know I can still mostly follow along.
Nice theme on the blog.
Nice theme on the blog.
Thank you.
It looks like a big difference is that the packets are signed with a single source. Allowing for many requests to be signed with a single response. Seems like a good idea.
This should mean cost to serve is cheaper, but I need to read the protocol in more detail.
This should mean cost to serve is cheaper, but I need to read the protocol in more detail.