Telegram Desktop a reçu une toute nouvelle méthode de contournement des blocages, qui déguise le trafic du messager en une simple navigation sur des sites web via une connexion sécurisée. Présentée le 21 août 2026, la technologie expérimentale du proxy WEB transmet les données du MTProxy via le transport WebView basé sur HTTPS ou WebSocket, rendant le flux indiscernable d'un surf web légitime et ouvrant de nouvelles perspectives d'accès au service dans des conditions de restrictions.
Comment fonctionne le tunnel invisible
L'essence de l'innovation réside dans l'utilisation d'un flux multiplexé, acheminé via le moteur de navigation intégré à l'application. Le client conserve le chiffrement et le cadrage 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 nombreuses connexions logiques de Telegram en un seul canal sécurisé, apparaissant extérieurement comme le chargement standard d'une page web.
Du côté serveur, un relais fonctionne, recevant ce flux unique et le divisant soigneusement en connexions distinctes 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 coursier aveugle. La charge utile reste opaque à toutes les étapes après la transformation initiale par l'application, garantissant la confidentialité même lors du passage par des nœuds supplémentaires.
La double vie du nom de domaine
Le proxy WEB fonctionne sur un domaine HTTPS ordinaire, qui continue de servir un site web public à part entière. La page pont 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, offrant ainsi une couverture fiable contre les systèmes de détection automatique.
Le choix du mode de transmission des données est strictement fixé 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 dans le cadre d'une session de transport unique, liée au domaine d'origine. Une telle architecture permet d'utiliser l'infrastructure d'hébergements ordinaires et de réseaux de diffusion de contenu (CDN) sans attirer l'attention sur l'activité proxy.
Détails techniques de mise en œuvre
La documentation complète sur le déploiement et le protocole est publiée dans le dépôt 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 possibilité 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 donne accès à la page spéciale ; les autres demandes sont traitées comme des visites ordinaires.
Le lien de connexion est de 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 fixes pour la spécification du type de proxy WEB. Le protocole décrit assure un typage strict des requêtes et empêche l'activation accidentelle du pont.
État actuel du projet
Le développement en est au stade de validation de concept et comprend une implémentation pour bureau, un client Android expérimental et des plans pour la prise en charge d'iOS. Toutes les plateformes utilisent une page intermédiaire, un format de trames et des composants serveur identiques, facilitant 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 proxy WEB marque une transition vers des méthodes d'intégration avec l'infrastructure web légitime plus sophistiquées. L'utilisation de mécanismes de navigation standard et de protocoles sécurisés complique la tâche des systèmes de filtrage, obligés de 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.
Opinion de l'IA
D'un point de vue de l'analyse automatisée des données, le schéma du proxy WEB présenté reproduit structurellement une technique antérieure de dissimulation de trafic en HTTPS légitime : le « domain fronting », qui s'était répandu dès le milieu des années 2010 et est décrit comme une méthode masquant le véritable destinataire d'une connexion via la non-concordance du SNI et de l'en-tête HTTP Host. Les principaux fournisseurs de CDN ont progressivement limité cette possibilité au niveau de leur infrastructure, obligeant les développeurs à chercher des voies alternatives de dissimulation — dans le cas de Telegram, cela s'est traduit par l'utilisation d'une page de pont 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 est efficace jusqu'à ce que les systèmes de filtrage s'adaptent au nouveau modèle de trafic. Le proxy WEB restera-t-il résistant à l'analyse des caractéristiques temporelles des paquets et du volume de session, ou les développeurs devront-ils une fois de plus trouver un nouveau niveau de dissimulation ?
end-content
