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 1), 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.

Using tlsdate

After installing tlsdate on your distribution, start tlsdate with the -h option to get all options.

# tlsdate -h  
tlsdate usage:  
[-H|-host] [hostname|ip]  
[-p|-port] [port number]  
[-P|-protocol] [sslv23|sslv3|tlsv1]  
[-C|-certcontainer] [dirname|filename]  
[-V|-showtime] [human|raw]  
[-x|-proxy] [url]  

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.


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.




Small picture of Michael Boelen

This article has been written by our Linux security expert Michael Boelen. With focus on creating high-quality articles and relevant examples, he wants to improve the field of Linux security. No more web full of copy-pasted blog posts.

Discovered outdated information or have a question? Share your thoughts. Thanks for your contribution!

Mastodon icon