NTS Activé sur l'Ensemble de Notre Pool Sécurisé

Ce n'est pas la norme, et c'est tout l'intérêt : sur les 2598 serveurs de temps européens que nous mesurons depuis 6 réseaux, 7,4 % seulement servent du NTS — soit 192 points d'authentification pour tout un continent. Les autres distribuent une heure que personne ne peut authentifier. Le détail vit sur la carte mondiale et dans l'étude européenne, avec l'arbre des dépendances pour savoir sur quoi tout cela s'appuie.

La synchronisation temporelle est un composant critique de toute infrastructure informatique. Jusqu'à présent, le protocole NTP transmettait le temps en clair et sans authentification, exposant les systèmes à des attaques potentielles. Avec l'activation de NTS sur notre infrastructure, vos systèmes peuvent désormais vérifier cryptographiquement que le temps reçu provient bien de nos serveurs.

Pourquoi Activer NTS Maintenant ?

NTS (Network Time Security), standardisé par la RFC 8915 en septembre 2020, représente une évolution majeure du protocole NTP. Voici pourquoi c'est le moment d'adopter cette technologie.

L'Adoption S'Accélère

Arguments Techniques et Opérationnels

Les Risques de Sécurité Sans NTS

Le protocole NTP, conçu dans les années 1980, n'intègre aucun mécanisme de sécurité natif. Les paquets NTP circulent en UDP sans chiffrement ni authentification, ce qui expose les systèmes à plusieurs types d'attaques bien documentées :

Comment fonctionne NTS ?

NTS (Network Time Security) est défini par la RFC 8915. Le protocole fonctionne en deux phases :

1. Phase d'établissement (NTS-KE) : Le client établit une connexion TLS 1.3 avec le serveur sur le port 4460. Ils échangent des cookies chiffrés qui seront utilisés pour authentifier les échanges NTP suivants.
2. Phase de synchronisation : Les requêtes NTP classiques (port 123) incluent désormais des extensions cryptographiques. Chaque réponse est authentifiée grâce aux cookies négociés précédemment.

Nos Serveurs NTS Disponibles

L'ensemble de notre pool NTP supporte désormais NTS. Vous pouvez utiliser n'importe lequel de ces serveurs pour une synchronisation sécurisée. Tous les TLD sont valides : .com, .fr, .eu, .net, .org, .be, .biz, .info.

Serveurs Individuels (Stratum 2)

Entrées Pool (Load-Balanced)

Ces trois sous-pools de site couvrent neuf des douze serveurs. Les trois autres sont hors des salles parisiennes — dont un à Francfort : la diversité géographique fait partie de la résilience d'un pool, et ntp-pool.rdem-systems.com les sert exactement comme les autres. Ils n'ont pas de sous-pool à eux, car nous n'en publions un qu'à partir de trois adresses : en dessous, le mot « pool » désignerait une machine unique.

Pools par opérateur de transit

Pour cibler un réseau de transit précis (diversité de chemin, tests de conformité), nous exposons un pool par transitaire regroupant les serveurs joignables via cet AS :

Configurer Votre Client NTS

Chrony est le client NTP recommandé pour utiliser NTS. Il est disponible sur la plupart des distributions Linux modernes et supporte nativement NTS depuis la version 4.0.

Configuration Chrony avec NTS

Éditez votre fichier /etc/chrony/chrony.conf (ou /etc/chrony.conf) :

# /etc/chrony/chrony.conf - Configuration NTS RDEM Systems

# Serveurs NTS RDEM Systems (sécurisés)
# Vous pouvez mixer les TLD : .com, .fr, .eu, .net, .org, .be, .biz, .info
server ntp-pool.rdem-systems.com iburst nts
server ntp-1.rdem-systems.fr iburst nts
server ntp-2.rdem-systems.eu iburst nts
server ntp-3.rdem-systems.net iburst nts

# Fichier de dérive
driftfile /var/lib/chrony/drift

# Autoriser les mises à jour importantes au démarrage
makestep 1.0 3

# Activer le mode temps réel
rtcsync

# Journalisation
logdir /var/log/chronyCopier

Installation et Redémarrage

# Installation de Chrony (Debian/Ubuntu)
sudo apt update && sudo apt install chrony

# Ou sur RHEL/CentOS/Fedora
sudo dnf install chrony

# Redémarrage du service
sudo systemctl restart chronyd

# Vérification du statut
sudo systemctl status chronydCopier

Vérifier que NTS Fonctionne

Après avoir configuré Chrony avec NTS, vérifiez que l'authentification fonctionne correctement :

Commande chronyc sources

sudo chronyc -N sourcesCopier

Vous devriez voir vos sources avec le flag N indiquant que NTS est actif :

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp-pool.rdem-systems.c>     2   6   377    23   -145us[ -201us] +/-   12ms
^+ ntp-1.rdem-systems.com       2   6   377    24   +234us[ +178us] +/-   15ms
^+ ntp-2.rdem-systems.com       2   6   377    25   -89us[ -145us] +/-   14ms

Vérifier l'état NTS

sudo chronyc -N authdataCopier

Cette commande affiche les détails de l'authentification NTS pour chaque source :

Name/IP address         Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
ntp-pool.rdem-systems.c> NTS     1   15  256  23m    0    0    8  100
ntp-1.rdem-systems.com   NTS     1   15  256  24m    0    0    8  100
ntp-2.rdem-systems.com   NTS     1   15  256  25m    0    0    8  100

Questions Fréquentes

NTS fonctionne-t-il avec ntpd ?

Non, le daemon ntpd classique ne supporte pas NTS. Vous devez utiliser Chrony (recommandé), NTPsec ou ntpd-rs (Rust) pour bénéficier de NTS. Windows W32Time ne supporte pas non plus NTS.

Quel est l'impact sur les performances ?

L'impact est négligeable. La négociation TLS n'intervient qu'au démarrage et lors du renouvellement des cookies (environ toutes les heures). Les échanges NTP réguliers ajoutent seulement ~100 octets pour l'authentification.

Puis-je mixer NTS et NTP classique ?

Oui, Chrony peut utiliser simultanément des sources NTS et des sources NTP classiques. Cependant, pour une sécurité optimale, privilégiez les sources NTS.

Que se passe-t-il si NTS échoue ?

Par défaut, si NTS ne peut pas être établi, Chrony n'utilisera pas la source concernée. C'est un comportement sécurisé : mieux vaut ne pas synchroniser que synchroniser de manière non authentifiée.

Combien de serveurs NTS existent dans le monde ?

Deux chiffres circulent, et ils ne mesurent pas la même chose — d'où l'importance de dire lequel est lequel :

• Le décompte déclaratif mondial — jauderho/nts-servers recense les serveurs dont l'opérateur annonce le NTS, toutes zones confondues. C'est le référentiel que la communauté reconnaît, et RDEM Systems y figure avec 11 serveurs.
• Notre décompte mesuré européen — 192 machines servant du NTS, confirmées par une heure réellement authentifiée et non par un port ouvert, sur 2598 machines européennes sondées depuis 6 réseaux (campagne du 7 août 2026). Il est plus élevé que le déclaratif parce qu'il trouve du NTS non documenté — et plus sévère, parce qu'il en retire ce qui est annoncé sans être servi.

Les deux ne se contredisent pas : l'un compte des déclarations mondiales, l'autre des faits européens. Selon notre registre mesuré, les premiers opérateurs européens sont Netnod (Suède, 12 machines, toutes en stratum 1), RDEM Systems (France, Allemagne, 12 machines), SIDN Labs (Pays-Bas, 6 machines, dont 5 en stratum 1), PTB (Allemagne, 4 machines, toutes en stratum 1), Nothing to hide (Pays-Bas, 4 machines) et Tharyrok (France, Belgique, Allemagne, 4 machines). À nombre de machines égal, c'est la strate qui départage : un serveur stratum 1 tient sa propre référence de temps, un stratum 2 la reçoit d'ailleurs. 98 machines NTS européennes de plus sont servies par des opérateurs que nous ne pouvons pas nommer — bénévoles du pool sans nom d'organisation, ou machines découvertes par déduction et publiées sous pseudonyme. Elles comptent dans les totaux, pas dans ce classement.

Ce classement mérite une précision d'honnêteté : nous en sommes la source, et nous y figurons en 2^e position. Il est reproductible — le CSV filtré sur counted=yes et nts_measured=yes redonne exactement ces chiffres. C'est la seule garantie que nous puissions offrir contre notre propre biais : rendre le calcul refaisable sans nous.

Existe-t-il un pool NTS comme pool.ntp.org ?

Il faut distinguer deux choses que le raccourci habituel confond. Ce qui est incompatible avec NTS, c'est le modèle de pool.ntp.org : un DNS round-robin derrière lequel environ 2 400 opérateurs bénévoles européens répondent sous un même nom. NTS impose au client de valider le certificat pour le nom qu'il a interrogé — on ne peut pas faire détenir un certificat valide pour ce nom à 2 400 organisations indépendantes. Ce n'est pas une négligence du projet : c'est la conséquence directe de sa propriété fondatrice, n'importe qui peut contribuer sans être audité. NTS repose sur l'inverse.

Mais un pool NTS reste possible, sous trois formes — dont une qui tourne déjà.

1. Le pool mono-opérateur — un seul opérateur, un seul certificat déployé sur toutes ses machines derrière un nom unique. C'est simple, ça fonctionne aujourd'hui, et c'est ce que nous faisons avec ntp-pool.rdem-systems.com. La limite est claire : c'est un pool au sens de la répartition de charge, pas au sens de la diversité de confiance — un seul opérateur, une seule juridiction.

2. Le consortium restreint, trois ou quatre opérateurs, avec deux variantes qui n'ont pas le même coût :

• Clé privée partagée — un certificat unique pour le nom du pool, déployé chez chacun. Le plus simple à mettre en œuvre. Mais une compromission chez un seul opérateur compromet tout le pool, et pas seulement le nom : aussi la clé de chiffrement des cookies NTS, donc la capacité à forger des cookies valides au nom de tous les autres.
• Un certificat par opérateur, pour le même nom — il faut alors une autorité de certification qui accepte d'émettre un même nom d'hôte à plusieurs organisations distinctes. Contraignant et inhabituel, mais ce n'est pas un obstacle protocolaire.

3. Le pool à NTS-KE central — et celui-là n'est plus théorique. sectime.org, opéré par la Trifecta Tech Foundation avec un financement ICANN (2025-2027), tourne aujourd'hui. Le principe évite le problème du certificat au lieu de le résoudre : le client parle à un NTS-KE central (ke.sectime.org), qui présente un certificat valide pour son propre nom, délivre les cookies, puis renvoie le client vers un serveur membre par la négociation NTPv4 Server (RFC 8915 §4.1.7). Le membre conserve son nom et son certificat ; le pool s'authentifie auprès de lui par un jeton. Mesuré le 31 juillet 2026 : huit serveurs membres distincts vus en 72 poignées de main, dont sept localisés dans cinq pays (NL, FR, BE, DE, CH).

La contrepartie de ce troisième modèle est logicielle, et c'est la page d'adhésion du pool qui l'énonce : rejoindre suppose ntpd-rs en 1.9.0 ou supérieur — seule implémentation à gérer le mode pool en amont — ou une version modifiée de chrony (ntsauthtokenfile) ou de NTPsec (nts poolauth), deux directives absentes de la documentation amont de ces projets. Le seuil de 1.9.0 n'est pas arbitraire : les notes de version de ntpd-rs (12 juin 2026) indiquent le passage aux codepoints IANA alloués par anticipation pour le pool de type KELB — les versions antérieures parlent donc un autre dialecte — et qualifient ce mode d'expérimental. Notre pile de production est chrony amont : nous ne rejoignons pas ce pool, parce que nous refusons de faire dépendre une infrastructure de temps d'un correctif hors amont. Le projet reste utile, et recommandable à qui a la pile adéquate.

Autrement dit : ce qui manque à un pool NTS européen n'est pas une solution technique — elle existe, et elle tourne — mais un écosystème d'opérateurs pouvant y entrer sans changer de pile, ou prêts à s'entendre sur une gouvernance de la clé pour la variante consortium.

Un verrou pratique subsiste sur cette seconde variante — et il est en cours de levée à l'IETF. La validation ACME DNS-01 repose sur un nom unique, _acme-challenge.<nom>, qu'un CNAME ne peut déléguer qu'à une seule cible : un seul opérateur peut donc renouveler. Ce n'est pas propre au temps, c'est le problème classique des déploiements haute disponibilité où plusieurs piles indépendantes ont chacune besoin d'un certificat valide pour le même nom.

Le draft draft-ietf-acme-dns-account-challenge (ACME DNS Labeled With ACME Account ID Challenge) résout exactement ce cas : le nom de validation porte un label dérivé du compte ACME — _ujmmovf2vn55tgye._acme-challenge.pool-nts.eu — si bien que chaque opérateur a son propre nom de validation, son propre compte et sa propre clé privée, pour le même nom de pool. Plus de clé partagée, plus de coordination humaine à chaque renouvellement. Un second draft, draft-ietf-acme-dns-persist, va dans le même sens avec des enregistrements réutilisables. Les deux sont des documents de groupe de travail IETF, en révision 01 au 31 juillet 2026 — donc un chantier ouvert, pas une solution déployable aujourd'hui.

Quels systèmes d'exploitation supportent NTS par défaut ?

Ubuntu 25.10+ activera Chrony avec NTS par défaut — un tournant majeur. RHEL/Fedora et SUSE documentent la configuration NTS. La plupart des distributions Linux modernes permettent d'activer NTS facilement avec Chrony.

Peut-on externaliser la gestion de son infrastructure NTP/NTS ?

Oui. RDEM Systems assure l'infogérance et l'astreinte 24/7 de serveurs — incluant la synchronisation temporelle NTP/NTS, le monitoring de dérive, et la maintenance des configurations Chrony. Idéal pour les DSI qui veulent fiabiliser leur horodatage sans mobiliser d'équipe interne dédiée.

Comment garantir la conformité NTP pour MiFID II ou PCI-DSS ?

MiFID II (RTS 25) impose une traçabilité UTC dont le seuil dépend de l'activité : 100 μs pour le trading algorithmique à haute fréquence, 1 ms pour les autres formes de trading algorithmique, 1 s pour la saisie manuelle. PCI-DSS (exigence 10.6) exige une technologie de synchronisation et des sources de temps désignées, sans imposer NTP nommément. RDEM Systems propose un audit NTP/NTS en 1 journée : entretien technique avec vos adminsys, analyse d'architecture (sources, strates, redondance, SPOF), et livraison d'un rapport de conformité avec plan de remédiation. Contactez-nous →

💡 Vérifiez la compatibilité NTS de votre serveur avec le testeur ntp-tester.eu/nts

Et au-delà du dernier saut ?

Le NTS authentifie l'échange entre vous et votre serveur. Votre serveur, lui, tient son heure de quelqu'un d'autre, et cette partie-là de la chaîne n'est pas observable de l'extérieur. Nous l'avons mesurée : le NTS doit-il se prouver de bout en bout ?