Nextcloud version : 27.0.2 (deployed via helm chart)
Talks version : 17.1.0
Hello Nextcloud team !
I just sat up a coturn server to work with Talks and it worked like a charm until I tried to enable the “turns only” option.
I’have a working coturn server and my tests with turnutils_uclient are successful (even with the -S option).
Everything seems fine but whenever I enable the “turns only” mode and I click the test icon, I get the red icon and my users can’t use webrtc anymore.
I can’t find any valuable information in the log file, the only logs I have when i grep spread are stating that : Creation of dynamic property OCA\\Maps\\Hooks\\FileHooks::$lockingProvider is deprecated at /var/www/html/custom_apps/maps/lib/Hooks/FileHooks.php#46 but it doesn’t seems related.
I read that there was some problems with letsencrypt certificates and the chromium webrtc libraries but my problem is the same if I run the check on chromium or firefox.
I don’t have any ideas where to search to debug this, so any help on this subject would be very appreciated.
Is there any particular reason you’re forcing turns only? It will not give you any additionally benefit, since the WebRTC part is already encrypted anyway.
If I understand correctly, the turn packets can leak the peer IP address.
This is not a realy serious nor a blocking issue, but as the option is availible and it doesn’t seems to work, I thought that I would try to understant why, but I can’t find a way to understand the problem.
The secret is not sent over the wire. It’s used to compute a one-way hash which is sent in its place. You don’t need an encrypted connection to protect the secret as it can’t be recreated from the hash.
Furthermore, the browsers use end-to-end encryption for the voice and video channels, so those are encrypted regardless of whether a TURN server is used or not.
Adding encryption at the TURN layer double encrypts the traffic, which isn’t generally necessary and usually just adds overhead.
The primary benefit to using TLS or DTLS for the TURN connection is to allow traversing firewalls that otherwise try to block WebRTC traffic. Many firewalls block all UDP traffic, for those you fall-back to using TCP. Others block all traffic except on a few well-known ports, for those you shift the TURN server to a well-known and allowed port, like 443[*]. Some advanced firewalls perform deep-packet-inspection to try to determine what kind data the traffic really is, regardless of the port. For those, you wrap the WebRTC traffic inside an encrypted tunnel, e.g. TLS or DTLS. A TLS connection on port 443 is basically indistinguishable from https: traffic (except by doing traffic analysis and taking an educated guess) so gets through most firewalls and web proxies.
You can use Nextcloud Talk as it is today without worrying about your TURN server being compromised or your conversations listened to. This feature is used to make connections when operating on hostile networks that will otherwise block your connections completely, e.g. coffee shop WiFi, hotels, locked-down enterprise networks, etc.
[*] Sharing port 443 with a web server on the same IP address can be done, but is not easy, using TLS can help there too.
Also i found this comment that explains that it does not work with Firefox and Chrome. Do you use turns: in other applications? Do they work with Firefox or Chrome?
Is your coturn running on the same server as Nextcloud?
Is TLS configured properly in the turnserver.conf file, and does coturn actually load and use the certificates?
Did you look at the coturn logs? You may have to set the logs to “verbose” temporarily in order to get useful information
On what ports is it running? As @devnull stated, using “TurnS only” does only make when it’s listening on port 443, in order to bypass firewall restrictions. But this only works properly if the TURN server is running on a dedicated server / dedicated public IP on which no other services are already listening on port 443.
I have set it up on Debian 11 on a VPS, using Carsten Rieger’s guide and it does work with “TurnS only” on port 443.
Both Firefox and Chromium ignore the UDP transport and force TCP when used with a turns: scheme. That is, DTLS is not supported in any of them, and turns:address:port?transport=udp is silently converted to TLS. Therefore, if both turns:address:port?transport=udp and turns:address:port?transport=tcp are specified in the ICE servers in practice they end being a duplicated turns:address:port?transport=tcp.
This clearly explains why my setup doesn’t work as I ony listen on UDP.
I think the ui is a bit missleading as you can state “udp only” and “turns only” but It can’t work (because browsers don’t support DTLS), maybe a little warning that states somthing like “with turns, udp is not supported by browsers” would be useful.
Again, thanks a lot for taking the time to answer me !