Hacker News new | ask | show | jobs
by stefanha 145 days ago
Link to the protocol specification: https://github.com/TrustTunnel/TrustTunnel/blob/master/PROTO...

It's a thin HTTP/2 and HTTP/3 tunneling protocol for TCP, UDP, and ICMP traffic.

It should be easy to write an independent implementation based on this specification provided you already have an HTTP/2 or HTTP/3 library. Pretty neat!

3 comments

Looks very similar to the HBONE protocol the istio folks created for ambient mesh: https://istio.io/latest/docs/ambient/architecture/hbone/
just did some spec reading, it's quite clear and nit.

I can understand that put UDP payload into a single HTTP stream, at least when QUIC transport is in use, there is no UDP in TCP case.

The Source Address/Port in the UDP payload message serve as key to handle to the tunnel client if I understand correctly?

Basically a CONNECT proxy? That's definitely not a difficult thing to write.
More or less, built on top of it with added udp/icmp.

When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.

QUIC CONNECT supports UDP too now.
We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.

And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.

We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.

Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.
Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.
> QUIC is not bad, but there are places where it either does not work at all or works too slow.

Curious: in your experience where does QUIC work bad/slow?

For example, in some countries it's either slowed down or outright blocked.