Le NTS doit-il se prouver de bout en bout ?
Publié le 12 août 2026 — mesures de la campagne scellée du 7 août 2026, vérifications directes du 12 août.
Le NTS (RFC 8915, texte de la RFC) authentifie l'échange entre un client et son serveur de temps. La question que cette page pose n'est pas de savoir s'il fonctionne — il fonctionne — mais jusqu'où il porte. Un serveur qui vous sert une heure signée tient lui-même son heure de quelqu'un. Que savez-vous de ce lien-là ?
Nous avons cherché la réponse dans nos propres mesures, et nous ne l'avons pas trouvée. Ce qui suit décrit ce que la mesure permet d'établir, ce qu'elle ne permet pas, et pourquoi l'écart entre les deux est le vrai sujet.
Dix serveurs annoncent une sécurité qu'ils ne délivrent pas
Point de départ, sans inférence : sur la campagne du 7 août, dix points d'accès présentent un NTS-KE valide depuis nos six réseaux d'observation et ne délivrent jamais d'heure authentifiée. La poignée de main aboutit, le certificat est bon, et l'heure ne vient pas.
Aucun institut n'y figure. Ce sont deux serveurs d'un même opérateur, un hébergeur, et six membres du pool répartis entre États-Unis, Allemagne, Royaume-Uni et Pays-Bas. Le fait intéressant n'est pas leur identité, c'est qu'annoncer le NTS et le rendre sont deux choses distinctes, et que seule une mesure de l'heure elle-même les sépare. Un contrôle qui s'arrête au NTS-KE valide ces dix-là.
Vous pouvez le vérifier sur n'importe quel serveur avec un validateur NTS, qui teste l'obtention de l'heure et pas seulement la poignée de main.
Le nom interrogé fait partie du service
Avant d'aller plus haut dans la chaîne, un obstacle qu'on ne contourne pas.
Une machine, deux noms, deux résultats
ntp1.de-cix.net est un CNAME vers ptbtime1.ptb.de, le serveur de
l'institut allemand de métrologie. Même machine, même adresse, même certificat, même port. Voici
ce que chrony en fait, le 12 août 2026 :
$ chronyd -Q "server ptbtime1.ptb.de iburst nts" System clock wrong by 0.002035 seconds (ignored) $ chronyd -Q "server ntp1.de-cix.net iburst nts" TLS handshake with [2001:638:610:be01::108]:4460 (ntp1.de-cix.net) failed : The certificate is NOT trusted. The name in the certificate does not match the expected. No suitable source for synchronisation
Le certificat ne porte qu'un nom, ptbtime1.ptb.de. Personne n'a tort : DE-CIX
publie un alias vers un serveur public, la PTB publie un certificat pour son propre nom. C'est
la composition des deux qui casse.
Deux conséquences, et la seconde est celle qui compte pour la suite :
- l'échec n'est pas une dégradation.
chronyne retombe pas sur du NTP simple, il refuse la source. Configurer l'alias avecnts, ce n'est pas obtenir une heure moins sûre, c'est n'en obtenir aucune ; - le refid ne transporte qu'une adresse — ici, qui plus est, un condensé de l'adresse IPv6. Savoir quelle machine est l'amont ne dit donc pas si son authentification fonctionne, puisque le résultat dépend du nom, et que le nom n'apparaît nulle part dans la chaîne observable.
Ce que la mesure permet d'affirmer, et où elle s'arrête
La campagne du 7 août — publiée dans le registre européen mesuré — retient 265 serveurs délivrant une heure authentifiée. Leur amont se répartit ainsi :
| Situation de l'amont | serveurs |
|---|---|
| stratum 1 — leur propre horloge, aucun amont réseau | 75 |
| amont que nous pouvons nommer | 86 |
| amont hors de notre périmètre de mesure | 102 |
| aucun refid publié | 2 |
Sur ces 86 chaînes, onze — 12,8 % ont un amont dont nous obtenons nous-mêmes l'heure authentifiée.
Le refid ne sait pas désigner une adresse IPv6
Ce premier chiffre porte sur un sous-échantillon, et il faut dire lequel. Le champ refid de la RFC 5905 fait quatre octets : une adresse IPv6 n'y entre pas. Un serveur qui suit son amont en IPv6 y place donc un condensé de quatre octets, qui ressemble à une IPv4 sans en être une. Résoudre les refids par simple correspondance d'adresse revient à ne voir que les chaînes en IPv4.
On peut en récupérer une partie : le condensé se recalcule pour toute adresse IPv6 que nous connaissons déjà. Avec les 3 108 adresses IPv6 de notre inventaire, 70 chaînes supplémentaires deviennent nommables, dont 48 ont un amont qui sert du NTS.
Ce déhachage est reproductible sans nous : le refid vaut
MD5(adresse IPv6)[0:4], écrit en quadruplet. Il ne demande ni notre base ni notre
table de résolution — seulement l'adresse. Voici les amonts vers lesquels le plus de chaînes NTS se rattachent, avec la leur. La colonne
compte les chaînes rattrapées par déhachage, pas le nombre total de suiveurs de la
machine — qui est bien plus élevé, et que le fichier scellé donne directement.
| chaînes NTS rattrapées | amont | adresse IPv6 à rehacher |
|---|---|---|
| 9 | a.st1.ntp.br (NTP.br) | 2001:12ff:0:7::186 |
| 8 | ptbtime1.ptb.de (PTB) | 2001:638:610:be01::108 |
| 7 | ntppool2.time.nl (SIDN Labs) | 2a00:d78:0:712:94:198:159:16 |
| 6 | ntp02.maillink.ch | 2a02:168:420b:4::7b:12 |
| 5 | ntppool1.time.nl (SIDN Labs) | 2a00:d78:0:712:94:198:159:15 |
| 3 | ptbtime2.ptb.de | 2001:638:610:be01::104 |
| 3 | ntp.ripe.net | 2001:67c:2e8:14:ffff::229 |
| 2 | ntp0.linx.net | 2a01:40:5459:7::2 |
| 2 | ptbtime4.ptb.de | 2001:638:610:cecf::7b |
Sur les 70 chaînes rattrapées, 68 pointent vers un amont que nous pouvons nommer. Les 2 autres visent une machine que notre politique d'anonymat couvre : elles sont comptées, pas nommées, et leur adresse n'est pas publiée.
| Méthode de résolution | chaînes nommables | amont servant du NTS | part |
|---|---|---|---|
| refid = adresse IPv4 mesurée | 86 | 11 | 12,8 % |
| + condensés IPv6 déhachés | 156 | 59 | 37,8 % |
L'écart entre les deux lignes est le résultat : il ne mesure pas l'écosystème, il mesure notre propre angle mort. Une résolution naïve du refid sous-estime d'un facteur trois les chaînes dont l'amont est authentifiable, et cette sous-estimation porte entièrement sur l'IPv6. Elle se réduit à mesure que notre inventaire d'adresses grossit — on ne peut déhacher que ce dont on connaît déjà l'adresse.
Dans les deux cas, le chiffre reste un majorant, et il faut insister : nous mesurons que l'amont offre le NTS publiquement, jamais que le lien l'utilise. Aucune de ces chaînes n'est prouvée authentifiée de bout en bout ; elles sont les seules qui pourraient l'être.
Le complément ne se dit pas « en clair ». Pour les 62,2 % restants, le NTS de l'amont n'est pas établi — ce qui recouvre trois situations qu'aucune mesure extérieure ne sépare : un amont qui n'offre pas le NTS, un amont qui l'offre à une liste fermée dont nous ne faisons pas partie, et un amont qui l'offre sous un nom que nous n'avons pas interrogé.
saturne.obs-besancon.fr, cité comme amont par
plusieurs serveurs français joignables, ne répond à aucun de nos six points d'observation :
nous ne pouvons rien en dire, ni dans un sens ni dans l'autre. Compter ce silence comme une
absence de NTS fabriquerait un chiffre à partir de notre propre angle mort.
La bonne question n'est pas le chiffrement, c'est le segment exposé
Puisque le transport du lien amont est indécidable, mesurons ce qui l'est : où passe ce lien. Sur les 86 chaînes nommables :
| Résolution de l'amont | traverse l'internet public | reste chez l'opérateur | total | part publique |
|---|---|---|---|---|
| par adresse IPv4 | 81 | 5 | 86 | 94,2 % |
| par condensé IPv6 déhaché | 61 | 9 | 70 | 87,1 % |
| ensemble | 142 | 14 | 156 | 91,0 % |
Les chaînes en IPv6 sont un peu moins exposées — 87,1 % contre 94,2 % — et l'écart s'explique : elles rattachent davantage de suiveurs à des racines institutionnelles dual-stack, dont une partie sont chez le même opérateur. L'ordre de grandeur, lui, ne bouge pas : neuf chaînes sur dix ont leur maillon amont sur l'internet public, quelle que soit la façon dont on les résout.
Le domaine et le préfixe sont des faits publics : ce partage ne demande aucune inférence. Et il change complètement la lecture d'un cas que nous connaissons bien.
La racine française, et ses quarante suiveurs
ntp-p1.obspm.fr est un stratum 1 synchronisé sur UTC(OP), la référence
nationale. Sa page officielle annonce le NTS sur le serveur secondaire depuis le
4 août 2026, et n'en dit rien sur le primaire — un silence informatif, dans un document
qui documente le NTS partout où il existe. Elle précise aussi son usage, sur sa page officielle :
que ce primaire « ne doit être utilisé que pour synchroniser des serveurs secondaires
desservant des sites importants ».
Nous mesurons quarante serveurs qui le suivent, dans cinq pays, dont six délivrent une heure authentifiée au monde entier : le secondaire de l'Observatoire lui-même, le pool NTS néerlandais, un opérateur français, et trois des nôtres.
Cette architecture n'est pas en cause : un primaire qui sert les secondaires de son propre
opérateur est exactement dans son rôle, et l'Observatoire le documente comme tel. Ce que la figure
montre est ailleurs — un seul de ces six est sur son réseau. Le lien
ntp.obspm.fr → ntp-p1.obspm.fr ne traverse rien : l'architecture est parfaitement
défendable. Le lien ntp9.rdem-systems.com → ntp-p1.obspm.fr traverse l'internet
public. Même absence d'authentification,
deux risques sans rapport — et c'est exactement pourquoi « faire du NTS » n'est pas
une réponse à soi seul.
Un stratum 1 sans NTS n'est pas un défaut
Il faut le dire, parce que la lecture facile est l'inverse. Un serveur primaire est un appareil de référence : une horloge disciplinée par un signal physique, conçue pour servir une poignée de secondaires. Le dimensionnement date d'une époque où les liens ne permettaient pas d'exposer une telle machine au tout-venant, et cette contrainte n'a pas disparu : le NTS y ajoute un point terminal TLS, une chaîne de certificats à renouveler, une gestion de clés. C'est un objet d'exploitation étranger à une horloge. Son absence sur un primaire peut tenir au matériel, à un calendrier, à une politique de sécurité — nous n'en savons rien, et nous ne le devinons pas.
La règle d'usage de l'Observatoire n'est donc pas une restriction bureaucratique : c'est la description de ce pour quoi la machine existe. Le défaut n'est pas à la racine. Il est chez les 94 % qui s'y adossent par l'internet public, souvent hors de l'usage déclaré.
La figure miroir : une racine qui, elle, sert du NTS
Le même relevé porte le cas inverse. ptbtime1 à ptbtime4.ptb.de, servis
par l'institut allemand de métrologie, servent du NTS et sont suivis par
quatre-vingt-quatorze serveurs que nous mesurons, dont neuf servent eux-mêmes
une heure authentifiée.
| Racine | sert du NTS | suiveurs mesurés | dont servant du NTS |
|---|---|---|---|
ntp-p1.obspm.fr (UTC(OP)) | aucune trace publique | 40 | 6 |
ptbtime1.ptb.de (PTB) | oui | 94 | 9 |
Les deux colonnes comptent la même population sur les deux lignes : tous les serveurs
dont le refid désigne cette racine, puis ceux d'entre eux qui servent eux-mêmes une heure
authentifiée. Pour ptbtime1, les deux familles sont réunies — son adresse IPv4 et
le condensé de son IPv6. L'asymétrie n'en est pas une : ntp-p1.obspm.fr
n'a pas d'enregistrement AAAA, il est en IPv4 seule, et un unique refid suffit donc à le compter
complètement ; ptbtime1 est dual-stack, il en faut deux.
Même structure, réponse opposée. Cela règle la question de la section précédente sans procès d'intention : un institut national de métrologie l'a fait, donc c'est possible — et ceux qui ne l'ont pas fait ont peut-être des contraintes que nous ne connaissons pas. Nous mesurons ce qui est servi, pas ce qui l'explique. L'authentification d'une racine est une propriété des acteurs et de leurs moyens, pas du protocole.
Huit questions que ces mesures posent
1. À qui profite la signature ?
Un client obtient une heure signée d'un serveur dont l'amont est invérifiable. Qui est rassuré : le client, ou l'opérateur qui peut désormais écrire « NTS » sur sa page ?
2. Que vérifie un audit qui coche « NTS » ?
L'auditeur constate le dernier saut. Il ne peut pas voir au-delà — nous venons de montrer que personne ne le peut. La case atteste donc l'existence d'un chiffrement, pas la provenance d'une heure. C'est une distinction que l'audit de traçabilité UTC doit porter explicitement.
3. La souveraineté se mesure-t-elle au dernier maillon ?
Un serveur français, authentifié, dont la source est hors de vue. Si la souveraineté consiste à maîtriser la chaîne, que signifie un dernier saut souverain ?
4. Que vaut une traçabilité dont un maillon est invérifiable ?
La traçabilité vers UTC exige une chaîne documentée et ininterrompue. La nôtre s'arrête au premier saut. Les cadres réglementaires demandent une traçabilité vers UTC, pas vers « un serveur qui dit venir d'UTC ».
5. Pourquoi ceux qui tiennent UTC sont-ils les derniers à servir du NTS ?
La question est inconfortable et la réponse est technique, pas morale : voir la section précédente. Elle mérite d'être posée pour éviter qu'on y réponde par un procès d'intention.
6. Et nous ?
Trois de nos serveurs suivent ntp-p1.obspm.fr par l'internet public — donc
au-delà de l'usage que sa page décrit, et c'est notre choix, pas le sien. La figure ne montre
cependant qu'un instant : nos douze secondaires mêlent sources NTP et NTS, et au moment du
relevé neuf d'entre eux avaient sélectionné un amont qui, lui, sert du NTS. Le refid ne
montre que le pair retenu à cette seconde, pas la configuration — et cette réserve
vaut pour tous les serveurs de cette page, pas seulement les nôtres. Ce sont des serveurs secondaires, et ils servent une heure
authentifiée en s'appuyant sur un amont que nous ne pouvons pas auditer. Nous ne faisons pas mieux que ce que nous mesurons chez les autres,
et c'est ce qui rend les sept autres questions publiables.
7. Que vaut le conseil « utilisez le pool avec NTS » ?
Cette configuration n'existe pas pour pool.ntp.org, et il faut
être précis : une de ses zones rend une machine différente à chaque résolution, tenue par un
opérateur différent, et aucun certificat ne peut couvrir cela sans donner à chaque bénévole le
pouvoir d'usurper les autres. Combien de guides la recommandent quand même ?
Des pools NTS existent pourtant — ntppool1 et ntppool2.time.nl
figurent parmi les amonts les plus suivis de notre relevé. Ils résolvent le problème autrement :
un point NTS-KE central, qui redirige ensuite le client vers un serveur de temps. La différence n'est
donc pas « pool ou pas », c'est qui détient la clé.
8. Si le dernier saut suffit, pourquoi exiger un stratum 1 souverain ?
Et s'il ne suffit pas, alors servir du NTS en stratum 2 est une demi-mesure — la nôtre comprise. Nous n'avons pas de réponse tranchée. Nous avons une observation : sur les 265 serveurs NTS mesurés, 75 sont des stratum 1 sans aucun amont réseau. Les seules chaînes entièrement auditables sont celles qui n'ont pas de chaîne.
9. Et un stratum 1 GNSS, qu'authentifie-t-il ?
Nous venons d'écrire que les seules chaînes entièrement auditables sont celles qui n'ont pas de chaîne. C'est faux, et il faut le dire dans la même page. Un stratum 1 discipliné par GNSS a lui aussi un amont : un signal radio, reçu sans authentification par la quasi-totalité des récepteurs. Un signal contrefait se fabrique avec du matériel courant, et le serveur le sert ensuite en NTS, signé, à toute sa clientèle.
Galileo répond à cela avec OSNMA, qui authentifie le message de navigation. Mais un récepteur qui ne l'implémente pas — l'immense majorité du parc installé — n'en tire rien, et rien dans le paquet NTP ne dit si le stratum 1 qui vous répond l'a activé. La question de cette page se déplace donc d'un cran : authentifier le dernier saut ne dit rien de l'amont, et authentifier l'amont réseau ne dit rien de la source physique. Nous ne mesurons pas l'OSNMA aujourd'hui, et nous ne connaissons aucun jeu de données public qui le fasse.
Les deux thèses, et ce qui les départagera
Le dernier saut suffit. L'attaquant réaliste est sur le chemin entre le client
et son serveur, pas dans le réseau d'un institut de métrologie. Et la pluralité des sources protège
mieux qu'une signature : chrony écarte par recoupement une source qui ment, quel que
soit le protocole. Une configuration à source unique reste la mauvaise configuration, fût-elle en
NTS.
Il faut du bout en bout. Sinon une signature authentique certifie une heure dont la provenance est invérifiable, et l'auditabilité s'arrête au premier saut — ce qui est précisément ce qu'un cadre de conformité demande de démontrer.
Nous penchons pour une troisième formulation : la question n'est ni « NTS ou pas », ni « bout en bout ou pas », mais quel segment est exposé, et à qui. C'est la seule qui se mesure sans inférence.
Méthode, limites, données
- Un refid ne montre qu'une source à l'instant du sondage. Un serveur configuré avec quatre sources n'en expose qu'une : nos décomptes de suiveurs sont des minorants, jamais des inventaires.
- Un amont IPv6 n'a pas d'adresse dans le refid, mais un condensé de quatre octets qui ressemble à une IPv4. Nous les résolvons par dictionnaire d'adresses connues, et des collisions restent possibles.
- Injoignable ne veut pas dire défaillant. Une ACL et une absence de service sont indiscernables depuis l'extérieur.
- Le périmètre est « serveurs NTP publics observables », pas « tous les serveurs NTP ».
- Mesures depuis six réseaux autonomes distincts. Campagne scellée, signée et horodatée : registre européen mesuré, carte mondiale. Données en CSV et JSON sous licence CC BY 4.0.
Vérifier par vous-même
Ce que vous pouvez contrôler s'arrête où s'arrête notre mesure — au dernier saut. Voici les outils ; au-delà, personne ne voit.
- valider l'obtention réelle de l'heure authentifiée — votre serveur la délivre-t-il, ou seulement un NTS-KE qui aboutit ?
- diagnostiquer un serveur NTP nommé — refid compris.
- mesurer depuis votre propre réseau — notre chemin n'est pas le vôtre, et les latences que nous publions sont les nôtres.