mycrl
Supports Transport Layer Encryption
This issue is for documenting the progress of adding transport layer encryption to turn-rs, and related issues.
TLS
Implementing tls inside rust is a very simple thing to do, and there is a very mature ecosystem to take advantage of.
DTLS
Implementing dtls is a bit more complicated, and if I can't find a mature library inside crates.io, I have no choice but to implement it myself from scratch.
The benefits of supporting transport layer encryption are so small and minimal that it's forced me to rethink the need to include transport layer encryption at this time.
None of the major current clients actually support transport layer encryption unless tested with coturn's test suite.
Adding transport layer encryption would bring a lot of extra work, but no significant benefit, so I'm putting this feature on hold for now, to be added in a subsequent release.
@mycrl I don't think adding DTLS is worth it, to be honest. In practice, DTLS is only used as a fallback, which probably accounts for 1-5% of cases. Since TLS is necessary as a last resort (looking at you enterprise network restriction), the DTLS use case can be covered with TLS instead.
Especially with the DTLS 1.2's lack of support from Rustls, we can drop DTLS altogether and support only TLS.
This is the approach taken by Cloudflare, https://developers.cloudflare.com/calls/turn/, and some other vendors I'm aware of.
@lherman-cs In fact, I don't think there's much need to add transport layer encryption to this whole topic, and my main point in keeping this topic is as a “dessert” that can be supported or not, but it's a low priority.
The reason I mentioned above is that transport layer encryption is seldom used in actual business. In my impression, turn servers are basically only used by webrtc (I don't deny that there are other things that use turn), and for webrtc, the traffic is already encrypted, and for non-webrtc scenarios, it's rare for someone to put unencrypted traffic directly on the transport layer of the turn. It's precisely because this is a feature that serves little purpose but is laborious to implement that it's causing me to put it on hold for now, and if a third-party ecosystem exists in rust's ecosystem down the road that would make it simple for me to add this functionality then I'll be adding it in. But for now, I'll probably try to implement it when I have nothing else to do.
@mycrl In my last comment, I only referred to the WebRTC use case. I agree that it's completely wasteful to reencrypt the media and data streams with TURN TLS. But, unfortunately, TLS is needed for some networks. In my experience, VPN and enterprise networks are the main culprits. These networks tend to put deep packet inspection on the clients/routers to filter out packets that are not TLS (basically only HTTPS traffic).
I believe the lack of UDP or DTLS adoption in these networks is one of the blockers for adopting HTTP/3 too. I'm hopeful to see DTLS (not TURN DTLS, but the underlying transport DTLS) will be eventually supported in these networks as HTTP/3 gains more traction. But, as of now, we need to be compatible with TLS.
Only supports tls, not dtls, and will consider supporting quic directly in the future
#138