Telegram Desktop a reçu une toute nouvelle méthode pour contourner les blocages, qui masque le trafic du service de messagerie sous une navigation web ordinaire via une connexion sécurisée. La technologie expérimentale WEB-proxy, présentée le 21 août 2026, transmet les données MTProxy via le transport WebView basé sur HTTPS ou WebSocket, ce qui rend le flux indiscernable d'une navigation web légitime et ouvre une nouvelle perspective d'accès au service dans des conditions restrictives.
Comment fonctionne le tunnel invisible
L'essence de l'innovation réside dans l'utilisation d'un flux multiplexé, acheminé via le moteur de navigateur intégré dans l'application. Le client conserve le chiffrement et l'encadrement habituels du MTProxy, mais au lieu de connexions TCP directes, il envoie toutes les données via une session WebView unique. Un format de trames spécial (OPEN, DATA, WINDOW, CLOSE) permet d'emballer de multiples connexions logiques de Telegram dans un seul canal sécurisé, qui ressemble extérieurement à un chargement standard de page web.
Du côté serveur, un relais fonctionne en recevant ce flux unique et en le séparant soigneusement en connexions individuelles pour les transmettre au MTProxy standard. Le nœud intermédiaire ne déchiffre pas le contenu et ne connaît pas les adresses de destination finales, agissant simplement comme un messager aveugle. La charge utile reste opaque à toutes les étapes après la transformation initiale par l'application, ce qui garantit la confidentialité même lors du passage par des nœuds supplémentaires.
La double vie du nom de domaine
Le WEB-proxy fonctionne sur un domaine HTTPS ordinaire, qui continue à héberger un site web public à part entière. La page passerelle pour le proxying n'est activée qu'en présence d'un paramètre spécial, calculé sur la base de la configuration. Toute requête ordinaire reçoit la page d'accueil standard de la ressource, créant ainsi une couverture fiable contre les systèmes de détection automatique.
Le choix de la méthode de transmission des données est strictement figé dans la page intermédiaire générée pour chaque session spécifique. L'adaptateur local transforme les connexions TCP en flux logiques et les combine au sein d'une seule session de transport, liée au domaine d'origine. Une telle architecture permet d'utiliser l'infrastructure des hébergements web ordinaires et des réseaux de diffusion de contenu (CDN) sans attirer l'attention sur l'activité de proxy.
Détails techniques de la mise en œuvre
La documentation complète pour le déploiement et le protocole est publiée dans le référentiel tproxy-server, décrivant toutes les nuances de configuration. L'utilisateur spécifie le nom canonique de l'hôte et le secret du MTProxy, à partir desquels un identifiant unique de capacité de connexion au pont est dérivé via HMAC-SHA256. Seule une requête GET précise avec un paramètre spécifique de 43 caractères permet d'accéder à la page spéciale ; toutes les autres visites sont traitées comme des consultations ordinaires.
Le lien de connexion a la forme https://t.me/webproxy?server=proxy.example.com&secret=... ou utilise le schéma tg://webproxy. Le port 443 et le protocole HTTPS sont obligatoires et fixés par la spécification du type WEB-proxy. Le protocole décrit assure une typage strict des requêtes et exclut toute activation accidentelle du pont.
État actuel du projet
Le développement est au stade de la preuve de concept et comprend une implémentation pour bureau, un client Android expérimental et des plans de support pour iOS. Toutes les plateformes utilisent la même page intermédiaire, le même format de trames et les mêmes composants serveur, ce qui simplifie les tests et le développement ultérieur. L'unification des parties client et serveur permet d'apporter rapidement des modifications et de tester des hypothèses sur différents systèmes d'exploitation.
L'apparition du WEB-proxy démontre une transition vers des méthodes plus sophistiquées d'intégration avec l'infrastructure web légitime. L'utilisation de mécanismes de navigateur standard et de protocoles sécurisés complique la tâche des systèmes de filtrage, qui doivent choisir entre un blocage total du trafic HTTPS et le maintien de la disponibilité des services ordinaires. La valeur pratique de la technologie sera déterminée par sa résistance aux méthodes d'analyse de trafic adaptatives et sa capacité à s'adapter sans perte de performance.
L'avis de l'IA
Du point de vue de l'analyse automatique des données, le schéma WEB-proxy présenté répète structurellement une technique plus ancienne de masquage du trafic sous un HTTPS légitime – le « domain fronting », qui s'est répandu au milieu des années 2010 et est décrit comme une méthode de dissimulation du véritable destinataire d'une connexion via une non-coïncidence entre le SNI et l'en-tête HTTP Host. Les grands fournisseurs de CDN ont progressivement limité cette possibilité au niveau de l'infrastructure, forçant les développeurs à chercher des voies alternatives de masquage – dans le cas de Telegram, cette voie est devenue l'utilisation d'une page passerelle paramétrée à l'intérieur du WebView. La situation démontre la cyclicité de la lutte entre la censure et les technologies de contournement : chaque solution technique fonctionne jusqu'à ce que les systèmes de filtrage s'adaptent au nouveau modèle de trafic. Le WEB-proxy restera-t-il résistant à l'analyse des caractéristiques temporelles des paquets et du volume de session, ou les développeurs devront-ils à nouveau chercher un nouveau niveau de masquage ?
end-content
