Any way to secure hard coded credentials?

[Monte]

Hi guys,

Does anyone know how TURN server can be secured from client side because password is visible in clients web browser source?

I'm refering to this part of code:

    Connection.prototype.connect = function() {

        var pc = new RTCPeerConnection({

            "iceServers" : []

        {"url": "turn:11.111.111.11:8000", "credential": "youhavetoberealistic", "username":"ninefingers"}

        });

Thanks

[Oleg Moskalenko]

There is a short-lived credentials approach (see the REST API section in the wiki).

Another approach (will be available in the future) is OAuth-based authorization. The specs are in working. When they are finished, we will be working on the implementation.

Regards,
Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

[onyii5119]

Oleg, I have actually being thinking about the open credentials in turnserver for quite sometime. Now that the issue has come up again, I will like to ask if one can add additional columns to "turnusers_st" table without disrupting the validation process handled by the turnserver when using short-term credentials. The NAME and PASSWORD columns will still be the same. For my use case the short-term credentials process is most suited for it. My database is secure and I can dynamically update the table. 

Do you envisage any problems?

Thanks,

Jonathan

On Tuesday, March 11, 2014 2:48:39 PM UTC-4, Oleg Moskalenko wrote:

There is a short-lived credentials approach (see the REST API section in the wiki).

Another approach (will be available in the future) is OAuth-based authorization. The specs are in working. When they are finished, we will be working on the implementation.

Regards,
Oleg

On Tue, Mar 11, 2014 at 11:44 AM, Monte <montc...@gmail.com> wrote:

Hi guys,

Does anyone know how TURN server can be secured from client side because password is visible in clients web browser source?

I'm refering to this part of code:

    Connection.prototype.connect = function() {

        var pc = new RTCPeerConnection({

            "iceServers" : []

        {"url": "turn:11.111.111.11:8000", "credential": "youhavetoberealistic", "username":"ninefingers"}

        });

Thanks

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Monte]

I was reading wiki and it says that for webrtc it can be done only with long-term credentials. Is this correct?

Sorry, i'm new with this

On Tuesday, March 11, 2014 7:48:39 PM UTC+1, Oleg Moskalenko wrote:

There is a short-lived credentials approach (see the REST API section in the wiki).

Another approach (will be available in the future) is OAuth-based authorization. The specs are in working. When they are finished, we will be working on the implementation.

Regards,
Oleg

On Tue, Mar 11, 2014 at 11:44 AM, Monte <montc...@gmail.com> wrote:

Hi guys,

Does anyone know how TURN server can be secured from client side because password is visible in clients web browser source?

I'm refering to this part of code:

    Connection.prototype.connect = function() {

        var pc = new RTCPeerConnection({

            "iceServers" : []

        {"url": "turn:11.111.111.11:8000", "credential": "youhavetoberealistic", "username":"ninefingers"}

        });

Thanks

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

If you just add the columns to the tables, it will not affect anything. The TURN server will not see those columns.

Regards,
Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Oleg Moskalenko]

Yes, the WebRTC browsers support only the long-term credentials mechanism.

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Kevin Dempsey]

You can have time limited username/password combinations based on a shared secret, which uses the TURN protocol's long term mechanism.

[Jo Yum]

Hi all,

Is the TURN server's credentials MySQL table accessible by other processes? I'm asking because I'd like to do this:

When a user login occurs to my WebRTC app, I'd like to lock the TURN server's credentials table from my XHR handler, and insert a row to the table with the session token for that user. 

Then I'd like to send the TURN request from the client, including the session token as the password.

When the user logout occurs, I'd like to remove the row for that user from the TURN server's credentials table, again from my XHR handler.

Is this possible on this TURN server?

Thank you

[Oleg Moskalenko]

On Sat, Jun 13, 2015 at 1:08 PM, Jo Yum <conr...@hotmail.com> wrote:
> Hi all,
>
> Is the TURN server's credentials MySQL table accessible by other processes?

Why you are asking ? You set the MySQL database, so you must know
which access parameters your database has. The only TURN server
requirement is that the TURN server has to be able to access it.
Everything else is up to you.

> I'm asking because I'd like to do this:
>
> When a user login occurs to my WebRTC app, I'd like to lock the TURN
> server's credentials table from my XHR handler, and insert a row to the
> table with the session token for that user.
>
> Then I'd like to send the TURN request from the client, including the
> session token as the password.
>
> When the user logout occurs, I'd like to remove the row for that user from
> the TURN server's credentials table, again from my XHR handler.

I do not advise to do that. You may run into many different
authorization problems.

>
> Is this possible on this TURN server?
>
> Thank you
>

[Jo Yum]

Hi Oleg,

If I can't alter the TURN server's credentials MySQL table with a valid session token for each authorized user, and if the WebRTC client sends the TURN server credentials from JS (i.e. the TURN server credentials are visible to the world), then how can I secure the TURN server from unauthorized users?

Thank you

[Oleg Moskalenko]

The TURN server is a secure system, and it has very little possible
security problems. You problems is with WebRTC scheme how WebRTC uses
the TURN server, not with the TURN server itself.

There are two ways to make TURN operations more secure with WebRTC:

1) Use functionality under (wrongfully named) umbrella "REST API".
2) Or use third-party authorization scheme (oAuth).

How to set the TURN server for that, is fully described in Wiki pages.
How to set WebRTC for that, I have no idea.

Oleg

[Jo Yum]

Hi Oleg,

For a new TURN server installation on Linux, would you recommend using the rfc5766-turn-server or the coturn fork?

Regards

[Oleg Moskalenko]

for all new installations, I recommend coturn.

[Jo Yum]

Hi Oleg,

I installed coturn on a Linux server, without errors.

Ran all the diagnostic scripts that came with it, which indicate that coturn is operating correctly.

Opened port 3478 in the INPUT chain of iptables for tcp and udp.

Started turnserver with this command (not the real IP):

turnserver -V -z -L 1.2.3.4


Used this tool for testing the TURN server at this URL (turn:1.2.3.4:3478):

http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

No ICE candidates for relay are collected, suggesting that my TURN server is not working properly.

The coturn log file doesn't indicate an attempted connection, or any errors.

I also started turnserver with this command (not the real IP):

turnserver -v -c "turntest.conf" -L 1.2.3.4

where turntest.conf contains this:

fingerprint

lt-cred-mech

#single static user details for long-term authentication:

user=username1:password1

#your domain here:

realm=example.com

In this case, the WebRTC client above, calls my coturn server on these URL's:

var pc_config = {'iceServers': [

{'url': 'stun:1.2.3.4:3478'}, 

{'url': 'turn:user...@1.2.3.4:3478?transport=udp','credential':'password1'}

]};

but again, no ICE candidates for relay are collected.

Any ideas what could be wrong?

Thank you

[Jo Yum]

To Oleg, or anyone else,

Using tcpdump on my Linux server where coturn is running, I traced the STUN/TURN requests arriving at coturn port 3478, from Trickle-ICE on Chrome.

See: http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

This is the Wireshark trace of those requests:

No. Time Source Destination Protocol Length Info

1 0.000000 5.6.7.8 1.2.3.4 STUN 62 Binding Request

2 0.000290 5.6.7.8 1.2.3.4 STUN 62 Binding Request

3 0.047414 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

4 0.047580 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

5 0.097650 5.6.7.8 1.2.3.4 STUN 62 Binding Request

6 0.099869 5.6.7.8 1.2.3.4 STUN 62 Binding Request

7 0.147398 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

8 0.147613 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

9 0.297656 5.6.7.8 1.2.3.4 STUN 62 Binding Request

10 0.299877 5.6.7.8 1.2.3.4 STUN 62 Binding Request

11 0.350324 5.6.7.8 1.2.3.4 STUN 70 Allocate Request UDP

...

[snip]

...

37 9.552835 5.6.7.8 1.2.3.4 STUN 62 Binding Request

I changed the IP's and domain names in these listings, but the real IP's and domain names are correct.

I'm starting coturn like this:

turnserver -c /opt/coturn/turnserver-4.4.5.2/examples/etc/turntest3.conf

The config file (turntest3.conf) contains this:

listening-port=3478

tls-listening-port=5349

listening-ip=1.2.3.4

relay-ip=1.2.3.9

external-ip=1.2.3.4

#relay-threads=10

#fingerprint

lt-cred-mech

user=u:0

cert=/etc/nginx/ssl/example.com.crt

pkey=/etc/nginx/ssl/example.com.key

#mobility

verbose

realm=example.com

netstat commands on the Linux server, show how coturn is listening for STUN/TURN requests:

netstat -a | grep 'stun'

tcp        0      0 example.com:stun             *:*                         LISTEN

tcp        0      0 example.com:stuns            *:*                         LISTEN

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stuns            *:*

udp        0      0 example.com:stun             *:*

udp        0      0 example.com:stun             *:*

udp        0      0 example.com:stun             *:*

udp        0      0 example.com:stun             *:*

netstat -a | grep '3478'

sctp                example.com:3478                                         LISTEN

netstat -a | grep '5349'

sctp                example.com:5349                                         LISTEN

Does the above mean that coturn is not listening for UDP? And if so, how do I fix that?

Why aren't the WebRTC TURN requests from Trickle-ICE answered by coturn?

Thank you.

[Oleg Moskalenko]

the TURN server is always listening to UDP ports (unless you specially ask it not to do it).

Try running it as superuser.

[Jo Yum]

Sorted. The Linux server ports were blocked for output !

"netstat -nap | grep 3478" --> all bindings owned by turnserver

Thank you !