# What Is Network Time Security (NTS) and Its Benefits Over Standard NTP

> Discover Network Time Security NTS a secure extension of NTP using TLS 1.3 to prevent attacks and ensure accurate time sync. Learn its benefits over standard NTP.

- Repository: [Jauder Ho/nts-servers](https://github.com/jauderho/nts-servers)
- Tags: deep-dive
- Published: 2026-03-04

---

**Network Time Security (NTS) is a cryptographic extension to the Network Time Protocol (NTP) that uses TLS 1.3 and AEAD encryption to authenticate time synchronization and prevent man-in-the-middle attacks, replay attacks, and packet spoofing.**

Network Time Security (NTS) addresses critical vulnerabilities in traditional NTP deployments by adding transport-layer protection to time synchronization traffic. While NTP version 4 provides accurate time distribution, it was originally designed without mandatory authentication, leaving systems exposed to manipulation. The `jauderho/nts-servers` repository provides a curated, continuously validated list of NTS-enabled servers along with automation scripts to simplify secure time synchronization deployment.

## How Network Time Security (NTS) Works

NTS operates through a two-phase handshake that separates key establishment from time synchronization, minimizing the cryptographic overhead on the critical time path.

### TLS 1.3 Session Establishment

The NTS Key Establishment (NTS-KE) protocol uses **TLS 1.3** to negotiate a shared secret between the client and the NTS-enabled server. This occurs over port 4460 and provides strong server authentication without requiring pre-shared symmetric keys. According to the `jauderho/nts-servers` source code, the repository maintains a validated list of servers exposing these TLS endpoints in [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml).

### AEAD-Encrypted Time Synchronization

After the TLS handshake completes, NTP packets are wrapped in an **Authenticated Encryption with Associated Data (AEAD)** construct. This guarantees both **authenticity** and **integrity** of the timestamp data. Any tampering with the packet contents is immediately detectable by the client, preventing attackers from skewing system clocks by manipulating time packets in transit.

## Key Benefits of NTS vs. Standard NTP

| Benefit | Standard NTP | Network Time Security (NTS) |
|---------|--------------|------------------------------|
| **Authentication** | Optional, insecure MAC schemes using symmetric keys that are rarely deployed in practice. | Strong TLS-based server authentication; no manual key distribution required. |
| **Integrity** | No built-in integrity verification; packets can be altered undetected. | AEAD encryption guarantees tampering detection. |
| **Replay Protection** | Vulnerable to replayed timestamps that can disrupt synchronization. | TLS session keys provide nonce-based replay avoidance. |
| **Confidentiality** | Never encrypted; timing patterns are exposed. | Optional encryption shields client-side timing information. |
| **Operational Confidence** | Relies on network perimeter security and trust assumptions. | Cryptographic guarantees simplify firewall rules and reduce operational risk. |
| **Compatibility** | Universally supported by legacy devices. | Supported by modern clients including **chronyd ≥ 3.5** and **ntpd-rs** using the `nts` protocol keyword. |

## Implementing NTS with the jauderho/nts-servers Repository

The `jauderho/nts-servers` repository provides a complete workflow for adopting Network Time Security, from server validation to configuration generation.

### Validating NTS Server Connectivity

Before deploying NTS in production, verify that a server correctly supports the protocol using the provided validation script:

```bash

# Test connectivity to a specific NTS server

./scripts/ntsCheck.sh time.cloudflare.com

```

This script executes `chronyd -Q -t 5 "server <hostname> iburst nts maxsamples 1"` to perform a one-shot query. It reports success only if the TLS 1.3 handshake and subsequent NTP response are both valid, confirming the server is properly configured for Network Time Security.

### Generating Client Configuration Files

The repository automates the conversion of its curated server list into client-specific configuration formats:

```bash

# Generate chrony.conf and ntp.toml from the YAML source

./scripts/ntpServerConverter.py nts-sources.yml

```

After execution, the files [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) and [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml) are refreshed with the latest server list and the `nts` protocol keyword. These files can be copied directly to system directories to enable secure time synchronization.

### Maintaining Server Metadata

To ensure accurate stratum-based source selection, the repository includes automation for refreshing server metadata:

```bash

# Preview changes without modifying the source file

./scripts/ntsUpdateServers.py --dry-run

# Apply stratum updates to nts-sources.yml

./scripts/ntsUpdateServers.py

```

The [`ntsUpdateServers.py`](https://github.com/jauderho/nts-servers/blob/main/ntsUpdateServers.py) script queries each hostname using `ntpdate` or `ntpq`, extracts the current stratum value, and writes corrections back into [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml). This ensures that client selection logic based on stratum remains accurate as network topology changes.

## Configuration Examples for NTS Clients

### Chrony Configuration

The generated [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) file uses the `nts` keyword to enable Network Time Security:

```conf

# Example excerpt from chrony.conf

server time.cloudflare.com iburst nts
server 1.ntp.ubuntu.com iburst nts

```

Chrony automatically negotiates TLS 1.3 with each listed server, providing authenticated time without requiring manual key management.

### ntpd-rs Configuration

For the Rust-based `ntpd-rs` daemon, the [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml) file specifies NTS support:

```toml

# Example excerpt from ntp.toml

[[servers]]
host = "time.cloudflare.com"
nts = true
iburst = true

```

The daemon reads this configuration, initiates an NTS session, and updates the system clock securely.

## Summary

- **Network Time Security (NTS)** adds TLS 1.3 and AEAD encryption to standard NTP, preventing man-in-the-middle attacks, replay attacks, and packet spoofing.
- The `jauderho/nts-servers` repository provides a **curated list** of NTS-enabled servers in [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml), along with automation scripts for validation and configuration generation.
- **Key benefits** over plain NTP include strong server authentication, integrity protection, replay resistance, and optional confidentiality without requiring pre-shared keys.
- **Implementation** is straightforward using modern clients like **chronyd** (≥ 3.5) and **ntpd-rs** with the `nts` protocol keyword, supported by the repository's generated configuration files.

## Frequently Asked Questions

### What is the difference between NTP and NTS?

NTP (Network Time Protocol) is the standard protocol for synchronizing computer clocks across networks, but it lacks built-in security and is vulnerable to manipulation. NTS (Network Time Security) is a cryptographic extension to NTP that uses TLS 1.3 for authentication and AEAD encryption for integrity, protecting time synchronization from man-in-the-middle and replay attacks while maintaining the same time accuracy.

### Does NTS require TLS 1.3?

Yes, the NTS Key Establishment (NTS-KE) protocol specifically requires **TLS 1.3** for the initial handshake on port 4460. This requirement ensures strong cryptographic guarantees and eliminates legacy TLS vulnerabilities. The `jauderho/nts-servers` repository validates that listed servers properly support TLS 1.3 before including them in the curated [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) file.

### Which NTP clients support NTS?

Modern NTP clients that support the `nts` protocol keyword include **chronyd version 3.5 and later**, and **ntpd-rs** (a Rust-based implementation). These clients handle the TLS 1.3 handshake and AEAD decryption automatically when configured with the `nts` option. The `jauderho/nts-servers` repository provides ready-to-use configuration files for both clients in [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) and [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml).

### How do I verify if an NTS server is working?

You can verify NTS server functionality using the [`ntsCheck.sh`](https://github.com/jauderho/nts-servers/blob/main/ntsCheck.sh) script provided in the `jauderho/nts-servers` repository. Running `./scripts/ntsCheck.sh <hostname>` executes a one-shot query using `chronyd -Q` with the `nts` keyword, validating both the TLS 1.3 handshake and the authenticated NTP response. The script returns success only if the server properly supports the complete NTS protocol stack.