logoalt Hacker News

Show HN: SMTP Tunnel – A SOCKS5 proxy disguised as email traffic to bypass DPI

120 pointsby lobito25yesterday at 12:30 AM40 commentsview on HN

A fast SOCKS5 proxy that tunnels your traffic through what looks like normal SMTP email, bypassing Deep Packet Inspection firewalls.

How it works: - Client runs a local SOCKS5 proxy (127.0.0.1:1080) - Traffic is sent to server disguised as SMTP (EHLO, STARTTLS, AUTH) - DPI sees legitimate email session, not a VPN/proxy

Features: - One-liner install on any Linux VPS - Multi-user with per-user secrets and IP whitelists - Auto-generated client packages (just double-click to run) - Auto-reconnect on connection loss - Works with any app that supports SOCKS5

Tech: Python/asyncio, TLS 1.2+, HMAC-SHA256 auth

GitHub: https://github.com/x011/smtp-tunnel-proxy


Comments

bmenrighyesterday at 12:09 PM

Large volumes of SMTP-like traffic are a huge red flag. Competent companies an ISPs should already be looking for large volumes of outbound mail to identify abuse / spam bots / data exfiltration.

If I came across this in netflow data I'd first assume outbound spam. But a hallmark of sending mail is that the client to server byte ratio is extremely skewed towards client -> server bytes, whereas running a VPN-like service is usually more balanced but still skewed towards server -> client bytes. I'd see the large server -> client byte count and immediately know something strange was going on.

That said, very little code here is involved in looking like SMTP. The SMTP obfuscation basically boils down to a few lines of plaintext between the client and server before a STARTTLS and then everything after that has nothing to do with SMTP. You could swap out the fake stub conversation quite easily to look like many other protocols. Whether the in to out bytes ratio makes sense for those protocols is another matter.

These days, I think the best thing to disguise as is HTTPS. There is so much variety in HTTPS traffic and such a huge volume of it, that spotting hidden tunnels is very hard.

show 1 reply
m132yesterday at 4:59 AM

That's an interesting protocol choice, especially given the purpose. SMTP is probably the most filtered protocol on residential networks, SMB being a runner-up.

show 3 replies
ralferooyesterday at 1:17 PM

This seems daft to me as it would be trivial to identify on a network. Real SMTP will have significant data flow in one direction towards the destination, will close the connection fairly quickly once it's transferred (so no pauses) and has very little traffic being returned. It's hard to think of a worst protocol to try to hide a proxy in.

dfajgljsldkjagyesterday at 4:42 PM

So many comments explaining this is a bad idea while OP just asked claude code to write this and probably doesn't even know the difference between TCP and IP.

thedougdyesterday at 3:58 AM

Quite a few things use STARTTLS. I imagine the same technique could be applied to those other protocols, giving users some options as they fight hostile networks.

Clever

show 1 reply
ok123456yesterday at 2:48 PM

Back in the 90s, I ran telnet on the POP3 port so I could IRC in the lab during high school. The more things change, the more they stay the same.

Gathering6678yesterday at 6:39 AM

I suppose it would be trivial to simply block or severely throttle high-volume SMTP traffic?

show 1 reply
neilvyesterday at 8:07 AM

How does this get past firewalls that would block the alternative, of SOCKS5 traffic tunneled through port-443 HTTPS with keepalives?

(Even with complete HTTPS decryption in the firewall, the downstream traffic could look like, say, random CSV data file downloads or innocuous HTML text, and upstream traffic could look like innocuous requests (avoiding large lists of problematic keywords).)

mycallyesterday at 1:20 PM

It would be great if it also worked as SMTP server

Haaargioyesterday at 12:13 PM

Get yourself an IP with Port 443 free and just use that.

SMTP is blocked by a lot of firewalls by default. All cloud providers do that and you need to request opening them up.

usAyayoyesterday at 11:34 AM

[dead]

YouAreWRONGtooyesterday at 8:22 AM

[dead]