11–20 of 56 posts
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.
Earlier quoted context omitted.
What would you reach for out of curiosity? For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.
I think HTTP web sockets would be an interesting tunneling protocol.
https://blog.torproject.org/introducing-webtunnel-evading-ce...
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.
What would you reach for out of curiosity? For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.
RTP isn't a bad choice, especially the WebRTC flavor of it:
- it's UDP; there's no need to worry avoid the TCP meltdown
- it's most commonly used for peer-to-peer and PBX communication; packets going in and out, from and to random IPs are expected
- high bandwidth RTP traffic is normal, so are high irregularities
- it most often carries video; huge room for steganography
- WebRTC makes encryption mandatory
I've come across corporate networks that do block non-intranet WebRTC, however this probably isn't feasible at the Internet scale.
Other good choices are QUIC and WebSockets (assuming your network doesn't do MitM), and SSH, which by default comes with strong protection against MitM and actually has SOCKS5 tunneling built into the most popular implementations (try `ssh -D`). SSH is what some of my friends successfully use to bypass the Great Firewall.
That being said, the shift of client-to-server SMTP from a common part of everyday internet traffic to something rather esoteric may have created some potential for firewall misconfigurations, and those might result in it being passed with minimal inspection. All depends on your particular firewall in the end.
Earlier quoted context omitted.
TECHNICAL.md lays it out a bit more, but it claims to be RFC 5321 compliant with a realistic initiation sequence so it should somewhat look like a real SMTP server for the first bit. Ending up on any DNSBLs shouldn't be a problem unless you have a static home IP you plan on running an actual SMTP server from after this though.
>SMTP traffic on port 587 (submission) is expected and normal Any residential dynamic or static IP with this port opened is definitely going to get flagged. Most ISPs already prevent these ports from being open, either by policy or by residential routers. It would probably very quickly end up on something like SpamHaus's PBL, which looks for this kind of thing.[1] I would imagine you would also find yourself on Shoda…
Any time you have any externally open TCP port (home or VPS) you should expect to get scanned to shit by Shodan and millions of other bots. It doesn't matter if it's the default port for SFTP, DNS, SMTP, HTTP, Minecraft, or whatever - all of them are great targets for malicious actors and as soon as the bots detect one open port they'll scan everything on that IP harder. I once forgot to disable certain default enabled login types and failed connection/authentication logging when exposing SSH/SFTP externally and ended up with GBs of logs in just one week.
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.
What would you reach for out of curiosity? For me RTP+rateless erasure codes come to mind, but I’m feeling Rube Goldbergy today.
I suppose it would be trivial to simply block or severely throttle high-volume SMTP traffic?
Earlier quoted context omitted.
Just curious - how much of this was AI generated? The readme has crazy emojis & the code was all checked in at once, which is usually my telltale for these kinds of things. Didn't see anything crazy in the source files. I think its polite to indicate AI agent usage in security related projects like this since they can have huge holes if they're just being vibe coded. -- Edit: Intended to post this on the board root,…
It's a fair question but I had a bit of a chuckle at the idea having a shit ton of emojis in your GitHub readme was the first flag it might be AI. Mostly because I always assumed the opposite - that GitHub readmes were a big part of the emoji ridden listicle training data (the other being slop "news" site/social media listicles) for AIs in the first place. After all, they are decently well written and come with grabb…
(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).)