Spreed: TURN-TLS support

[rugk]

It seems you only support UDP and TCP. However there is another transport mechanism called TURN-TLS, which wraps the whole thing into another TLS layer. This should be the last fallback for ugly company firewalls or so, which do deep package inspection and block non-HTTPS traffic on port 443.

[jancborchardt]

@nextcloud/spreed what do you think?

[Pazu]

Firefox appears to have added support for this in v53.

[nickvergessen]

@fancycode any idea what would need to be done on our end?
CoTurn seems to support it:

TLS (per RFC 5766 and RFC 6062): TLS1.0/TLS1.1/TLS1.2; ECDHE is supported.

[fancycode]

It should be enough to also return turns: urls here:
https://github.com/nextcloud/spreed/blob/d69d88bcd42e5953d4a82eb78ba26a912d96f507/lib/Config.php#L69

Needs some testing though.

[MichaIng]

@fancycode @nickvergessen
I just faced the TURNS TLS question as well. Many guides state to enable TLS support in coTURN settings (my own HowTo as well), but actually coTURN allows to access plain on "tls-listening-port" as well (and the other way round), so it's up to the client to request via turn:// or turns:// and the coTURN settings do not matter at all, besides TLS cert required of course.

So if spreed/talk accesses via turn:// only, then setting up TLS in coTURN has absolutely no effect (for Nextcloud Talk). So I need to update my HowTo 🙈: https://help.nextcloud.com/t/howto-setup-nextcloud-talk-with-turn-server/30794

TURN is such an essential part of getting Nextcloud Talk working throughout NAT and that it is never accessed via TLS (TURNS) is important to know to not give users a wrong impression about the connection type. So I think it would be beneficial to have these infos (e.g. based on the HowTo) to a more prominent/official place. What do you think?

And of course if applying TURNS is really that easy, it would be perfect to have a toggle within Talk app settings.

---

Side note: https://github.com/coturn/coturn/issues/33

• Security benefit of TURNS is very limited (WebRTC encrypted anyway).
• But it allows passing firewalls that allow transport layer encrypted requests only.

[joe-average-user]

@fancycode @nickvergessen:
Really if patching the "turn" in the spreed app to "turns" is enough for enabling tls for turn, then I cannot imagine a single reason why you don't let the user/admin enter the protocol in the config page. I mean someone being able to config a turn-server should be able to name the protocol, not?
So simply, redo the code:
if no protocol given, add "turn", else use given protocol. compatible and simple.

[nickvergessen]

Feel free to send in a PR.
But also make sure you read https://github.com/aszlig/avonc/commit/09743c237c480addff7f0aaf235180ade1fdeb6e before.

[joe-average-user]

Honestly, the mentioned comment is really not intelligent in its logic. The author admits that there _are_ in fact cases where you need TLS encrypted turn traffic. But he comes to the conclusion: "don't bother if you don't have to." well, what else? We all are only bothered by problems if we have to solve them. Ok, some of us do it all for fun, as stated in the book ...

[MichaIng]

then I cannot imagine a single reason why you don't let the user/admin enter the protocol in the config page

Simplicity would be a reason. And that TURNS does not add a security benefit but the overhead of doubled encryption only, which as well might introduce other issues or reports about bad performance, high CPU usage, incompatibility with certain WebRTC clients and such. Some users tend to add high security options where possible, but in this case it probably introduces issues only. What is your reason for aiming it?

For the rare mentioned cases where it might be "required" (meaning it does not work with plain TURN but only TURNS), if the firewall does not allow any on signalling level unencrypted connections, regardless of port, it might be reasonable to wait for/collect these cases first, before opening a possibly problematic option that might require docs rework and a differentiation when it comes to hardware recommendations/requirements for multi-peer scenarios.

But yeah, generally I would support the option, at least to allow testing it, it's performance impact and such, which allows then to give a clear hint in the docs.

[joe-average-user]

How about this untested patch then:

(Explanation: we assume a syntax like "stun://stunserver.domain:port" or "turn://turnserver.domain:port" or of course "turns://turnserver.domain:port" because the signaling server is spelled in the same way. But obviously "://" is not needed in the urls, so we use ":" compatible to original syntax. I have no idea if the correct spelling can contain "://")

patch.txt

[joe-average-user]

@MichaIng
This is the reason why my patch looks like it does:

• no change in running configs needed, compatible to current docs
• additional possibilities to configure something with a syntax that is similar to signal server, so in fact it is a "streamlining" of config options that had differing syntax before (for no obvious reasons)

[MichaIng]

LGTM. Would be nice if you could open a PR with this patch, to get some more attention and allow testing and discussion about the implementation.

Generally I am not sure if it is best to allow setting the protocol freely, or add a selection menu instead, like it is the case for UDP/TCP selection. It depends a bid about how the clients handle it, if they usually throw meaningful error messages, if Nextcloud otherwise should check syntax and such. I am as well not sure about turn:domain.org vs turn://domain.org, which one is common and which one "only" works. Would be good to either allow the common scheme or both or work around it via selection menu and plain domain in text field.

[joe-average-user]

Honestly, I am no fan of the selection list, not even the UDP/TCP list. janus, to name an example, knows udp,tcp,tls on the same config options.
And remember that there may well be a path component that the user can mess up freely - I know, because I did myself in the signaling server config. You cannot make such a config option fool-proof, where it is simply necessary for the admin to know and understand what he is doing.

Regarding PR:
The patch is dead simple. I hoped that someone just takes it for inclusion - as long as it really works (remember "untested"). I don't even use git ;-)

[MichaIng]

janus, to name an example, knows udp,tcp,tls on the same config options.

Hmm, actually it's TCP <> TLS and UDP <> DTLS, which coTURN supports, so TCP and UDP each with their encrypted counterpart, having TLS as only 3rd option breaks TCP vs UDP selection and basically it makes sense to allow both concurrently as well.

You cannot make such a config option fool-proof, where it is simply necessary for the admin to know and understand what he is doing.

Yes that must be evaluated by the spreed devs basically. As long as the docs are clear, that is all fine to me.

I don't even use git ;-)

But you have a GitHub account so you can just edit the file via web UI, which creates a fork and branch automatically (don't forget the sign-off) and offers you to send the commit as PR automatically. The best way to push ideas which did not get enough developer attention otherwise 😃. Probably I find time this weekend to test it in general. The exact implementation (selection or free text field or something different) can be discussed when it basically works fine.

[joe-average-user]

It must be mentioned that coturn is in fact saving nextclouds' a** in this topic. Since there is no possibility currently to change nextcloud to use turns or stuns it is handy that coturn makes no difference on _every_ port if it the user is using "s"-variants or not. If you follow the good practice to protect the TLS port(s) of coturn with nginx (or httpd) you will fail miserably with nextcloud as both cannot forward TLS and non-TLS connections on the same port.
Another good reason for the my patch...

[MichaIng]

If you follow the good practice to protect the TLS port(s) of coturn with nginx (or httpd)

Why is this good practice? From all that was discussed about that topic it is just an overhead without security benefit.

Ah sorry probably I misunderstood, do you mean enabling TLS via webserver proxy?

[joe-average-user]

Yes, of course you can do both ways, "tls-through" and "tls-endpoint" config is possible with the webservers. "tls-endpoint" (webserver terminating the tls session and giving the data in a non-tls connection to turn) is probably safer.

[MichaIng]

However, as you say it's "good practice", it sounds like you say that encrypted TURN requests add any security benefit. But as long as all discussion about that state that it does not, generally I would say that encrypting it only adds unnecessary overhead, hence is bad practice and should only be used if it is really impossible to use TURN otherwise. And this was my earlier argument against adding the feature without making clear statements and recommendations about that point. So I am still wondering why you want to encrypt your TURN requests instead of simply making the plain TLS and/or UDP TURN ports accessible directly.

But at least implementing the ability to test TURNS is still a good thing IMO, so don't understand me wrong in this point 😉.

[rugk]

AFAIK the reason for TURN-TLS is just to circumvent crazy (ccoperate) firewalls that do DPI (deep package inspection) or so and thus would block the "usual" protocol.

[BloodyIron]

Reading through this thread. Original start, March 2017, and last post Jun 13 2020.

Clearly there's ways to add this functionality without breaking in-place configurations, or other such things.

There are those of us that want TLS for TURN and related traffic. Let us decide if the performance impact is acceptable or not, do not make that decision for us. There are those of us where security is paramount, and we do not want to give any inch on any sort of DPI, or other forms of inspection.

So, what's it going to be, are we going to bicker about this for another 3 years, or is this going to get implemented already?

I'm genuinely disappointed to discover this has yet to be implemented. At the bare minimum as an option. nextCloud is touted as a secure platform, with aspects of GDPR and HIPAA compliance. Why even give up yet another angle it can be more secure?

Just please put it in already. I for one want to use it immediately.

[MichaIng]

Please read through this and linked issues again and you'll see that there is no security benefit. I just had a conversation with another TURN server coder which just verified that TURNS/TLS is used to pass through strict firewalls only, nothing else.

I know that some (including myself) "try" to increase security wherever they can, don't ask me about the encryption key sizes, ciphers etc I use, 100% ssllabs.com etc. But to derive priority for coders it is good to get clarification about what REALLY increases security and which step just gives you the illusion while implying downsides and takes your time away from much more important security aspects. Especially for Nextcloud devs it simply makes sense FOR security reasons to not waste time on illusions, decreasing user experience on the other end, while there are other REAL security aspects to enhance/work on.

If you want to waste your time in this (sorry for wording, no offence, I'm doing this myself), then apply the patch that was posted above already and simply try it out, pushing this topic forward, but do not blame Nextcloud coders for acting reasonable in this regards.

[nickvergessen]

I'm genuinely disappointed to discover this has yet to be implemented.

A patch was given above. Feel free to turn it into a Pull Request and send it in as an opt in solution.

[joe-average-user]

This is about the only project I know where you give it a working patch and it is not picked up, only because someone does not want to have such a simple "feature" (obviously political). So it is no wonder for me why other things that should have been done since months/years are not making steps forward, too. Amongst which is a useable moderator UI for managing sound on/off, declaring one stream as primary (big view) for _all_ participants, recording of the primary stream, just about everything one would call conference management...

[MichaIng]

I said before (and Nick now) that turning a request and/or patch into a PR is the best way to get attention, as its triggering CI builds/tests which checks general compatibility + making it easy to clone and test as well. I really appreciate that you published the patch already, however do not blame devs of an open source project to not follow a request where until now not a single user has proven to "require" it for the only purpose it serves (firewall). I don't know what you mean by "political" but from all qualified input I got I would call it "reasonable" or "rational".

Also throwing now a bunch of feature requests inside doesn't help. There are always more requests and wishes then developers time to pick up. One has to set priorities and when setting them too far into new feature direction, people blaming for now taking care about bug fix and fine tune existing features (I read such all the time), now we have it the other way round. Really, such statements are totally ignorant and ungrateful and unmotivating, especially when taking into account the large progress and many feature integration that has been made with Nextcloud Talk recently, at in opinion.

Please guys remember this is free and open source GPL software and what it means, see the very regular work that Nick and others put inside, respect the priorities of those who are actively investing time, otherwise invest your own time to bring things into a PR, else collect votes, but do not blame 🙏 ☮️.

[joe-average-user]

Strange to see you neglect to count me as the user who needed the patch. I did it exactly because I needed it. And we (meaning several people around me) use it since that day. Interesting how people interpret democracy according to their respective personal policy. I write software since the 80s last century. So please do not try to divert "user" from "dev" in the way you do. Because mostly today this only means "not paid" in comparison to "paid" for the project. This is not my project. Originally GPL was all about being able to contribute some lines of code with the idea that others may need it now or some time later. Which is why I doubt you are "offering" the true spirit of GPL in your words.

[MichaIng]

I did it exactly because I needed it.

Okay sorry then, I asked you for your reason somewhere above and misinterpreted the missing answer. If your patch is even tested then, why not open a PR? Of course I could grab in and do it (with your permission) but it makes much more sense if you do it yourself, adding your test results/experience, notes and ideas to it, having the correct snippet author in commit history etc. 🚀.

So please do not try to divert "user" from "dev" in the way you do. Because mostly today this only means "not paid" in comparison to "paid" for the project.

With "developers" I mean the ones who pick up others requests and which you address with your criticism to not pick up your(s), totally regardless if paid or spare time contributors, applying for this the same as for hobbyists projects, and regardless how ready the code for commit already is.

Interesting how people interpret democracy according to their respective personal policy.
...
Originally GPL was all about being able to contribute some lines of code with the idea that others may need it now or some time later. Which is why I doubt you are "offering" the true spirit of GPL in your words.

GPL is not democratic (probably the project-internal team is organised democratic partly), it gives you the right to do what you want but it does explicitly not give you the right to get what you want or even what most want, which is why I think your criticism is inappropriate and definitely contra-productive.

[joe-average-user]

Really, if I had to do all the steps for a project I ever contributed some lines I'd probably need to double my lifetime. Those are only few lines with absolutely nothing irritating or complicated in it. Whoever feels like it can take them and include them in the project. The irritating fact for me in the whole issue is that the discussion about this null-code is a lot longer and more time-consuming than the code itself.
The immanent strength of GPL is that everybody can code something in a project and if the maintainer is wise he will include everything that _works_. And the simple reason is that a GPL project is meant to survive its maintainers by far. That is the true nature of the thing. Whereas closed sources often die with its maintainers, GPL is able to live on. This means it is mostly not useful to try to stamp a project with only the maintainers' view of things. Be open-minded and try to accept things beyond your own horizon. Being able to contribute is the most democratic right one can have.

[MichaIng]

Really, if I had to do all the steps for a project I ever contributed some lines I'd probably need to double my lifetime.

But you blame others for now doing all this steps for you? Note that sending a PR for CI tests, review, documentation etc is common practice across Nextcloud projects for all code commits.

if the maintainer is wise he will include everything that works

Okay then we have fundamental different opinions on what is wise and how quality software should be developed.

The irritating fact for me in the whole issue is that the discussion about this null-code is a lot longer and more time-consuming than the code itself.

Yeah you're right, I'm just too discussion affine and bullhead by times, no need to discuss further, the GPL/meta topic I mean.

However the exact final TURNS implementation will, I guess, be still part of discussion, meaning free text entry vs selection, menu or checkbox, if/how fallbacks are handled and such, as its likely not "include everything that works".

Probably I'm able to run some tests during the weekend, as well to measure CPU/performance impact. Also not sure if I will directly take your code as is for my PR then, as I would do it differently in detail, and might take again some days as I have do dig into PHP code (I'm no PHP coder, and this is spare time/hobby work). So again fastest is if you do it and add your test results/experience from first hand.

[joe-average-user]

Uh, please don't name "qualitiy software" and nextcloud related in the same context.
There is a ton of stuff that was obviously not tested before its inclusion. If you need a prominent example: nextcloud talk app destroys the video if you turn your mobile to one side. It is really not possible to not see this in a single 1-minute-test.
I mean, sure nextcloud is mostly ok, but it is not what one would call "quality software".
And there must be some people in the project with the same opinion. Else we would have seen NC19 in the stable update repo, nevertheless it is distributed as standalone archive.
Listen, NC is quite ok and has taken big steps compared to OC. But there are issues, quite some of them if we believe in the github issue tracker...

[MichaIng]

... edited to not further drive this OOT conversation, lets keep this productive.

[tapete]

I wonder if the static-auth-secret is transferred in an encrypted way if turn is configured without tls. Does anyone know? Especially if the nextcloud talk server and coturn are not in the same network.

[MichaIng]

Good question, at least hashed, hopefully?

[fancycode]

Coturn describes how the shared secret is used:
https://github.com/coturn/coturn/wiki/turnserver#turn-rest-api

TLDR: it's used in a hmac to generate a temporary password for a temporary username. It's never transmitted.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[BloodyIron]

What? Re open! This is needed!

[plinss]

Agreed, please re-open.

My concern is not about security, I agree that TLS isn't necessary here from a security perspective. The primary problem is firewall traversal, which is why TURN gets used in the first place.

There are an increasing number of firewalls that restrict traffic on ports other than 80 and 443. There's also an increasing trend in firewalls to add deep packet inspection (there are even open-source solutions, I'm running one at home now), which makes TLS absolutely required to get through on port 443.

There's not a lot of point in adding a specific mechanism to let you penetrate firewalls, if it can't penetrate firewalls...

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[MichaIng]

I removed the "needs info" tag to satisfy no-response bot. It is clear in which (rare but existing) cases TLS-encrypted TURN support is required. Finally someone should simply open a PR as suggestion and GUI-related aspects (which was discussed above, protocol selection vs free input field) can be discussed in the PR based on actual tests, look&feel.

[plinss]

PR Submitted.

The change allows specifying turn: or turns: in the TURN server name (defaults to turn: if not specified). This works for both TURN-TLS and TURN-DTLS (on UDP connections).

It's based on @joe-average-user's patch above, but uses turns:turn.example.com rather than turns://turn.example.com (the latter is not a legal TURN URL per the relevant RFCs), was updated to match code refactoring in the config handling, and includes fixups for the CSP headers and the 'test' button in the UI.

Tested on a TURN server that only allows TURN-TLS on port 443.

[joe-average-user]

Great! thank you for supporting the issue.

[luminous706]

Hello, so can we encrypt turn communications in Nextcloud or not? What's the state on this issue?

1. I configured coturn, but it is now exposed to the internet. As I understand it, Nextcloud sends a secret to it unencrypted through the wire. Anybody able to capture this secret can hijack the turn server, if I understand correctly.

2. Then, what about the video and voice conversations in Talk, are those encrypted?

Can anybody comment on the 2 points above?

[plinss]

@luminous706: 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.