Force only TLS and DTLS sockets not working about coturn HOT 43 OPEN

No, even with an unencrypted connection with the TURN server, the WebRTC data cannot be compromised. Key exchange in WebRTC is done on a different layer (often called the signaling layer), and it is the signaling layer that needs to be encrypted and secure to prevent snooping or MITM attacks.

The TURN server is just a relay, it has no knowledge or insight into the data being send back and forth between WebRTC peers; all it sees are data packets that come from client A which need to be sent to client B. There is the possibility of IP/session data leakage if someone is able to sniff TURN traffic, but honestly, if an actor is able to do so, they will be able to see the source and destination IPs of all traffic anyway, so encrypting the TURN traffic doesn't give you anything.

In my experience, an encrypted connection to the TURN server was required because of proxy/firewall rules on a particular client network, not because of the risk of MITM at the TURN server. If your configuration works without (D)TLS to the TURN server, then there's no reason to enforce it.

TL;DR make your signaling layer is encrypted and secure, don't bother with (D)TLS on the TURN server unless you really need to.

from coturn.

I don´t want the turn server to be unencrypted. It would be very bad, if nextcloud talk uses an unencrypted turn server or do I understand something wrong?

Note that Nextcloud Talk uses WebRTC, which is already encrypted end-to-end, regardless of whether a TURN server is used or not. When a TURN server is used, the data it is relaying is encrypted already. Forcing an encrypted connection to the TURN server will end up making the TURN server re-encrypt already encrypted WebRTC packets.

from coturn.

TURN TLS is needed because some firewall are exposing only TLS (over 443 for example)

from coturn.

Hello all together,
Is there any progress?
I don´t want the turn server to be unencrypted. It would be very bad, if nextcloud talk uses an unencrypted turn server or do I understand something wrong?

from coturn.

Perhaps I misunderstood something as well, but --no_tcp + --no_udp should break coTURN functionality completely, since it must either communicate via TCP or UDP or both?

I as well found no way to disable listening-port (non TLS) at all. If not defined, it will use the default port 3478. Would be great if we had an option to only listen to the tls-listening-port via TLS.

However it is still possible to ensure encrypted TURN connections:

• In the mentioned case with Nextcloud, one can anyway only configure one specific port in the Talk app settings, so if the assigned TLS port is entered there, all Nextcloud Talk connections will be TLS encrypted.
• Of course other clients can still use coTURN via unencrypted port. To handle this:
  • In case behind a NAT, simply only forward the TLS port.
  • If you want to block non-TLS also within local network or coTURN is not behind a NAT, use iptables/nftables (respectively whatever firewall) to block the non-TLS port (+ alternative alt-listening-port, which is by default listening-port+1 = 3479), or at best block all ports besides the required ones.

from coturn.

So this Image shows that the MITM could just say he is the TURN server and shows both clients another Fake Client. Or how does the Clients know the that they are speaking with the right client?
The clients are using self signed certificates, right? Because they can't have a CA certificate like from lets encrypt.

The same problem would be with STUN, because also a MITM could be the STUN Server and just say give the wrong IPs and create Fake Clients and link the video/audio stream between the two fake clients.

The only way would be that the clients know that the STUN and TURN Server have to authenticate themselfes with a validate certificate like in HTTPS.

Or have I understood something completely wrong and WebRTC makes something completely different then Assymetric Key Exchange?
The Clients probably never talked to each other so they can't have a pre-shared key or something?

The nextcloud uses also a signaling server, is this the way that the clients authenticate them?

from coturn.

Tls and plain as the config files says are listening also on the other Port.
E.g. plain on plain and tls Port.
This can be configured.
The nextcloud Check responded without Error with no-tcp and no-udp enabled

from coturn.

@jonathanmmm

Tls and plain as the config files says are listening also on the other Port.

Okay this would be indeed a bug or a totally unreasonable confusing behaviour and security issue. Already the alt-* ports that are listened to by default don't make much sense to me. Either the ONE port works, or it doesn't and should be fixed, or if for any reason required, one could be allowed to "explicitly" add multiple ports.

This can be configured.

What you mean? You can change the above behaviour?

The nextcloud Check responded without Error with no-tcp and no-udp enabled.

Hmm, I am no specialist, but that does not make much sense to me either. What I could think of, is that disabling both is simply ignored, as this would break functionality completely? Or how should coTURN communicate aside with TCP or UDP?

Okay I read the config file comments about this. coTURN listens to both (all) ports the exact same way and automatically determines plain or TLS connection.
But "if allowed by configuration"? So how to deny this?

Further:

# Uncomment if no UDP client listener is desired.
# By default UDP client listener is always started.
#
#no-udp

# Uncomment if no TCP client listener is desired.
# By default TCP client listener is always started.
#
#no-tcp

# Uncomment if no TLS client listener is desired.
# By default TLS client listener is always started.
#
#no-tls

# Uncomment if no DTLS client listener is desired.
# By default DTLS client listener is always started.
#
#no-dtls

• So does this mean that no-udp/tcp explicitly means plain (non-D/TLS) connections?
• I am no specialist, but (D)TLS connections are still wrapped into TCP or UDP! Definitely confusing.
• Better/clearer to me would be: no-udp/tcp meaning indeed that for plain and TLS connections either UDP or TCP is disabled. And having no-tls/plain instead to disable encrypted or unencrypted listener.
• And of course this should not only stop listening to the ports (as long as they can be used for both), but block TLS/non-TLS connections completely then.

from coturn.

This is somehow what I am asking

from coturn.

@MichaIng We are welcome any correction to make coturn better.
Please submit a Pull Request.
If you can make it less confusing and make the config more sophisticated it would be great!
I would happy to incorporate it.

from coturn.

@bradleythughes In #33 (comment) you say that WebRTC communication is encrypted.

What I believe is not encrypted when not using TURNS is username and password, which means it opens doors for the man in the middle, specifically when used with long-term-credentials.

Can you confirm I am correct?

from coturn.

https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/
When the signaling server is compromised then you have a problem. But because the clients have self signed certificates/keys some instance has to be the trusted source.

from coturn.

Could you please send a pull request about it?

from coturn.

https://github.com/coturn/coturn/wiki/turnserver
There u can see:
--no-udp Do not start 'plain' UDP listeners.
--no-tcp Do not start 'plain'TCP listeners.

Problem:
The moment I put no-tcp in the config file nextcloud talk errors on only tcp.
UDP check still works.

If I change at UDP Only in nextcloud talk to some wrong port or change the credential (static-secret) to something wrong it fails. So UDP Checks that is working

If I put
tls-listening-port=5349 and
alt-listening-port=3470
and "no-udp" then on port 3478 I can see tcp listening (netstat).

So the standard port will listen (tcp and sctp)

So how can I completely force that there is only encrypted connections and no plain.
Like only HTTPS instead of HTTP by websites (as an example to illustrate)

from coturn.

Now I am as well doubled confused:

• Indeed with no-udp and no-tcp coTURN connection from Nextcloud does not work at all. TURN server check in admin panel fails and as well no WebRTC connection possible.

• So either it DOES as well disable UDP and TCP for TLS connections (thus does not allow any connection), or the TLS config does not work properly.

• curl -v https://my.domain.org:5349 reports:

  SSL certificate problem: unable to get local issuer certificate

  But the same cert works well on 443 webserver and as well coturn logs do not report any errors on startup, which is e.g. the case if the cert/key is not accessible by coturn run user. But curl (not supporting stun/turn protocol) might be not a good test anyway.
  Startup log:

Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: SSL23: Certificate file found: /etc/letsencrypt/live/my.domain.org/cert.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: SSL23: Private key file found: /etc/letsencrypt/live/my.domain.org/privkey.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: TLS1.2: Certificate file found: /etc/letsencrypt/live/my.domain.org/cert.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: TLS1.2: Private key file found: /etc/letsencrypt/live/my.domain.org/privkey.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: TLS cipher suite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: DTLS: Certificate file found: /etc/letsencrypt/live/my.domain.org/cert.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: DTLS: Private key file found: /etc/letsencrypt/live/my.domain.org/privkey.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: DTLS1.2: Certificate file found: /etc/letsencrypt/live/my.domain.org/cert.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: DTLS1.2: Private key file found: /etc/letsencrypt/live/my.domain.org/privkey.pem
Feb 23 16:59:34 my.domain.org turnserver[26085]: 0: DTLS cipher suite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5

• Disabling SSL(2/3) as well is missing, but this is another topic.

So indeed we don't know now if our connections are encrypted at all or not, since the same port allows both and explicitly disabling plain connections is not possible, or, breaks TLS as well.

from coturn.

But with Turn Server unencrypted the webrtc Connection could be compromised by MITM I believe?
Because the integrity between the clients and the turn server is vurnerable

from coturn.

@bradleythughes
Okay that is really helpful information. Didn't know that WebRTC encrypts by default, although it makes totally sense since in case of P2P connections there is no TURN server in the middle. Thanks for clarifying this.

The only left reason to use (D)TLS on the TURN server then is to verify the TURN server authenticity, although there is not much reason for this. If it enables the connection, then it doesn't matter who it is, since it cannot use the encrypted data stream?

Still the settings and how they work are currently confusing and still a security vulnerability by this, if not used with an already encrypted data stream (something different than WebRTC).

from coturn.

@misi
I am no c coder, however not hard to understand the code. I am currently very busy on own project but will see if I can have a look by times.

from coturn.

@MichaIng
Thanks a lot.. I look forward to it..

from coturn.

#33 (comment)

I will shortly post some graphic to illustrate the connection paths.

Still, is there any way to force only tls/dtls?

It says "If allowed by configuration" so there has to be a way to disallow it. I thought -no-udp and -no-tcp are the disallow.
But then tcp ssl does Not work anymore?

from coturn.

Check Webrtc identity: https://www.w3.org/TR/webrtc-identity/

from coturn.

And this: https://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf

from coturn.

Great, thanks.

Still the question:
Is it possible to force only encrypted stun and turn connections through coturn?

When given in the config
"Tls-listening-port=..."
"no-udp"
"no-tcp"
And NO(!) plain port configured

Then: Udp encrypted works and tcp not (Shown in nextcloud Talk config Test).

So why is udp encryption possible to force and udp not?

If there is now way to force encrypted Connection I can bring that into the Manual/config File. But I have to know.

Thanks already for the great help and for what you do :)

from coturn.

Regarding WebRTC security and privacy, this is the canonical source: https://www.w3.org/TR/webrtc/#privacy-and-security-considerations

from coturn.

@bradleythughes In #33 (comment) you say that WebRTC communication is encrypted.

What I believe is not encrypted when not using TURNS is username and password, which means it opens doors for the man in the middle, specifically when used with long-term-credentials.

Can you confirm I am correct?

You are correct. If you use TURN unencrypted, then the TURN username and password will be visible to anyone able to see the traffic. This is why you should be using throw-away, time-limited TURN credentials. See https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 and the static-auth-secret config option.

Regardless, WebRTC traffic is still encrypted end-to-end, even when running via an unencrypted TURN server. Even if someone is sniffing your TURN packets, they only see encrypted SRT(C)P packets going back and forth between WebRTC peers. Unencrypted TURN traffic is not the same as unencrypted audio/video traffic.

Hope this helps :)

from coturn.

And what happens when somebody fakes the turn server (like my graphic) and lets the client communicate with fake clients? Would that be possible? Because if the TURN Server uses a TLS certificate (not self signed) and the clients no that they should expect TLS there would be no easy way to MITM as a fake TURN server.

Am I missing something? Maybe the clients get (e.g. in Nextcloud) a secret that a fake TURN server would not know or something like that?!

from coturn.

@bradleythughes Yeah, it does, thanks. Given that UDP candidates are preferred (and these cannot be served via TLS) the only reason for configuring coturn securely (when using it for WebRTC only traffic) would to prevent blocking at the firewall. I assume some firewalls will detect WebRTC encrypted traffic as unencrypted because the encryption isn't happening on the transport layer. Does that make sense, or are there other reasons?

from coturn.

I can see what @jonathanmmm is saying. I believe there is a peer-identity mechanism https://www.w3.org/TR/webrtc/#dfn-peeridentity which can also prevent that. Have the clients check server certs would probably work as well.

from coturn.

Just as a side note regarding Nextcloud Talk:

• It does not use TURNS (TURN TLS) at all currently, which is also the reason why disabling plain access breaks it: nextcloud/spreed#257

from coturn.

UDP uses DTLS in TURN.

That nextcloud does not use encryption would explain why it does not work with only encrypted Connection. So if I put no-udp and no-tcp no unencrypted Connection should be possible? Maybe then some config manual should be made more clear.

Also why did (if this really makes only encrypted connections possible) still the udp check work in nextcloud talk? Tcp encrypted fails but encrypted udp not?!

from coturn.

@jonathanmmm

And what happens when somebody fakes the turn server (like my graphic) and lets the client communicate with fake clients? Would that be possible? Because if the TURN Server uses a TLS certificate (not self signed) and the clients no that they should expect TLS there would be no easy way to MITM as a fake TURN server.

A malicious TURN server that forces clients to talk to "fake" clients would not get very far, since these fake clients would not be able to complete key exchange... unless your signaling layer was also compromised. That's a pretty complex threat model, if you ask me, and tbh I would worry more about compromised signaling in that case.

Am I missing something? Maybe the clients get (e.g. in Nextcloud) a secret that a fake TURN server would not know or something like that?!

Each client generates its own secret already... the key used to encrypt the WebRTC traffic. The key fingerprint is shared securely via signaling with the remote client for verification purposes. This is part of the SDP in the offer/answer created by WebRTC. If you haven't read the WebRTC privacy and security documentation, I would recommend doing so now. :) https://www.w3.org/TR/webrtc/#privacy-and-security-considerations

from coturn.

If somebody has access to your traffic (like fake wifi hotspot) he could also incept the signalimg layer, right? And somebody trying to break it would probably be prepared for signaling and turn server. The fake clients would have their own keys and exchange them with the clients. So now both users are communicating with a different fake Client. In the end the video and audio gets linked by the attacker from one fame Client to the other. (There is already a tutorial for it, I can search, if you want to know). In the end the MITM can record everything and the users could communicate with each other normally.

Did I get it wrong?

from coturn.

@jonathanmmm If you link media encryption key to identity then you can avoid such attack..
See webrtc-identity

from coturn.

Okay guy let me sum up what I got to verify that I derived/understood everything correctly:

• coTURN ALWAYS listens to four ports:
  • listening-port (default = 3478)
  • tls-listening-port (default = 5349)
  • alt-listening-port (default = listening-port + 1)
  • alt-tls-listening-port (default = tls-listening-port + 1)
• It generally allows (D)TLS and plain connections on all four ports.
  • You can limit to plain via no-(d)tls or let it fail by adding no cert/pkey.
  • You can limit to (D)TLS via no-udp + no-tcp
  • You can combine the above to limit to any combination of (plain) UDP, (pain) TCP, TLS or DTLS.
  • Finally you can limit the TLS protocol via no-tlsv1, no-tlsv1_1 and/or no-tlsv1_2
• But what ever you allow via above, it always applies to all four ports!

I am not sure now if it is possible to limit everything to one single port by setting all of them to the same port number? EDIT: Just tried and at least it does not throw any error.

• Generally the TLS/plain port separation exists to satisfy RFC 5766.
• The alternative ports exist to satisfy RFC 5780, although I am not sure in which circumstances this makes sense. If the one port does not answer, then the server most likely does not answer on the alternative port as well? Also if you can set it to whatever you want, then the clients cannot know anyway which alternative port they can try.

From admin point of view it would be actually easier to only allow one single port. If the firewall allows it, this can be used for plain TCP/UDP, otherwise (D)TLS, as coTURN allows both types on that port.
But an open protocol only makes sense if the related RFCs are fulfilled, so this is taken as given.

So finally when the RFCs are to be respected, then indeed it makes sense to do this consequently, thus only allowing (D)TLS on the (alt-)tls-listening-port and plain TCP/UDP on the (alt-)listening-port. As mentioned already above otherwise it is simply confusing from admin point of view to know which port is used for what and how to configure the firewall + setup the clients. Especially the users never know if they are connecting via (D)TLS or not when using a certain port. When disabling either plain or (D)TLS, the related ports should be not listened to at all, to allow the admin skip handling of them for proxy/firewall/redirects and all such. But this is only my opinion about it 😉.

from coturn.

I think I get it, the security is established over the signaling server. Is the signaling server the nextcloud server over HTTPS? Then the key exchange is secure as long as the nextcloud server is not compromised by a hacker.

from coturn.

From nextcloud talk setting:
Signaling server

An external signaling server can optionally be used for larger installations. Leave empty to use the internal signaling server.

from coturn.

@jonathanmmm
Makes sense. Of course if the Nextcloud server is compromised then a possibly compromised TURN server is your smallest problem and implicit if both are on the same machine.

Yeah so finally I think it can be taken as a fact that there is no need to enable (D)TLS for security reasons. However this does not change the fact (IMO) that the way coTURN handles the ports is at best confusing and increases configuration/overview efforts for admins that want/need to control/handle all ports of their machine. At least the default turnserver.conf explains everything very well and correct.

from coturn.

• coTURN ALWAYS listens to four ports:

  • listening-port (default = 3478)
  • tls-listening-port (default = 5349)
  • alt-listening-port (default = listening-port + 1)
  • alt-tls-listening-port (default = tls-listening-port + 1)

• It generally allows (D)TLS and plain connections on all four ports.

  • You can limit to plain via no-(d)tls or let it fail by adding no cert/pkey.
  • You can limit to (D)TLS via no-udp + no-tcp
  • You can combine the above to limit to any combination of (plain) UDP, (pain) TCP, TLS or DTLS.
  • Finally you can limit the TLS protocol via no-tlsv1, no-tlsv1_1 and/or no-tlsv1_2

• But what ever you allow via above, it always applies to all four ports!

I think i have NO TLS listener started because i only see 2 ports open: 3478 and 3479.
tls-listening-port is not commented, and no-tls is commented out.
How to enable the other 2 TLS ports?

from coturn.

@expressrussian
Not sure. The service or binary log should show which listener was started, e.g.:

journalctl -u coturn

or

cat /var/log/turn.log

from coturn.

@bradleythughes "This is why you should be using throw-away, time-limited TURN credentials.". Could you give a config example please?

from coturn.

TLS listener accepts TCP connections so this is not supported yet. This is not a problem for WebRTC services as media is already encrypted at SRTP level anyway.

from coturn.

@bradleythughes "This is why you should be using throw-away, time-limited TURN credentials.". Could you give a config example please?

Check https://github.com/coturn/coturn/blob/master/examples/run_tests.sh for the shared_secret usage that uses time limited TURN credentials. You can check this doc for the explaination of how it works: https://datatracker.ietf.org/doc/html/draft-uberti-behave-turn-rest-00

from coturn.

New ICE Test tool:

https://icetest.atec-systems.com/

from coturn.