Support for UDP/DTLS/QUIC ? - Githubissues

yrutschle / sslh

Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)

https://www.rutschle.net/tech/sslh/README.html

GNU General Public License v2.0

4.56k stars 368 forks source link

Support for UDP/DTLS/QUIC ? #279

Closed utoni closed 3 years ago

utoni commented 4 years ago

What do you think about UDP support? As QUIC is evolving further and further it might be interesting for sslh users. My current scenario requires to distinguish between DTLS, QUIC and a proprietary protocol (client initiated; stable pattern in the first packet available).

What do you think about it?

yrutschle commented 4 years ago

This is an interesting use case. I never looked into it, but intuitively I would have expected corporate firewalls to not let UDP out on 443... Then again, I suppose if Google is pushing it, that channel might open little by litte :-)

My first thoughts:

Handling UDP would require sslh to keep track of connection states, essentially doing the work of a NAT server.
UDP being message-oriented, it would be simpler than the current logic (i.e. we can simply receive and send right away, we don't even need to handle message loss) So we gain on one side and lose on the other side. What's not clear to me is how much of TCP-sslh is relevant to UDP-sslh. As usual, I can't commit to a deadline, but I'll definitely keep this idea in mind :-)

yrutschle commented 3 years ago

Release info here: https://lists.rutschle.net/mailman/archives/sslh/2020-December/000738.html

I'm particularly interested by DTLS and QUIC probes :-) On my side, I'll still work on the UDP integration for a while, it still needs work.

utoni commented 3 years ago

You can take a look into the test pcaps from nDPI.

Checkout the subfolder tests/pcap/(dtls|quic*).pcap, this may be interesting for you.

utoni commented 3 years ago

Thank you very much for your hard work. <3 UDP support just works fine w/o any issues.

I'm looking forward for a official release, so package maintainers can also profit from your effort. ;)

yrutschle commented 3 years ago

FYI, UDP integration is coming (slowly), I should have a "crappy working" version (which will work with a hard limit of connections and probably fairly heavy CPU usage) soon-ish, and a production version coming after that.

If you have working probes DTLS and/or QUICK, would you mind posting them so I can add them as example, and maybe make hardcoded probes (which will probably work orders of magnitude faster than a regex probe).

utoni commented 3 years ago

I recommend nDPI pcaps used for diff tests e.g.: dtls pcap yet another dtls pcap gQUIC QUIC and many more

utoni commented 3 years ago

I can also record some additional pcaps if required. Or I can just C&P the regex I've used. Not sure if this will help you.

yrutschle commented 3 years ago

UDP is now "acceptably working", there is no longer a limit on the number of connections. I think I'll freeze there and make release to get it out, before improving further.

Yes, I'll be interested in your regexes to include as examples, unless they are too tied to your setup (I know little about QUICK). I I am not really in a place where I have the time or the setup to test QUIC myself, so...

utoni commented 3 years ago

For my test setup I'm currently using:

# Teamspeak3
{ name: "regex"; host: "teamspeak.test.lan"; is_udp: true; port: "9987"; regex_patterns: [ "TS3INIT1" ]; },
# IETF QUIC-50
# Remember that the regex needs to be adjusted for every supported QUIC version.
{ name: "regex"; host: "quic50.test.lan"; is_udp: true; port: "4433"; regex_patterns: [ "\x51\x30\x35\x30" ]; },

Not tested, but also required:

{ name: "openvpn"; host: "openvpn.test.lan"; is_udp: true; port: "1134"; },