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. chrony ne retombe pas sur du NTP simple, il refuse la source. Configurer l'alias avec nts, 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'amontserveurs
stratum 1 — leur propre horloge, aucun amont réseau75
amont que nous pouvons nommer86
amont hors de notre périmètre de mesure102
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
amontadresse IPv6 à rehacher
9a.st1.ntp.br (NTP.br)2001:12ff:0:7::186
8ptbtime1.ptb.de (PTB)2001:638:610:be01::108
7ntppool2.time.nl (SIDN Labs)2a00:d78:0:712:94:198:159:16
6ntp02.maillink.ch2a02:168:420b:4::7b:12
5ntppool1.time.nl (SIDN Labs)2a00:d78:0:712:94:198:159:15
3ptbtime2.ptb.de2001:638:610:be01::104
3ntp.ripe.net2001:67c:2e8:14:ffff::229
2ntp0.linx.net2a01:40:5459:7::2
2ptbtime4.ptb.de2001: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ésolutionchaînes nommablesamont servant du NTSpart
refid = adresse IPv4 mesurée861112,8 %
+ condensés IPv6 déhachés1565937,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é.

Pourquoi nous ne publions pas de pourcentage de chaînes « non authentifiées ». Une ACL sur le port 4460 et une absence de service produisent exactement la même observation depuis l'extérieur. 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'amonttraverse l'internet publicreste chez l'opérateurtotalpart publique
par adresse IPv48158694,2 %
par condensé IPv6 déhaché6197087,1 %
ensemble1421415691,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.

Racinesert du NTSsuiveurs mesurésdont servant du NTS
ntp-p1.obspm.fr (UTC(OP))aucune trace publique406
ptbtime1.ptb.de (PTB)oui949

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

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.

Questions fréquentes

Le NTS garantit-il que l'heure reçue est juste ?

Non. Le NTS garantit que vous parlez bien au serveur annoncé et que le paquet n'a pas été retouché en route. Il ne dit rien de la provenance de l'heure : un serveur peut servir, avec une signature parfaitement valide, une heure que son propre amont lui a mal donnée. La signature est authentique, le contenu ne l'est pas nécessairement.

Peut-on vérifier de l'extérieur si un serveur NTS interroge lui-même sa source en NTS ?

Non, et c'est structurel. Le champ refid identifie la source sélectionnée — une adresse IPv4, ou un condensé de quatre octets pour une source IPv6 — mais rien dans le paquet servi ne décrit comment le serveur joint cette source. La RFC 8915 ne modifie pas l'encodage du refid. Un serveur qui suit son amont en NTS et un serveur qui le suit en NTP simple servent des paquets identiques.

Un même serveur peut-il servir du NTS sous un nom et pas sous un autre ?

Oui, et c'est le fonctionnement normal de TLS. Le NTS-KE présente un certificat, et un client vérifie que le nom demandé y figure. Mesuré le 12 août 2026 : ntp1.de-cix.net est un CNAME vers ptbtime1.ptb.de ; interrogée sous son propre nom, la machine délivre une heure authentifiée, tandis que chrony rejette la même machine sous le nom de-cix avec « the name in the certificate does not match the expected ». Même adresse, même certificat, deux résultats.

Un serveur stratum 1 qui ne fait pas de NTS est-il un défaut ?

Pas en soi. Un serveur primaire est un appareil de référence dimensionné pour servir une poignée de serveurs secondaires, souvent sur le réseau de son propre opérateur. Le NTS y ajoute un point terminal TLS et des certificats à renouveler, c'est-à-dire un objet d'exploitation étranger à une horloge. La question n'est pas l'absence de NTS à la racine, mais le nombre d'opérateurs tiers qui s'y adossent par l'internet public.

Peut-on utiliser pool.ntp.org avec NTS ?

Non, et pas par retard : structurellement. Le NTS suppose un certificat lié au nom interrogé, or une zone du pool rend une machine différente à chaque résolution, tenue par un opérateur différent. Partager entre tous les bénévoles la clé de chiffrement des cookies leur donnerait le pouvoir d'usurper l'identité les uns des autres. Un membre du pool peut servir du NTS sous son propre nom ; jamais via la zone.