4 ms·

Securing Network Time

77 points by jwilk 9y ago

eadmund 9y ago
Interestingly, chrony is C. I thought for sure it'd be a more modern, safer language — but no, this level of code quality is clearly possible in C. I'm honestly surprised. Congratulations to the author, though!
- zackelan 9y ago
  Early releases of Chrony go as far back as 2006 [0] so the original codebase predates Rust, Go, etc. 0: https://git.tuxfamily.org/chrony/chrony.git/tag/?h=1.20 https://git.tuxfamily.org/chrony/chrony.git/tag/?h=1.20
- xorcist 9y ago
  There are other high quality C codebases, vsftpd, postfix, dovecot come to mind, maybe openssh nowadays.
  - zimpenfish 9y ago
    Most of djb's stuff comes to mind as well.
  - namibj 9y ago
    I'll add sqlite too, and also, cough, seL4. The latter is cough "secure due to being written in C" cough.....
- paulajohnson 9y ago
  Same here. So what is chrony doing differently? Is it just that the developer(s) are really clever, or are they using static analysis, or a better coding standard, or what? This is important. We don't often get the chance to compare side-by-side implementations of the same requirement, so when big differences turn up we need to understand why.
speps 9y ago
No author name and sounds like a PR article for Chrony. That's 2 red flags there.
- ibotty 9y ago
  Did you read the article at all?
  - dang 9y ago
    Would you mind following the site guidelines when commenting here? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html They ask you not to do the "did you read" trope. What would be particularly better is if you explained, instead, what the commenter missed in the article. Then we all learn something.
jlgaddis 9y ago
Chrony doesn't have all the bells and whistles that ntpd does but it does have all of the features that 99% of users will need. I've been running ntpd for many, many years and, due to inertia (and, sometimes, device support), have just stuck with it. I've started using Chrony since it started shipping on RHEL by default, though, and it's an excellent replacement. OpenNTPD has one feature, in particular, that I'd love to see supported in Chrony: "authenticated TLS constraints" [0]. > "Time can also be fetched from TLS HTTPS servers to reduce the impact of unauthenticated NTP man-in-the-middle attacks." In my testing, OpenNTPD wasn't nearly as accurate as Chrony or ntpd -- although I believe it wasn't really intended to be. Instead, if memory serves, it was designed to be a more secure replacement that was "good enough" for most uses. [0]: https://marc.info/?l=openbsd-tech&m=142356166731390&w=2 https://marc.info/?l=openbsd-tech&m=142356166731390&w=2
- xyzzy_plugh 9y ago
  We originally considered using times from TLS but many HTTP servers randomize the times. It was common enough, and likely to become more common, to be unreliable to us. In some cases, potentially dangerous (if times provided allow for using expired certificates).
  - jwilk 9y ago
    The mail says: We only use the time from the HTTPS header, and not the TLS timestamp, as the latter is most possibly randomized in modern SSL/TLS implementations. Do any HTTP servers lie in the Date header? That would be weird.
  - jlgaddis 9y ago
    As pointed out by jwilk, this comes from the "Date:" HTTP header, NOT the TLS timestamp. To clarify, they aren't intended to be exact or high-precision, like NTP timestamps. They are simply meant to give the NTP client some confidence that the (unauthenticated) timestamps being received from NTP servers/peers are accurate (and not being manipulated by an attacker). OpenNTPD supports both the singular and plural versions [0] of the directive and they operate in the same fashion as chrony's "server" and "pool" directives do (i.e. single vs. multiple hosts). With several such sources configured, outliers here can also be easily detected. Personally, I use several sources across many different organizations (U.S. government, U.S. tech companies, foreign entities, and my own servers) and it gives me much more confidence that an attacker can't manipulate the time on any of the hosts under my control. Please do reconsider adding this feature! If you'd like, I'd be more than happy to open a bug/file a feature request/whatever. [0]: https://man.openbsd.org/ntpd.conf https://man.openbsd.org/ntpd.conf

77 points by jwilk 9y ago

Interestingly, chrony is C. I thought for sure it'd be a more modern, safer language — but no, this level of code quality is clearly possible in C. I'm honestly surprised. Congratulations to the author, though!

zackelan 9y ago
Early releases of Chrony go as far back as 2006 [0] so the original codebase predates Rust, Go, etc. 0: https://git.tuxfamily.org/chrony/chrony.git/tag/?h=1.20 https://git.tuxfamily.org/chrony/chrony.git/tag/?h=1.20
xorcist 9y ago
There are other high quality C codebases, vsftpd, postfix, dovecot come to mind, maybe openssh nowadays.
- zimpenfish 9y ago
  Most of djb's stuff comes to mind as well.
- namibj 9y ago
  I'll add sqlite too, and also, cough, seL4. The latter is cough "secure due to being written in C" cough.....
paulajohnson 9y ago
Same here. So what is chrony doing differently? Is it just that the developer(s) are really clever, or are they using static analysis, or a better coding standard, or what? This is important. We don't often get the chance to compare side-by-side implementations of the same requirement, so when big differences turn up we need to understand why.

speps 9y ago

No author name and sounds like a PR article for Chrony. That's 2 red flags there.

ibotty 9y ago
Did you read the article at all?
- dang 9y ago
  Would you mind following the site guidelines when commenting here? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html They ask you not to do the "did you read" trope. What would be particularly better is if you explained, instead, what the commenter missed in the article. Then we all learn something.

jlgaddis 9y ago

Chrony doesn't have all the bells and whistles that ntpd does but it does have all of the features that 99% of users will need. I've been running ntpd for many, many years and, due to inertia (and, sometimes, device support), have just stuck with it. I've started using Chrony since it started shipping on RHEL by default, though, and it's an excellent replacement. OpenNTPD has one feature, in particular, that I'd love to see supported in Chrony: "authenticated TLS constraints" [0]. > "Time can also be fetched from TLS HTTPS servers to reduce the impact of unauthenticated NTP man-in-the-middle attacks." In my testing, OpenNTPD wasn't nearly as accurate as Chrony or ntpd -- although I believe it wasn't really intended to be. Instead, if memory serves, it was designed to be a more secure replacement that was "good enough" for most uses. [0]: https://marc.info/?l=openbsd-tech&m=142356166731390&w=2 https://marc.info/?l=openbsd-tech&m=142356166731390&w=2

xyzzy_plugh 9y ago
We originally considered using times from TLS but many HTTP servers randomize the times. It was common enough, and likely to become more common, to be unreliable to us. In some cases, potentially dangerous (if times provided allow for using expired certificates).
- jwilk 9y ago
  The mail says: We only use the time from the HTTPS header, and not the TLS timestamp, as the latter is most possibly randomized in modern SSL/TLS implementations. Do any HTTP servers lie in the Date header? That would be weird.
- jlgaddis 9y ago
  As pointed out by jwilk, this comes from the "Date:" HTTP header, NOT the TLS timestamp. To clarify, they aren't intended to be exact or high-precision, like NTP timestamps. They are simply meant to give the NTP client some confidence that the (unauthenticated) timestamps being received from NTP servers/peers are accurate (and not being manipulated by an attacker). OpenNTPD supports both the singular and plural versions [0] of the directive and they operate in the same fashion as chrony's "server" and "pool" directives do (i.e. single vs. multiple hosts). With several such sources configured, outliers here can also be easily detected. Personally, I use several sources across many different organizations (U.S. government, U.S. tech companies, foreign entities, and my own servers) and it gives me much more confidence that an attacker can't manipulate the time on any of the hosts under my control. Please do reconsider adding this feature! If you'd like, I'd be more than happy to open a bug/file a feature request/whatever. [0]: https://man.openbsd.org/ntpd.conf https://man.openbsd.org/ntpd.conf