Télécharger les sites web qui utilisent TornadoServer

À propos de TornadoServer

Un hôte qui fait tourner TornadoServer le dit en général lui-même, en toutes lettres, dans un en-tête qu’il attache à chaque réponse qu’il envoie. Un nom donné de cette façon est une preuve directe plutôt qu’une déduction tirée du code qu’un navigateur télécharge, donc la confiance dans ce relevé est plus élevée qu’elle ne le serait pour une bibliothèque côté client, et le mode de défaillance est différent lui aussi.

Ce qu’implique cet en-tête mérite d’être déplié. Tornado est un framework web asynchrone et une bibliothèque réseau écrite en Python, conçue pour des connexions de longue durée et une forte concurrence plutôt que pour le rendu de pages, si bien qu’on la trouve derrière des fonctions temps réel : sockets maintenus ouverts, points de terminaison en flux, services de notification, interfaces d’appareils et d’équipements, tableaux de bord internes, et API qui parlent à autre chose qu’un navigateur. La voir répondre directement sur un port public veut aussi dire qu’aucun proxy inverse ne se place devant pour réécrire l’en-tête, ce qui est en soi instructif. Les déploiements de cette forme ont tendance à être petits, construits pour un usage précis ou embarqués, et moins susceptibles de porter les couches d’exploitation qu’aurait un grand parc web.

Les origines expliquent une partie du motif. Le framework a été écrit au sein d’une startup et ouvert en open source par Facebook (Meta) en 2009 sous licence Apache 2.0, à une époque où Python n’avait pas de réponse convaincante aux connexions concurrentes. La base d’utilisateurs est depuis composée de développeurs qui construisent des services plutôt que de propriétaires qui construisent des sites, ce qui explique pourquoi l’étiquette de la catégorie Web servers lui convient mieux que ne le ferait n’importe quelle catégorie de contenu ou de commerce. En octobre 2026 nous détectons TornadoServer sur 342 sites.

C’est dans les données de version qu’un relevé de serveur justifie son existence. Nous voyons 39 versions distinctes qui répondent, et la version enregistrée le plus souvent est 6.1. Un éventail aussi large à l’intérieur d’un même framework décrit des habitudes de déploiement plutôt que le logiciel : les services de longue durée sont construits, mis en conteneur puis laissés tranquilles, et un framework qui tourne sans bruit pendant des années est rarement mis à niveau selon un calendrier. Pour une équipe sécurité, un inventaire de services joignables publiquement étiqueté par version est un outil de cadrage, car un avis de sécurité s’applique à une plage et cette plage doit devenir une liste d’hôtes avant que quiconque puisse agir.

La limite évidente va dans l’autre sens que l’histoire des versions. Beaucoup d’applications Tornado se trouvent derrière un proxy ou un répartiteur de charge cloud qui remplace ou retire l’en-tête de serveur, et ces déploiements nous restent invisibles quel que soit leur usage. Notre liste n’est pas un parc installé. Notre liste est l’ensemble des points de terminaison où le framework répond pour lui-même, ce qui penche vers les services exposés et s’écarte des parcs de production gérés.

C’est cette distinction qui rend l’export utile plutôt que décoratif. Vérifier un hôte vous dit ce qu’un serveur admet. Une liste de tous les domaines où le framework a répondu permet à un chercheur en sécurité de cadrer l’exposition sur une plage de versions, permet à un fournisseur d’infrastructure de trouver les équipes qui exploitent elles-mêmes leurs services et pourraient en acheter un géré, et permet à un analyste de mesurer comment un framework vieillit une fois qu’il est passé de mode sans sortir de production. Aucune de ces questions ne trouve de réponse un nom d’hôte à la fois.