Présentation de time.cloudflare.com

Cloudflare a toujours été leader dans le déploiement de versions sécurisées de protocoles Internet non sécurisés et dans leur mise à disposition gratuite pour tous. En 2014, nous avons lancé l’un des premiers services HTTPS gratuits et sécurisés au monde (Universal SSL), associé à notre plan HTTP gratuit existant. Lorsque nous avons lancé le résolveur DNS 1.1.1.1, nous avons également pris en charge les nouvelles versions sécurisées de DNS (DNS sur HTTPS et DNS sur TLS). Aujourd'hui, dans le cadre de la Crypto Week 2019, nous faisons la même chose pour le protocole de synchronisation horaire par réseau (NTP), le protocole dominant pour obtenir l'heure sur Internet.

Cette annonce est personnelle pour moi. Au cours des quatre dernières années, j'ai identifié et corrigé des vulnérabilités dans les protocoles de temps. Aujourd'hui, je suis fier d’aider à la présentation d’un service qui aurait rendu ma vie beaucoup plus facile entre 2015 et 2019 : time.cloudflare.com, un service de temps gratuit prenant en charge à la fois NTP et le nouveau protocole NTS (Network Time Security) pour sécuriser NTP. Désormais, n'importe qui peut avoir du temps en toute sécurité à partir de tous nos centres de données situés dans 180 villes à travers le monde.

Aujourd’hui, vous pouvez utiliser time.cloudflare.com comme source de temps pour tous vos appareils avec NTP, alors que les clients NTS sont encore en cours de développement. NTPsec inclut un support expérimental pour NTS. Si vous souhaitez obtenir des mises à jour sur le développement client NTS, envoyez-nous un e-mail pour nous rejoindre à [email protected]. Pour utiliser NTS afin de sécuriser la synchronisation horaire, contactez vos fournisseurs et renseignez-vous sur le support NTS.

En 2015, en tant que nouvel étudiant diplômé intéressé par la sécurité Internet, je suis tombé sur ce protocole Internet essentiellement ésotérique appelé le protocole de synchronisation horaire par réseau (NTP). NTP a été conçu pour synchroniser l'heure entre les systèmes informatiques communiquant sur des chemins réseau peu fiables et à latence variable. En fait, j'étudiais la sécurité du routage Internet, en particulier les attaques contre l’infrastructure à clé publique de ressource (RPKI), mais je ne trouvais aucune issue en raison d'un problème de vidage de la mémoire cache. En dernier recours, j'ai décidé de ramener manuellement l'heure sur mon ordinateur, et cela a fonctionné.

J'avais découvert l'importance du temps pour la sécurité informatique. La plupart des techniques de cryptographie utilisent des horodatages pour limiter les périodes de validité des certificats et des signatures. Lors de la connexion à un site Web, la connaissance de l'heure exacte garantit que le certificat que vous voyez est à jour et qu'il n'est pas compromis par un pirate. Lorsque vous examinez les journaux, la synchronisation horaire garantit la corrélation précise entre les événements sur différentes machines. Les certificats et l'infrastructure de journalisation peuvent ne plus connaître les minutes, les heures ou les mois de décalage horaire. D'autres applications, telles que la mise en cache et Bitcoin, sont sensibles aux différences, même minimes, de l'ordre de quelques secondes.

L'authentification à deux facteurs utilisant des numéros variables repose également sur des horloges précises. Elle crée ensuite le besoin pour les horloges d'ordinateur d'avoir accès à une heure raisonnablement précise et fournie en toute sécurité. NTP est le protocole le plus couramment utilisé pour la synchronisation de l'heure sur Internet. Si un pirate peut exploiter les failles du NTP pour manipuler l'heure sur des horloges d'ordinateur, il peut saper les garanties de sécurité fournies par ces systèmes.

Motivé par la gravité du problème, j'ai décidé de m'intéresser davantage à NTP et à sa sécurité. NTP est un très vieux protocole, puisque la nécessité de synchroniser l'heure sur tous les réseaux était visible très tôt. La première version normalisée du NTP remonte à 1985, tandis que la dernière version 4 du NTP a été achevée en 2010 (voir RFC5905).

Dans son mode le plus courant, NTP fonctionne lorsqu’un client envoi un paquet de requête à un serveur NTP qui répond ensuite avec son heure d’horloge. Le client calcule ensuite une estimation de la différence entre son horloge et l'horloge distante et tente de compenser le retard réseau. Le client NTP interroge plusieurs serveurs et utilise des algorithmes pour sélectionner la meilleure estimation puis rejette clairement les réponses fausses.

Étonnamment, les recherches sur le NTP et sa sécurité n'étaient pas très actives à l'époque. Auparavant, fin 2013 et début 2014, des attaques de déni de service distribué (DDoS) de grande envergure étaient menées en amplifiant le trafic provenant de serveurs NTP. Les pirates capables d'usurper l'adresse IP d'une victime ont été en mesure de canaliser une quantité considérable de trafic submergeant les domaines ciblés. Cela a attiré l'attention de certains chercheurs. Toutefois, ces attaques n’exploitaient pas les failles de la conception de protocole fondamentale. Les pirates ont simplement utilisé NTP comme multiplicateur de bande passante ennuyeux. Cloudflare a beaucoup écrit sur ces attaques et vous pouvez lire à ce sujet ici, ici et ici.

J'ai trouvé plusieurs failles dans la conception du protocole NTP principal et dans son application qui peuvent être exploitées par des pirates réseau pour lancer des attaques bien plus dévastatrices en décalant l'heure ou en refusant le service aux clients NTP. Ce qui est encore plus préoccupant, c'est que ces pirates n'ont pas besoin d'être un Monster-In-The-Middle (MITM), où un pirate peut modifier le trafic entre le client et le serveur afin de monter ces attaques. Un ensemble de documents récents rédigés par l'un d’entre nous a montré qu'un pirate hors du chemin présent n'importe où sur le réseau peut changer l'heure ou refuser le service aux clients NTP. Cela se fait notamment en abusant de la fragmentation IP.

La fragmentation est une caractéristique de la couche IP dans laquelle un paquet volumineux est divisé en plusieurs fragments plus petits, afin qu’ils puissent passer à travers les réseaux qui ne prennent pas en charge les paquets volumineux. Fondamentalement, tout élément de réseau aléatoire sur le chemin entre le client et le serveur peut envoyer un paquet spécial «fragmentation ICMP nécessaire» au serveur en lui demandant de fragmenter le paquet par exemple en X octets. Puisque le serveur n'est pas censé connaître les adresses IP de tous les éléments du réseau sur son chemin, ce paquet peut être envoyé à partir de n'importe quelle adresse IP d’origine.

Attaque par fragmentation contre NTP

Dans notre attaque, le pirate a exploité cette fonctionnalité pour que le serveur NTP fragmente son paquet de réponse NTP pour le client NTP victime. Le pirate usurpe ensuite avec soin des fragments de réponse chevauchants hors chemin, contenant ses valeurs d’horodatage. En exploitant davantage les règles de réassemblage pour les fragments superposés, le pirate trompe le client en lui demandant d’assembler un paquet contenant des fragments légitimes et les insertions du pirate. Cela évite les contrôles d'authenticité qui reposent sur des valeurs dans les parties source du paquet.

Au moment de la création de NTP en 1985, Il y avait deux objectifs principaux de conception pour le service qu’il devait fournir. Tout d'abord, ses concepteurs voulaient qu'il soit suffisamment robuste pour gérer les erreurs de réseau et les pannes d'équipement. Il a donc été conçu comme un service permettant au client de collecter des échantillons de synchronisation provenant de plusieurs pairs sur plusieurs voies de communication, puis, de faire la moyenne pour obtenir des mesures plus précises.

Le deuxième objectif était la répartition de la charge. Bien que chaque client souhaite communiquer avec des serveurs de temps directement connectés à des outils d'estimation du temps de haute précision, tels que des horloges atomiques, des GPS, etc., et disposant ainsi d'une heure plus précise, ces outils doivent être de grande capacité. Ainsi, afin de réduire la charge de protocole sur le réseau, le service a été conçu de manière hiérarchique. Au sommet de la hiérarchie, se trouvent les serveurs connectés à des sources de temps non NTP, qui distribuent le temps à d'autres serveurs et qui distribuent le temps à encore plus de serveurs. La plupart des ordinateurs se connectent à ces serveurs de deuxième ou troisième niveau.

La hiérarchie des strates du NTP

La spécification initiale (RFC 958) indique également les « non objectifs » du protocole, à-savoir l'authentification entre pairs et l'intégrité des données. La sécurité n’était pas considérée comme essentielle dans le premier réseau Internet relativement petit et peu sûr, et les protocoles ainsi que les applications, qui reposaient sur le temps nécessaire à la sécurité, n’existaient pas encore. La sécurisation du protocole NTP ne venait qu’en second lieu après son amélioration et sa mise en œuvre.

Au fur et à mesure du développement d'Internet, de plus en plus de protocoles Internet de base ont été sécurisés grâce à la cryptographie pour éviter les abus : TLS, DNSSEC, RPKI sont toutes des étapes pour assurer la sécurité de toutes les communications sur Internet. Ces protocoles utilisent le « temps » pour fournir des garanties de sécurité. Puisque la sécurité d'Internet dépend de la sécurité de NTP, il devient encore plus important de sécuriser le NTP.

Cette recherche a clairement montré la nécessité de sécuriser le NTP. En conséquence, l’organe de normalisation pour les protocoles Internet, l’IETF (Internet Engineering Task Force), s’est concentré sur l’authentification cryptographique du protocole NTP. À l'époque, même si NTPv4 prenait en charge l'authentification cryptographique symétrique et asymétrique, il était rarement utilisé en pratique en raison des limites des deux approches.

L'approche symétrique de NTPv4 pour sécuriser la synchronisation ne s'adapte pas, puisque la clé symétrique doit être précédemment partagée et configurée manuellement : imaginez que si chaque client sur terre avait besoin d’une clé secrète spéciale avec les serveurs desquels il voudrait obtenir le temps, les entreprises qui exploiteraient ces serveurs auraient beaucoup à faire pour gérer les clés. Cela rend cette solution assez lourde pour les serveurs publics qui doivent accepter les requêtes de clients arbitraires. En contexte, le NIST exploite d’importants serveurs de temps publics et distribue des clés symétriques uniquement aux utilisateurs qui s’enregistrent, une fois par an, par courrier américain ou par télécopie. L'US Naval Office fait quelque chose de similaire.

Le protocole Autokey décrit dans le document RFC 5906 a été le premier pour tenter de résoudre le problème de la distribution des clés. De nombreux serveurs NTP publics ne prennent pas en charge Autokey (par exemple, les serveurs de temps NIST et USNO et de nombreux serveurs dans pool.ntp.org). Le protocole est sérieusement endommagé car n’importe quel pirate du réseau peut facilement extraire la clé secrète partagée entre le client et le serveur. Les mécanismes d'authentification sont non standard et assez idiosyncrasiques.

La prochaine étape est de sécuriser Internet, c’est-à-dire l’authentifier et le crypter. Mais jusqu'à présent, NTP reste généralement peu sûr, malgré le développement continu du protocole. En attendant, de plus en plus de services en dépendent.

Chronologie du développement du NTP

Après la publication de notre document, la communauté NTP a suscité beaucoup plus d'enthousiasme au sein de l’organe de normalisation pour les protocoles Internet, de l'IETF (Internet Engineering Task Force) et à l'extérieur pour l'amélioration de la sécurité du NTP. Comme solution à court terme, le logiciel d’implémentation de référence ntpd a été corrigé pour plusieurs défaillances que nous avons détectées. Et pour une solution à long terme, la communauté a réalisé le besoin urgent d'un protocole de synchronisation temporelle sécurisé et authentifié basé sur la cryptographie à clé publique, qui permet le cryptage et l'authentification, sans nécessiter le partage préalable des documents clés. Aujourd'hui, nous avons un projet de Sécurité du temps de réseau (NTS) à l'IETF, grâce au travail de dizaines d'individus dévoués du groupe de travail NTP.

En résumé, le protocole NTS est divisé en deux phases. La première phase est l’échange de clé NTS qui établit le document clé nécessaire entre le client NTP et le serveur. Cette phase utilise l’établissement de liaison TLS (Transport Layer Security) et repose sur la même infrastructure à clé publique que le Web. Une fois les clés échangées, le canal TLS se ferme et le protocole entre dans la deuxième phase. Dans cette phase, les résultats de cet établissement de liaison TLS sont utilisés pour authentifier les paquets de synchronisation de temps NTP via des champs d'extension. Le lecteur intéressé peut trouver plus d'informations dans le brouillon Internet.

Cloudflare annonce aujourd'hui son service de temps gratuit à tous les internautes. Nous avons l'intention de résoudre les problèmes liés aux services de temps publics existants, notamment en augmentant la disponibilité, la robustesse et la sécurité.

Nous utilisons notre réseau mondial pour offrir un avantage en termes de latence et de précision. Nos 180 sites à travers le monde utilisent tous anycast pour acheminer automatiquement vos paquets vers notre serveur le plus proche. Tous nos serveurs sont synchronisés avec les fournisseurs de services de temps de la strate 1, puis offrent NTP au grand public, de la même manière que les autres fournisseurs de NTP publics. La plus grande source d'inexactitude pour les protocoles de synchronisation de temps est l'asymétrie du réseau, qui entraîne une différence de temps de trajet entre le client et le serveur et du serveur au client. Toutefois, la proximité de nos serveurs avec les utilisateurs signifie qu’il y aura moins de gigue, une mesure de la variance de la latence sur le réseau et une asymétrie possible dans les chemins de paquets. Nous espérons également que, dans les régions où les serveurs NTP sont rares, notre service améliore considérablement la capacité et la qualité de l’environnement NTP.

Les serveurs Cloudflare obtiennent le temps authentifié en utilisant une clé symétrique partagée avec nos serveurs en amont de la strate 1. Ces serveurs en amont sont répartis géographiquement et garantissent que nos serveurs disposent d'une heure précise dans nos centres de données. Mais cette approche de la sécurisation du temps n’est pas adaptée. Nous avons dû échanger des e-mails individuellement avec les entreprises qui exploitent des serveurs de la strate 1 et négocier l'autorisation de les utiliser. Bien que ce soit une solution pour nous, ce n’est pas une solution pour tout le monde sur Internet.

En tant que fournisseur de service de temps sécurisé, Cloudflare est fier d’annoncer que nous sommes parmi les premiers à offrir un service de temps sécurisé public et gratuit basé sur Network Time Security. Nous avons mis en œuvre le dernier projet NTS IETF. Au fur et à mesure que ce projet avance dans le processus de normalisation Internet, nous nous engageons à maintenir nos services à jour.

La plupart des implémentations de NTP travaillent actuellement sur le support NTS et nous espérons que les prochains mois verront une introduction plus large ainsi que l’intégration du projet de protocole actuel à un RFC. Nous avons actuellement une interopérabilité avec NTPsec qui a mis en œuvre le projet 18 de NTS. Nous espérons que notre service accélérera l'adoption de cette amélioration importante de la sécurité Internet. Comme il s’agit d’un nouveau service sans exigence de compatibilité rétroactive, nous exigeons l’utilisation de TLS v1.3 avec celui-ci pour promouvoir l’adoption de la version la plus sécurisée de TLS.

Si vous avez un client NTS, orientez-le vers time.cloudflare.com:1234. Sinon, orientez votre client NTP vers time.cloudflare.com. Plus de détails sur la configuration sont disponibles dans la documentation pour développeurs.

De notre service de Roughtime à Universal SSL, Cloudflare a joué un rôle dans l’extension de la disponibilité et de l’utilisation de protocoles sécurisés. Désormais, avec notre service de temps public gratuit, nous offrons une alternative fiable et largement disponible à un autre protocole hérité non sécurisé. Notre mission consiste à créer un Internet plus rapide, plus fiable et plus sécurisé pour tous.

Merci aux nombreux autres ingénieurs qui ont travaillé sur ce projet, dont Watson Ladd, Gabbi Fisher et Dina Kozlov

Cet article a été écrit par Aanchal Malhotra, assistant de recherche à la maîtrise à l’Université de Boston et ancienne stagiaire de Cloudflare au sein de l’équipe de cryptographie.