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.
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.
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
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.
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).
Comments
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.
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_Serv...
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.
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
You can generate short-lived and single-use credentials for users.
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.
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-ge...
coturn provides these APIs, they're not covered in the writeup, though
This is how the credentials server in the write up works
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).