tlsdate: The Secure Alternative for ntpd, ntpdate and rdate

tlsdate

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.

[root@archlinux ~]# tlsdate -h
tlsdate usage:
[-h|–help]
[-s|–skip-verification]
[-n|–dont-set-clock]
[-H|–host] [hostname|ip]
[-p|–port] [port number]
[-P|–protocol] [sslv23|sslv3|tlsv1]
[-C|–certcontainer] [dirname|filename]
[-v|–verbose]
[-V|–showtime] [human|raw]
[-t|–timewarp]
[-l|–leap]
[-x|–proxy] [url]
[-w|–http]

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

Screenshot of tlsdate in action and synchronization the time of a system

Time synchronization with tlsdate

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.

Security

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.

Conclusion

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.

 

References:

[1] https://www.ietf.org/rfc/rfc2246.txt

One more thing...

Keep learning

So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert.

See training package




Lynis Enterprise screenshot to help with system hardeningSecurity scanning with Lynis and Lynis Enterprise

Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance.


Download

2 comments

  • Scott J.Scott J.

    In my case, tlsdate refused to update my clock since the time was too far in the future:
    root@raspberrypi:~# tlsdate -v
    V: tlsdate version 0.0.13
    V: We were called with the following arguments:
    V: validate SSL certificates host = google.com:443
    V: RECENT_COMPILE_DATE is 1432990555.000000
    V: we’ll do the time warp another time – we’re not setting clock
    V: time is currently 1464358849.770895111
    V: time is greater than RECENT_COMPILE_DATE
    V: using TLSv1_client_method()
    V: Using OpenSSL for SSL
    V: opening socket to google.com:443
    V: In TLS response, T=1472332813
    certification verification error: 9
    child process failed in SSL handshake

    so I had to force it to “leap” to a different time with this:
    root@raspberrypi:~# tlsdate -l

    then it was set correctly.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.