Encryption for STUN / TURN exchanges

[Raoul Duke]

Hi list,

I'm trying to establish what mechanisms are available for encrypting of TURN / STUN exchanges.  I have found it somewhat unclear from the resources I have found to date particularly wrt. UDP support so I thought it would be informative in my case (and for future readers) to ask my questions to the list.

In the webrtc codebase (peerconnection.cc) I can see that stun/turn servers can be supplied with the protocol scheme of "stuns" and "turns" which the comments say "Indicates a [STUN | TURN] server used with a TLS session". 

my question is: are both TCP and UDP supported here?

in the case of STUN / UDP I know there is a specification for STUN over DTLS:
https://tools.ietf.org/html/draft-ietf-tram-stun-dtls

However, it isn't clear if this is implemented in webrtc and I found this issue which suggests it isn't:
https://code.google.com/p/webrtc/issues/detail?id=3644

Can anyone clarify this?

Note: I'm using the native webrtc library (in java code) so in my case I am not constrained by what particular browsers support.

I have the same question in relation to TURN,  i.e. assuming I disabled STUN entirely such that p2p was not an option and I was only using a TURN relay then how can I ensure that the turn authentication credentials and other user-specific information is encrypted?

i.e. would a UDP flavour of "turns" require the same "STUN over DTLS" capability as discussed above?

If the DTLS approach is not yet supported then am I restricted to using TCP for STUN/TURN if I want encryption?

If so what are the downsides of using TCP over UDP in this case?  i.e I'm somewhat unclear about why I would prefer one over the other in the case of NAT traversal.

I'd be very grateful for any feedback / pointers.

Thanks.
RD

[Warren McDonald]

@juberti The TURN DTLS in Chrome seems to have fallen into a hole somewhere. I just searched both crbugs and webrtc bugs and cannot find an outstanding or complete issue for it. The issue above is for the standalone implementation. I will raise a new bug with the problem. I have just retested 46 and 48 and they both exhibit the same behaviour. Specifying turns protocol with transport=udp does not raise an error or fail, it just uses a TCP TLS connection to the TURN server on the same port (if the server and networking is configured to accept it). 

New issue is https://code.google.com/p/chromium/issues/detail?id=545781 

Warren       

[Christoffer Jansson]

Thanks for filing the issue!

[Justin Uberti]

As you point out, DTLS and thereby use of UDP will give better performance. Note though that this will add 2 RTT to TURN candidate gathering.

What are you trying to protect, specifically? The TURN password is already protected by hashing.

WebRTC supports client-server DTLS connections already, and there is an old CL out that tried to add this logic to TURN (https://webrtc-codereview.appspot.com/21179004/), but it hit some snags and the work was never completed.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/54f685e3-45d2-4fe2-85ba-3d197d788617%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Warren McDonald]

Hi Justin,

we are not trying to protect static password values, which as you say are hashed. We are trying to avoid sniffing of the exchange and using this to a construct a replay to achieve an unauthorized connection. The TURN server is one of several layers of security and we are trying to improve this one aspect. Of course we can achieve this via TCP TLS but only with the latency overhead.

[Justin Uberti]

The TURN nonce protects against replay.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/36340a12-e539-4702-abae-f5b6fb834c73%40googlegroups.com.