Si vous traînez sur des réseaux ultra-verrouillés (grandes entreprises, réseaux publics filtrés ou pays un peu trop portés sur la censure), vous savez que les suspects habituels — ports 22 (SSH) ou protocoles VPN standards (OpenVPN, WireGuard) — sont souvent les premiers à se faire « drop » ou « throttle » par les pare-feu de nouvelle génération (NGFW).
C’est là qu’intervient smtp-tunnel-proxy. Au lieu d’essayer de forcer le passage, cet outil pratique l’art du camouflage protocolaire en utilisant le port 587 (SMTP Submission).
Le concept : La « Stéganographie Protocolaire »
Le principe est simple : si un pare-feu fait de l’inspection profonde de paquets (DPI), il ne se contente pas de regarder le port, il analyse la signature du trafic. smtp-tunnel-proxy ne se contente pas d’encapsuler des données, il imite parfaitement le comportement d’un serveur mail légitime pour tromper les sondes.
1. Le Handshake : Respecter la RFC à la lettre
Tout commence par une discussion en clair, totalement conforme à la RFC 5321. Le tunnel envoie une bannière de bienvenue (type Postfix) et répond aux commandes EHLO. Pour n’importe quel système de surveillance, c’est juste une session mail qui démarre.
2. Le pivot STARTTLS : Le « Blackout » pour le DPI
Le point critique, c’est l’upgrade via STARTTLS. C’est une extension standard (RFC 3207) qui permet de passer d’une connexion en clair à une connexion chiffrée. Une fois le tunnel TLS établi, le pare-feu perd la visibilité sur ce qui circule.
Pourquoi c’est malin ? Sur le port 443 (HTTPS), un trafic chiffré qui dure des heures et consomme beaucoup de bande passante peut paraître suspect. Sur le port 587, un flux TLS est la norme absolue pour l’envoi de pièces jointes volumineuses.
3. L’authentification par HMAC
Pour éviter que n’importe qui n’utilise votre serveur comme relais, le projet utilise un mécanisme d’authentification robuste. Au lieu d’un mot de passe statique, le client génère un HMAC-SHA256 basé sur un secret partagé et un timestamp :
Le serveur vérifie la validité du timestamp (fenêtre de 5 minutes) pour empêcher les attaques par rejeu.
Pourquoi c’est vraiment utile ?
-
Contournement du filtrage sélectif : Dans beaucoup de réseaux, on part du principe que « le mail doit passer ». Bloquer le port 587 casserait la productivité de n’importe quelle boîte.
-
Multiplexage des flux : L’outil gère plusieurs connexions TCP à l’intérieur d’un seul tunnel SMTP. Vous pouvez faire passer votre navigateur, votre SSH et votre messagerie instantanée en même temps sans ouvrir 50 sessions.
-
Faible empreinte : Le binaire est léger et ne nécessite pas de dépendances lourdes (souvent écrit en Python ou Go selon les versions, ici du Python asynchrone pour la performance).
En pratique, ça donne quoi ?
Côté client, l’outil monte un proxy SOCKS5 local (généralement sur le port 1080). Une fois votre navigateur configuré pour utiliser ce proxy, tout votre trafic est encapsulé, transformé en « morceaux de mails » chiffrés, et envoyé au serveur distant qui déballe tout ça pour vous.
smtp-tunnel-proxy n’est pas l’outil le plus rapide du monde (le protocole SMTP ajoute un certain overhead), mais c’est l’un des plus résilients. Si vous avez besoin d’une « issue de secours » quand tout le reste est bloqué, c’est une option sérieuse à avoir dans sa boîte à outils.
Le projet sur GitHub : x011/smtp-tunnel-proxy
