Let’s Encrypt is using ntpd-rs

Let’s Encrypt has high security requirement, so they deployed memory safe NTP implementation, ntpd-rs:

Interesting discussion: More Memory Safety for Let's Encrypt: Deploying ntpd-rs | Hacker News

1 Like

Please note that ntpd-rs already had two high-impact security issues in the server functionality. It could be crashed by attackers.

If you want to run it on a pool server, consider setting up a monitoring script ready to switch to something else if it starts crashing. Setting the systemd service to restart automatically on a crash doesn’t help much as it takes some time for the server to provide time to clients again and the attackers could be crashing it faster than that.


What do you think, are those bugs a kind of child-sickness, and their number will tend to go to zero asymptotically? Or, are those bugs rather structural, any new one may appear any time later?

In the case of ntpd, urgent fixes have almost all been due to logic errors, not the memory safety issues Rust avoids by language design. So an alternative implementation that is basically safe from buffer overruns, double-frees, etc is fine as far as it goes, but given ntpd-rs is a new codebase with little exposure in the wild compared to Chrony or ntpd, I expect these types of issues to continue to be a problem for years to come.


Yes, NTP as a networking protocol (the timing modes, not mode 6/7) is very simple and memory-safety issues in its implementations seem to be rare. The complexity is in the processing of NTP measurements, etc.

I think they will eventually sort the security issues out, but it will take some effort. As I see it, Rust is like C++, great for fast development, but not so great for maintaining long-term projects with minimum resources. The code is harder to read and reason about. As with any other language, it still needs good testing and fuzzing coverage. For an NTP client/server, Rust just turns memory-safety issues into denial-of-service issues.