#3 nextcloud talk enterprice backend

Open
opened 4 months ago by m · 2 comments
m commented 4 months ago

notes

existing

  • Caddy - Public https Proxy
  • Nextcloud - Apache-php container
  • Mariadb

addons

  • nextcloud spreed signaling backend
    • public accessable
    • connected with nextcloud talk
    • connected with nats
    • connected with janus gateway
  • janus-gateway
  • nats
# notes * https://www.golem.de/news/videochat-nextcloud-talk-bekommt-offenes-enterprise-backend-2005-148582.html * https://docs.nats.io/nats-server/running * https://github.com/meetecho/janus-gateway * https://github.com/strukturag/nextcloud-spreed-signaling # existing * Caddy - Public https Proxy * Nextcloud - Apache-php container * Mariadb #### addons * nextcloud spreed signaling backend * public accessable * connected with nextcloud talk * connected with nats * connected with janus gateway * janus-gateway * nats
m commented 1 month ago
Owner

https://github.com/coturn/coturn/issues/33#issuecomment-467419297

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.

https://github.com/coturn/coturn/issues/33#issuecomment-467419297 > 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.
m commented 1 month ago
Owner
https://nextcloud-talk.readthedocs.io/en/latest/TURN/#3-configure-turnserverconf-for-usage-with-nextcloud-talk
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.