3 ms·

The problem I see with TURN is there's basically no way to prevent people from abusing it publicly for relaying any traffic they want, without any of your own w

The problem I see with TURN is there's basically no way to prevent people from abusing it publicly for relaying any traffic they want, without any of your own web sites or WebRTC apps involved.

cookie_monsta 2y ago
Basic authentication is covered in Section 11[0] There are more thoughts on tightening up authentication in the last section "Tightening and tidying" Apologies if I have misunderstood your comment [0]https://github.com/lvidgen/WebRTC/blob/master/FOSS_TURN_Server/howto.md#11-add-some-authentication https://github.com/lvidgen/WebRTC/blob/master/FOSS_TURN_Serv...
- ranger_danger 2y ago
  Authentication still requires the client to have access to the password, where you can just take it and use it for any other purpose. Unless you're asking every user to manually input a TURN password and they promise not to give it out, you're basically forced to reveal it to every visitor of your site.
  - cookie_monsta 2y ago
    yes, but you can block cross origin requests to both the credentials server and the PeerJS server which I understand prevents this: "relaying any traffic they want, without any of your own web sites or WebRTC apps involved" Again, not an expert. This problem only really exists for "ad-hoc" connections where you don't want people to have to set up accounts. coturn has the ability to do standard authentication by checking credentials stored in databases
  - mtud 2y ago
    You can generate short-lived and single-use credentials for users.
    - ranger_danger 2y ago
      Yes, but, if this is a public website that anyone can use, then an abuser using your TURN server for other purposes can also grab a single-use credential from the site, making it a bit pointless.
Sean-Der 2y ago
I see a couple ways to combat that. * Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users. * Use an auth mechanism that has an expiry time. Like [0] [0] https://github.com/pion/turn/tree/master/examples/lt-cred-generator https://github.com/pion/turn/tree/master/examples/lt-cred-ge...
- cookie_monsta 2y ago
  > * Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users. coturn provides these APIs, they're not covered in the writeup, though > * Use an auth mechanism that has an expiry time. Like [0] This is how the credentials server in the write up works
fenesiistvan 2y ago
Yes, usually some more intelligent auth is needed, depending on your app logic. For example the MRTC SIP-WebRTC gateway will do the usual SIP digest auth first, then will send a temporary TURN password to the WebRTC client + it will allow only the current source IP to use the TURN service (with an extra auth message exchane if the IP changes during the call).

The problem I see with TURN is there's basically no way to prevent people from abusing it publicly for relaying any traffic they want, without any of your own web sites or WebRTC apps involved.

cookie_monsta 2y ago

Basic authentication is covered in Section 11[0] There are more thoughts on tightening up authentication in the last section "Tightening and tidying" Apologies if I have misunderstood your comment [0]https://github.com/lvidgen/WebRTC/blob/master/FOSS_TURN_Server/howto.md#11-add-some-authentication https://github.com/lvidgen/WebRTC/blob/master/FOSS_TURN_Serv...

ranger_danger 2y ago
Authentication still requires the client to have access to the password, where you can just take it and use it for any other purpose. Unless you're asking every user to manually input a TURN password and they promise not to give it out, you're basically forced to reveal it to every visitor of your site.
- cookie_monsta 2y ago
  yes, but you can block cross origin requests to both the credentials server and the PeerJS server which I understand prevents this: "relaying any traffic they want, without any of your own web sites or WebRTC apps involved" Again, not an expert. This problem only really exists for "ad-hoc" connections where you don't want people to have to set up accounts. coturn has the ability to do standard authentication by checking credentials stored in databases
- mtud 2y ago
  You can generate short-lived and single-use credentials for users.
  - ranger_danger 2y ago
    Yes, but, if this is a public website that anyone can use, then an abuser using your TURN server for other purposes can also grab a single-use credential from the site, making it a bit pointless.

Sean-Der 2y ago

I see a couple ways to combat that. * Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users. * Use an auth mechanism that has an expiry time. Like [0] [0] https://github.com/pion/turn/tree/master/examples/lt-cred-generator https://github.com/pion/turn/tree/master/examples/lt-cred-ge...

cookie_monsta 2y ago
> * Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users. coturn provides these APIs, they're not covered in the writeup, though > * Use an auth mechanism that has an expiry time. Like [0] This is how the credentials server in the write up works

fenesiistvan 2y ago

Yes, usually some more intelligent auth is needed, depending on your app logic. For example the MRTC SIP-WebRTC gateway will do the usual SIP digest auth first, then will send a temporary TURN password to the WebRTC client + it will allow only the current source IP to use the TURN service (with an extra auth message exchane if the IP changes during the call).