tlsdate: The Secure Alternative for ntpd, ntpdate and rdate
The Secure Alternative for ntpd, ntpdate and rdate
The common protocol to synchronize the time, is named Network Time Protocol, or NTP. While this protocol works great for synchronizing systems to one or more multiple time sources, it is not always easy to set-up. One alternative is using tlsdate, a secure replacement to keep your systems in sync.
About the Project
The software is written in 2012 by Jacob Appelbaum and can be found at GitHub: tlsdate. With the primary goal of securely synchronizing time, it uses an an unintentional part in the TLS protocol. For Chromium OS, tlsdate is actual the default synchronization tool.
TLS and tlsdate
Within the specification of the TLS protocol (RFC 2246 ), there are two functions (ServerHello and ClientHello), which should have a timestamp embedded in their responses. This is the time of the server, and can be used to compare it with the local time. The interesting part is that is can also be used for synchronizing the time. While not having the same accuracy as NTP, it is fairly precise.
After installing tlsdate on your distribution, start tlsdate with the -h option to get all options.
[root@archlinux ~]# tlsdate -h
[-p|–port] [port number]
To query the time, we can set the hostname with -H, provide the -v for verbose output and tell tlsdate not to sync the time yet (-n).
In this example we used one of the mail servers of Google to fetch the time, using TLSv1.
Even if you don’t want to use tlsdate to synchronize your systems, it can be used to query the time on a different system.
Pros and Cons
The biggest pros of tlsdate are:
Easy of use
The tlsdate toolkit is easy to use, with clear configuration files and option.
By leveraging TLS, synchronization is secure.
Speed of synchronizing
The tool is quick and directly synchronizes the time.
On the side of the cons we have:
Precision of the time synchronization process
For most systems however, having a precision within a few seconds is acceptable. But in some cases you want to know exactly what event happened when, especially for forensics and comparing events on multiple systems. Even a few milliseconds can be too much to accurately describe what happened.
TLS 1.3 and tlsdate
In the upcoming version of TLS, tlsdate might not function anymore.
Quality of Time
At this moment tlsdate lacks features like how “drifting” of time is managed, the amount of time difference due to slight differences in chip sets and electronic components. Another one is the lack of compensation for network latency. Last, but not least, the quality of the time source itself can not be measured. Where NTP uses a process similar to voting, tlsdate simply uses one source.
For desktops and most servers, tlsdate might be a great alternative to the existing arsenal of time synchronization services. If you want precision, we suggest to have a look at OpenNTPD, from the folks behind OpenBSD. If something is secure and well-audited, it’s the code coming from these projects.