turnserver-devel — Discussions on development of TurnServer

Re: [Turnserver-devel] SSL client authentication issue

[Sébastien G. <sgi...@gm...>]

YEAHAA, I found the answer to my issue with your helpful test_turn_client
 advice

And the answer is that I made the following command line where my.crt and
my.key are the certificates I configured in /etc/turnserver.conf

openssl pkcs12 -export -out my.pfx -in /home/certs/my.crt -inkey
/home/private/my.key

It creates a PKCS #12 certificate containing the private key and I can use
in my C# client



2012/7/19 Sébastien GISSINGER <sgi...@gm...>

> I tried the test_turn_client and it works.
>
> I used what I self-made for my apache server :
>  -k Private Key
>  -s Client Certificate
>  -a CA Certificate (me)
>
>
> The difference with my Windows C# client is that I do not have any CA
> Certificate to send in the SSL request because it's a self-signed one.
>
> And if I try to bypass -a parameter test_turn_client is not happy
>
>
>
> 2012/7/19 Sebastien Vincent <se...@ji...>
>
>> Hi,
>>
>> Do you have tried the sample test_turn_client ? Does it works or not  ?
>>
>>
>> Le mercredi 18 juillet 2012, Sébastien GISSINGER <sgi...@gm...>
>> a écrit
>>
>> > I use a C# SSL client code to make TLS over TCP STUNS requests. This
>> code works well with ejabberd SSL STUN implementation
>> >
>> >
>> > I noted that you were waiting a certificate from the TURN client. So I
>> send one using the following method
>> http://msdn.microsoft.com/en-us/library/ms145061(v=vs.80).aspx
>> > It gives the following piece of code, where turnServer is the IP of the
>> host, clientCertificates is a collection of certificates which contains
>> only one certificate and the boolean has no impact here :
>> >
>> >
>> sslStream.AuthenticateAsClient(turnServer, clientCertificates, SslProtocols.Tls, true);
>> >
>> > But when this method tries to authenticate on the client side, I get
>> this error
>> > The certificate chain was issued by an authority that is not trusted.
>> > Which should be handled by a callback method returning always true for
>> debugging purpose to make my code trusts any certificate valid or not.
>> > But this callback is never fired with turnserver whereas it's fired
>> when I make the same request on ejabberd SSL STUN.
>> > http://msdn.microsoft.com/en-us/library/ms145054(v=vs.80).aspx
>> >
>> >
>> > And I also got the following errors on server side
>> > [turnserver.c:4661]     Received TLS on listening address
>> > [turnserver.c:4588]     Received data from TLS client
>> > SSL_ERROR_WANT_READ
>> > [turnserver.c:4624]     Error: Succès
>> > [turnserver.c:4588]     Received data from TLS client
>> > SSL_ERROR_SSL: no certificate returned
>> > [turnserver.c:4624]     Error: Succès
>> > [turnserver.c:4588]     Received data from TLS client
>> > [turnserver.c:4641]     Error: Succès
>> >
>> > I'm not a POSIX C guru so I don't understand what's happening. I made a
>> little trip to http://www.openssl.org/docs/ssl/SSL_get_error.html but
>> without any success.
>> > Help will be really appreciated.
>> > Thanks
>>
>
>

Re: [Turnserver-devel] SSL client authentication issue

[Sébastien G. <sgi...@gm...>]

I tried the test_turn_client and it works.

I used what I self-made for my apache server :
 -k Private Key
 -s Client Certificate
 -a CA Certificate (me)


The difference with my Windows C# client is that I do not have any CA
Certificate to send in the SSL request because it's a self-signed one.

And if I try to bypass -a parameter test_turn_client is not happy



2012/7/19 Sebastien Vincent <se...@ji...>

> Hi,
>
> Do you have tried the sample test_turn_client ? Does it works or not  ?
>
>
> Le mercredi 18 juillet 2012, Sébastien GISSINGER <sgi...@gm...> a
> écrit
>
> > I use a C# SSL client code to make TLS over TCP STUNS requests. This
> code works well with ejabberd SSL STUN implementation
> >
> >
> > I noted that you were waiting a certificate from the TURN client. So I
> send one using the following method
> http://msdn.microsoft.com/en-us/library/ms145061(v=vs.80).aspx
> > It gives the following piece of code, where turnServer is the IP of the
> host, clientCertificates is a collection of certificates which contains
> only one certificate and the boolean has no impact here :
> >
> >
> sslStream.AuthenticateAsClient(turnServer, clientCertificates, SslProtocols.Tls, true);
> >
> > But when this method tries to authenticate on the client side, I get
> this error
> > The certificate chain was issued by an authority that is not trusted.
> > Which should be handled by a callback method returning always true for
> debugging purpose to make my code trusts any certificate valid or not.
> > But this callback is never fired with turnserver whereas it's fired when
> I make the same request on ejabberd SSL STUN.
> > http://msdn.microsoft.com/en-us/library/ms145054(v=vs.80).aspx
> >
> >
> > And I also got the following errors on server side
> > [turnserver.c:4661]     Received TLS on listening address
> > [turnserver.c:4588]     Received data from TLS client
> > SSL_ERROR_WANT_READ
> > [turnserver.c:4624]     Error: Succès
> > [turnserver.c:4588]     Received data from TLS client
> > SSL_ERROR_SSL: no certificate returned
> > [turnserver.c:4624]     Error: Succès
> > [turnserver.c:4588]     Received data from TLS client
> > [turnserver.c:4641]     Error: Succès
> >
> > I'm not a POSIX C guru so I don't understand what's happening. I made a
> little trip to http://www.openssl.org/docs/ssl/SSL_get_error.html but
> without any success.
> > Help will be really appreciated.
> > Thanks
>

Re: [Turnserver-devel] Bad padding in 401 Error Reason attribute

[Sebastien V. <se...@ji...>]

Hi,

Thanks for your report.

I confirm this issue. It is due to sizeof(MYSTRING) that includes
null-terminated character.

I will fix it this week or next ones.

Regards,
--
Seb

Le mercredi 18 juillet 2012, Sébastien GISSINGER <sgi...@gm...> a
écrit :
> It seems that padding apply to the reason phrase of the 401 ErrorCode is
not accurate
> When doing an ALLOCATE request, turnserver returns me an ERROR class
message of type 401 with a reason phrase "Unauthorized" all is right as
described in TURN RFC5766.
> In details, the response contains the following informations :
> Class    00 09 (ERROR-CODE)
> Length   00 14 (20 bytes)
> Reserved 00 00
> Class    04
> Code     01
> Reason   55 6e 61 75 . 74 68 6f 72 . 69 7a 65 64 . 00 00 00 00
>           U  n  a  u    t  h  o  r    i  z  e  d
>
> Everything is ok except the 00 00 00 00 padding at the end of the reason
phrase which is not needed.
> Without it the length would be 16 bytes which is already a 32bits rounded
value
> You can saw that behavior in Wireshark.

[Turnserver-devel] SSL client authentication issue

[Sebastien V. <se...@ji...>]

Hi,

Do you have tried the sample test_turn_client ? Does it works or not  ?


Le mercredi 18 juillet 2012, Sébastien GISSINGER <sgi...@gm...> a
écrit
> I use a C# SSL client code to make TLS over TCP STUNS requests. This code
works well with ejabberd SSL STUN implementation
>
>
> I noted that you were waiting a certificate from the TURN client. So I
send one using the following method
http://msdn.microsoft.com/en-us/library/ms145061(v=vs.80).aspx
> It gives the following piece of code, where turnServer is the IP of the
host, clientCertificates is a collection of certificates which contains
only one certificate and the boolean has no impact here :
>
>
sslStream.AuthenticateAsClient(turnServer, clientCertificates,
SslProtocols.Tls, true);
>
> But when this method tries to authenticate on the client side, I get this
error
> The certificate chain was issued by an authority that is not trusted.
> Which should be handled by a callback method returning always true for
debugging purpose to make my code trusts any certificate valid or not.
> But this callback is never fired with turnserver whereas it's fired when
I make the same request on ejabberd SSL STUN.
> http://msdn.microsoft.com/en-us/library/ms145054(v=vs.80).aspx
>
>
> And I also got the following errors on server side
> [turnserver.c:4661]     Received TLS on listening address
> [turnserver.c:4588]     Received data from TLS client
> SSL_ERROR_WANT_READ
> [turnserver.c:4624]     Error: Succès
> [turnserver.c:4588]     Received data from TLS client
> SSL_ERROR_SSL: no certificate returned
> [turnserver.c:4624]     Error: Succès
> [turnserver.c:4588]     Received data from TLS client
> [turnserver.c:4641]     Error: Succès
>
> I'm not a POSIX C guru so I don't understand what's happening. I made a
little trip to http://www.openssl.org/docs/ssl/SSL_get_error.html but
without any success.
> Help will be really appreciated.
> Thanks

[Turnserver-devel] Bad padding in 401 Error Reason attribute

[Sébastien G. <sgi...@gm...>]

It seems that padding apply to the reason phrase of the 401 ErrorCode is
not accurate

When doing an ALLOCATE request, turnserver returns me an ERROR class
message of type 401 with a reason phrase "Unauthorized" all is right as
described in TURN RFC5766.

In details, the response contains the following informations :

Class    00 09 (ERROR-CODE)
Length   00 14 (20 bytes)

Reserved 00 00
Class    04
Code     01

Reason   55 6e 61 75 . 74 68 6f 72 . 69 7a 65 64 . 00 00 00 00
          U  n  a  u    t  h  o  r    i  z  e  d


Everything is ok except the 00 00 00 00 padding at the end of the reason
phrase which is not needed.
Without it the length would be 16 bytes which is already a 32bits rounded
value

You can saw that behavior in Wireshark.

[Turnserver-devel] SSL client authentication issue

[Sébastien G. <sgi...@gm...>]

I use a C# SSL client code to make TLS over TCP STUNS requests. This code
works well with ejabberd SSL STUN implementation



I noted that you were waiting a certificate from the TURN client. So I send
one using the following method
http://msdn.microsoft.com/en-us/library/ms145061(v=vs.80).aspx

It gives the following piece of code, where turnServer is the IP of the
host, clientCertificates is a collection of certificates which contains
only one certificate and the boolean has no impact here :

sslStream.AuthenticateAsClient(turnServer, clientCertificates,
SslProtocols.Tls, true);



But when this method tries to authenticate on the client side, I get this
error

The certificate chain was issued by an authority that is not trusted.

Which should be handled by a callback method returning always true for
debugging purpose to make my code trusts any certificate valid or not.

But this callback is never fired with turnserver whereas it's fired when I
make the same request on ejabberd SSL STUN.
http://msdn.microsoft.com/en-us/library/ms145054(v=vs.80).aspx



And I also got the following errors on server side

[turnserver.c:4661]     Received TLS on listening address
[turnserver.c:4588]     Received data from TLS client
SSL_ERROR_WANT_READ
[turnserver.c:4624]     Error: Succès
[turnserver.c:4588]     Received data from TLS client
SSL_ERROR_SSL: no certificate returned
[turnserver.c:4624]     Error: Succès
[turnserver.c:4588]     Received data from TLS client
[turnserver.c:4641]     Error: Succès


I'm not a POSIX C guru so I don't understand what's happening. I made a
little trip to http://www.openssl.org/docs/ssl/SSL_get_error.html but
without any success.

Help will be really appreciated.
Thanks

Re: [Turnserver-devel] Compilation issues on debian squeeze

[Sébastien G. <sgi...@gm...>]

mmmmm sorry it worked but using autoconf -i not autoreconf -i

I have a warning but turnserver starts and parses /etc/stunserver.conf
correctly



2012/7/18 Sébastien GISSINGER <sgi...@gm...>

> I try to compile TurnServer on a Debian Squeeze 6.0 on a 64bit architecture
>
> But I got the following error when typing autoreconf -i command
>
> configure.in:10: error: possibly undefined macro: AC_MSG_RESULT
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
>
>
> Typing the command a second time do not show the message again but next I
> got the following error typing ./configure command
>
> ./configure: line 2418: syntax error near unexpected token `CHECK,'
> ./configure: line 2418: `PKG_CHECK_MODULES(CHECK, check >=
> 0.9.4,,AC_MSG_RESULT([testing is disabled]))'
>
> I tried the same thing on a Debian Squeeze VirtualBox VMs in 32bits and it
> worked.
> I had the first message and when I tried later and I only had a simple
> warning about autoconf version and every other step where passed
> successfully.
>
> I installed every dependencies, any idea how to solve this ?
>
> thanks
>

[Turnserver-devel] Compilation issues on debian squeeze

[Sébastien G. <sgi...@gm...>]

I try to compile TurnServer on a Debian Squeeze 6.0 on a 64bit architecture

But I got the following error when typing autoreconf -i command

configure.in:10: error: possibly undefined macro: AC_MSG_RESULT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1


Typing the command a second time do not show the message again but next I
got the following error typing ./configure command

./configure: line 2418: syntax error near unexpected token `CHECK,'
./configure: line 2418: `PKG_CHECK_MODULES(CHECK, check >=
0.9.4,,AC_MSG_RESULT([testing is disabled]))'

I tried the same thing on a Debian Squeeze VirtualBox VMs in 32bits and it
worked.
I had the first message and when I tried later and I only had a simple
warning about autoconf version and every other step where passed
successfully.

I installed every dependencies, any idea how to solve this ?

thanks

Re: [Turnserver-devel] Unencrypted data on TLS connection

[Sebastien V. <se...@ji...>]

Hi Thomas,

Do you use TURN-TCP ?

When TLS is used, only for the control connection is using TLS (i.e. 
between client and server). Data from server to external peer is not 
secured (by the server). With TURN-UDP data (channel or data indication) 
go through the way the client connect to the server (UDP, TCP or TLS).

When using TURN-TCP, you can only obtain TCP-based allocation address 
(and not TLS) so data received on the data connections is not encrypted. 
TLS is just here to "secure" the allocation process.

 From TURN-TCP:
    In order to actually send data on the new connection or otherwise
    utilize it in any way, the client establishes a new TCP connection to
    its TURN server.  Once established, it issues a ConnectionBind
    request to the server over this new connection.  That request echoes
    back the connection identifier to the TURN server.  The TURN server
    uses it to correlate the two connections.  As a consequence, the TCP
    connection to the peer is associated with a TCP connection to the
    client one-to-one.  The two connections are now data connections.  At
    this point, if the server receives data from the peer, it forwards
    that data towards the client, without any kind of encapsulation.  Any
    data received by the TURN server from the client over the client data
    connection is forwarded to the peer, again without encapsulation or
    framing of any kind.  Once a connection has been bound using the
    ConnectionBind request, TURN messaging is no longer permitted on the
    connection.



Regards,
--
Seb

Le 04/06/12 17:26, Thomas Milligan a écrit :
>
> Hello
>
> AS a TLS client, I can establish the control and data connections, but 
> once I have securely bound to the peer on the data connection, I 
> receive data from the peer that is not encrypted.  This causes TLS to 
> immediately terminate the connection.
>
> Should the TurnServer be sending non-encryped data on a secure connection?
>
> thanks
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

[Turnserver-devel] Unencrypted data on TLS connection

[Thomas M. <tmi...@co...>]

Hello

AS a TLS client, I can establish the control and data connections, but once I have securely bound to the peer on the data connection, I receive data from the peer that is not encrypted.  This causes TLS to immediately terminate the connection.

Should the TurnServer be sending non-encryped data on a secure connection?

thanks

Re: [Turnserver-devel] Server Corrupting Pointer?

[Erik L. <er...@ho...>]

Thanks Ryo,

Corrupting error was ours, but we fixed an unrelated bug wrt to verifying auth on send indications, passed it along to Sebastien, hopefully it will make it into the next update.

Regards,
Erik

On 2012-05-31, at 12:44 AM, Ryo Sato <sat...@gm...> wrote:

> Hello,
> 
> I think that it is fixed with this patch. 
> Please use. 
> 
> diff -acr turnserver-0.6/src/protocol.c turnserver-0.6fix/src/protocol.c
> *** turnserver-0.6/src/protocol.c       2011-11-02 23:22:13.000000000 +0900
> --- turnserver-0.6fix/src/protocol.c    2012-04-05 19:07:47.000000000 +0900
> ***************
> *** 563,569 ****
>    }
> 
>    ret->turn_attr_type = htons(STUN_ATTR_UNKNOWN_ATTRIBUTES);
> !   ret->turn_attr_len = htons(attr_size);
> 
>    ptr = (uint16_t*)ret->turn_attr_attributes;
>    tmp_len = len;
> --- 563,569 ----
>    }
> 
>    ret->turn_attr_type = htons(STUN_ATTR_UNKNOWN_ATTRIBUTES);
> !   ret->turn_attr_len = htons(attr_size * 2);
> 
>    ptr = (uint16_t*)ret->turn_attr_attributes;
>    tmp_len = len;
> diff -acr turnserver-0.6/src/turnserver.c turnserver-0.6fix/src/turnserver.c
> *** turnserver-0.6/src/turnserver.c     2012-01-17 02:36:31.000000000 +0900
> --- turnserver-0.6fix/src/turnserver.c  2012-04-27 16:24:46.000000000 +0900
> ***************
> *** 2988,2997 ****
>          desc = NULL;
>        }
>      }
> -     else
> -     {
> -       desc = NULL;
> -     }
> 
>      if(!desc)
>      {
> --- 2988,2993 ----
> 
> -- 
> Ryo Sato <sat...@gm...>
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

Re: [Turnserver-devel] Server Corrupting Pointer?

[Ryo S. <sat...@gm...>]

Hello,

I think that it is fixed with this patch. 
Please use. 

diff -acr turnserver-0.6/src/protocol.c turnserver-0.6fix/src/protocol.c
*** turnserver-0.6/src/protocol.c       2011-11-02 23:22:13.000000000 +0900
--- turnserver-0.6fix/src/protocol.c    2012-04-05 19:07:47.000000000 +0900
***************
*** 563,569 ****
    }

    ret->turn_attr_type = htons(STUN_ATTR_UNKNOWN_ATTRIBUTES);
!   ret->turn_attr_len = htons(attr_size);

    ptr = (uint16_t*)ret->turn_attr_attributes;
    tmp_len = len;
--- 563,569 ----
    }

    ret->turn_attr_type = htons(STUN_ATTR_UNKNOWN_ATTRIBUTES);
!   ret->turn_attr_len = htons(attr_size * 2);

    ptr = (uint16_t*)ret->turn_attr_attributes;
    tmp_len = len;
diff -acr turnserver-0.6/src/turnserver.c turnserver-0.6fix/src/turnserver.c
*** turnserver-0.6/src/turnserver.c     2012-01-17 02:36:31.000000000 +0900
--- turnserver-0.6fix/src/turnserver.c  2012-04-27 16:24:46.000000000 +0900
***************
*** 2988,2997 ****
          desc = NULL;
        }
      }
-     else
-     {
-       desc = NULL;
-     }

      if(!desc)
      {
--- 2988,2993 ----

-- 
Ryo Sato <sat...@gm...>

Re: [Turnserver-devel] Server Corrupting Pointer?

[Erik L. <er...@ho...>]

more..
--
Forgot to include the server output from that code:
04:26:32.351486 [turnserver.c:4785]    Source is 173.192.183.147
04:26:32.351620 [turnserver.c:4786]    Destination is 10.215.91.89
04:26:32.351744 [turnserver.c:4787]    Destination is 2805670640
04:26:32.351870 [turnserver.c:3688]    Source is 255.127.0.0
04:26:32.352009 [turnserver.c:3689]    Destination (2) is 255.127.0.0
04:26:32.352133 [turnserver.c:3690]    Destination (2) is 2805671072

The first two IPs are valid, the second two are obviously not... but again, I'm tired so maybe my debug output is wrong, except that:
04:28:23.784043 [turnserver.c:3697]    No allocation found

is the reason I went to look there in the first place...

Robin


On 2012-05-30, at 9:34 PM, Erik Lagerway <er...@ho...> wrote:

> Sending this on behalf of my senior engineer, hopefully someone can shed some light on this.
> 
> /Erik
> 
> --
> I think I've found a bug, but I'm trying to verify it because what I have as a client can't communicate to the server. Upon debugging the server I discovered a few issues:
> 
> inside turnserver_process_turn:
> 
> 
>   if(!(STUN_IS_REQUEST(hdr_msg_type) && method == TURN_METHOD_ALLOCATE))
> 
> 
> If you send a 'send method' 'indication class' without a username / password the server is checking for a username and password anyway because the logic check isn't quite right.
> 
> The RFC specifically states the send indication doesn't include credentials:
> 
>    Send and Data indications cannot be authenticated, since the long-
>    term credential mechanism of STUN does not support authenticating
>    indications.  This is not as big an issue as it might first appear,
>    since the client-to-server leg is only half of the total path to the
>    peer.  Applications that want proper security should encrypt the data
>    sent between the client and a peer.
> 
>    Because Send indications are not authenticated, it is possible for an
>    attacker to send bogus Send indications to the server, which will
>    then relay these to a peer.  To partly mitigate this attack, TURN
>    requires that the client install a permission towards a peer before
>    sending data to it using a Send indication.
>  
> I discovered it doesn't work right when testing with my own client.
> 
> Another issue I have is:
> 
> char bigbuffer[256];
> 
>             debug(DBG_ATTR, "Source is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&saddr)->sin_addr), &(bigbuffer[0]), saddr_size));
>             debug(DBG_ATTR, "Destination is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&daddr)->sin_addr), &(bigbuffer[0]), saddr_size));
>             debug(DBG_ATTR, "Destination is %u\n", ((unsigned long)(&daddr)));
> 
>             turnserver_relayed_recv(buf, nb, (struct sockaddr*)&saddr, &daddr, saddr_size, allocation_list, speer);
> 
> put in the first part of the code inside turnserver_relayed_recv:
>  
>   debug(DBG_ATTR, "Source (2) is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&saddr)->sin_addr), &(bigbuffer[0]), saddr_size));
>   debug(DBG_ATTR, "Destination (2) is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&daddr)->sin_addr), &(bigbuffer[0]), saddr_size));
>   debug(DBG_ATTR, "Destination (2) is %u\n", ((unsigned long)(&daddr)));
> 
> after the call the "dest" those address values change... but maybe i'm just tired out and doing something wrong... typo can cause anything to happen..
> 
> The value "saddr/daddr" is proper before calling the method but then corrupted. Strangest thing...
> 
> -Robin

[Turnserver-devel] Server Corrupting Pointer?

[Erik L. <er...@ho...>]

Sending this on behalf of my senior engineer, hopefully someone can shed some light on this.

/Erik

--
I think I've found a bug, but I'm trying to verify it because what I have as a client can't communicate to the server. Upon debugging the server I discovered a few issues:

inside turnserver_process_turn:


  if(!(STUN_IS_REQUEST(hdr_msg_type) && method == TURN_METHOD_ALLOCATE))


If you send a 'send method' 'indication class' without a username / password the server is checking for a username and password anyway because the logic check isn't quite right.

The RFC specifically states the send indication doesn't include credentials:

   Send and Data indications cannot be authenticated, since the long-
   term credential mechanism of STUN does not support authenticating
   indications.  This is not as big an issue as it might first appear,
   since the client-to-server leg is only half of the total path to the
   peer.  Applications that want proper security should encrypt the data
   sent between the client and a peer.

   Because Send indications are not authenticated, it is possible for an
   attacker to send bogus Send indications to the server, which will
   then relay these to a peer.  To partly mitigate this attack, TURN
   requires that the client install a permission towards a peer before
   sending data to it using a Send indication.
 
I discovered it doesn't work right when testing with my own client.

Another issue I have is:

char bigbuffer[256];

            debug(DBG_ATTR, "Source is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&saddr)->sin_addr), &(bigbuffer[0]), saddr_size));
            debug(DBG_ATTR, "Destination is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&daddr)->sin_addr), &(bigbuffer[0]), saddr_size));
            debug(DBG_ATTR, "Destination is %u\n", ((unsigned long)(&daddr)));

            turnserver_relayed_recv(buf, nb, (struct sockaddr*)&saddr, &daddr, saddr_size, allocation_list, speer);

put in the first part of the code inside turnserver_relayed_recv:
 
  debug(DBG_ATTR, "Source (2) is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&saddr)->sin_addr), &(bigbuffer[0]), saddr_size));
  debug(DBG_ATTR, "Destination (2) is %s\n", inet_ntop(AF_INET, &(((struct sockaddr_in *)&daddr)->sin_addr), &(bigbuffer[0]), saddr_size));
  debug(DBG_ATTR, "Destination (2) is %u\n", ((unsigned long)(&daddr)));

after the call the "dest" those address values change... but maybe i'm just tired out and doing something wrong... typo can cause anything to happen..

The value "saddr/daddr" is proper before calling the method but then corrupted. Strangest thing...

-Robin

Re: [Turnserver-devel] turnserver without authentication

[Sebastien V. <se...@ji...>]

Hi,

Unfortunaly not. Autentication is mandatory in TURN RFC. FYI I don't think
that flash supports latest TURN RFC5766 so it will not work even without
authentication.

Regards,
--
Seb

Le jeudi 5 avril 2012, sebastian <seb...@gm...> a écrit :
> Hello,
>
> Is it possible to disable authentication in turnserver 0.6?
>
> Flash clients do not support authentication.
>
> Greetings,
> -sebastian
>
>
------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel
>

[Turnserver-devel] turnserver without authentication

[sebastian <seb...@gm...>]

Hello,

Is it possible to disable authentication in turnserver 0.6?

Flash clients do not support authentication.

Greetings,
-sebastian

Re: [Turnserver-devel] Debian package

[sebastian <seb...@gm...>]

Ok, I figured out which files need to be included (right after posting
to the mailing list):

$ ./configure --prefix /usr/ >/dev/null
$ make >/dev/null
$ make DESTDIR=/tmp/inst install
$ ls -R /tmp/inst
/tmp/inst/usr/bin:
test_echo_server
test_turn_client
turnserver

/tmp/inst/usr/share/man/man1:
turnserver.1

/tmp/inst/usr/share/man/man5:
turnserver.conf.5

dependencies:
$ grep '\-l' Makefile
LIBS = -lconfuse -lcrypto -lssl -lrt

so the dependencies are
* libconfuse-dev
* libssl-dev (providing crypto and ssl)
* libc6-dev (prodivind librt)

would that be all required for building a debian package?

greetings,
-sebastian




On Wed, Apr 4, 2012 at 12:56 AM, sebastian <seb...@gm...> wrote:
> Hi,
>
> I'm looking at turnserver for a project and am going to build a Debian
> (binary) package. As it happend, a Debian package is something you
> have on the roadmap for a future release.
>
> binaries: after building turnserver and checking the results I figure
> that src/turnserver and man/*.man must be included into the Debian
> package. Anything else that I might have overlooked?
>
> dependencies: i had to install libssl-dev and libconfuse-dev on Debian
> before being able to ./configure turnserver. Any other dependencies?
>
> Greetings,
> -sebastian

[Turnserver-devel] Debian package

[sebastian <seb...@gm...>]

Hi,

I'm looking at turnserver for a project and am going to build a Debian
(binary) package. As it happend, a Debian package is something you
have on the roadmap for a future release.

binaries: after building turnserver and checking the results I figure
that src/turnserver and man/*.man must be included into the Debian
package. Anything else that I might have overlooked?

dependencies: i had to install libssl-dev and libconfuse-dev on Debian
before being able to ./configure turnserver. Any other dependencies?

Greetings,
-sebastian

Re: [Turnserver-devel] Turnserver Performance Testing...

[Sebastien V. <se...@ji...>]

Hi Bill,

Le 19/03/12 20:55, Bill Clark a écrit :
>
> Sebastien,
>
> We managed to load Turnserver with 2K simultaneous connections pushing 
> 4K bytes per second at 85% CPU (single core as Turnserver is single 
> threaded).  Once we crossed 2.5K connections, Turnserver utilized 100% 
> CPU with a load average of 1.6 (in other words 160% CPU).  We pushed 
> number of connections to 3.5K at which point connections stated dropping.
>
> From our initial performance testing, it appears Turnserver is CPU 
> bound and cannot take full advantage of system resources.
>
> Questions:
>
> 1)Are there any plans to make Turnserver multi-threaded?
>

We think about it.

> 2)If so, what is the ETA of a multi-threaded release?
>

We cannot tell you a date yet. We need to analyze and propose a design 
to estimate time of effort to make TurnServer multi-threaded.

Regards,
--
Seb

> Regards,
>
> Bill Clark
>
> *From:*Bill Clark [mailto:bc...@co...]
> *Sent:* Monday, March 19, 2012 10:22 AM
> *To:* tur...@li...
> *Subject:* Re: [Turnserver-devel] Turnserver Performance Testing...
>
> Recompiling with switch '--enable-fdsetsize=65535' allows us to get 
> past the 203 simultaneous connection limit.
>
> Once we formulate our findings, we'll post to group.
>
> Regards,
>
> Bill Clark
>
> *From:*Bill Clark [mailto:bc...@co...]
> *Sent:* Monday, March 19, 2012 9:12 AM
> *To:* tur...@li... 
> <mailto:tur...@li...>
> *Subject:* Re: [Turnserver-devel] Turnserver Performance Testing...
>
> Resending without attachment to avoid message size limits and 
> requiring moderator approval.
>
> *From:*Bill Clark [mailto:bc...@co...]
> *Sent:* Friday, March 16, 2012 12:20 PM
> *To:* tur...@li... 
> <mailto:tur...@li...>
> *Subject:* [Turnserver-devel] Turnserver Performance Testing...
>
> Hi Sebastien,
>
> We're hitting a wall of 203 simultaneous connections on the 
> turnserver.  Could you please provide any server-level or turnserver 
> configuration that would increase this number?
>
> Attached is a netstat capture (netstat --aptn | grep turn) of all 
> sockets open on turnserver.
>
> We're stressing the Turnserver using a modified test_turn_client and 
> netcat as the peer.  The test_turn_client simply allocates, sets 
> permissions and waits for peer to send data.  Once test_turn_client is 
> notified of connection attempt, it binds and echoes data back to peer.
>
> We've increased the number of 'open file' handles to 65535 for all 
> users in /etc/security/limits.conf and ensured value persists across 
> reboots using 'ulimit --a'
>
> Setup:
>
> 1)Configuration
>
> a.Range of allowable sockets increased 40K
>
> i.max_port = 65535
>
> ii.min_port = 25535
>
> b.turn_tcp = true
>
> c.using user file for authentication
>
> 2)User file contains 40K users (ex user1, user2, ..., user40000) with 
> appropriate password, domain and authorized syntax.
>
> Execution:
>
> 1)All clients (aka test_turn_client) processes execute on own server 
> (IP 10.11.205.2)
>
> 2)All peers (aka netcast) execute on own server (IP 10.11.205.4)
>
> 3)Turnserver is running on own server (IP 10.11.205.5)
>
> Any help on this matter would be greatly appreciated.
>
> Regards,
>
> Bill Clark
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

Re: [Turnserver-devel] Turnserver Performance Testing...

[Bill C. <bc...@co...>]

Sebastien,

We managed to load Turnserver with 2K simultaneous connections pushing 4K bytes per second at 85% CPU (single core as Turnserver is single threaded).  Once we crossed 2.5K connections, Turnserver utilized 100% CPU with a load average of 1.6 (in other words 160% CPU).  We pushed number of connections to 3.5K at which point connections stated dropping.

From our initial performance testing, it appears Turnserver is CPU bound and cannot take full advantage of system resources.

Questions:

1)      Are there any plans to make Turnserver multi-threaded?

2)      If so, what is the ETA of a multi-threaded release?

Regards,
Bill Clark


From: Bill Clark [mailto:bc...@co...]
Sent: Monday, March 19, 2012 10:22 AM
To: tur...@li...
Subject: Re: [Turnserver-devel] Turnserver Performance Testing...

Recompiling with switch '--enable-fdsetsize=65535' allows us to get past the 203 simultaneous connection limit.

Once we formulate our findings, we'll post to group.

Regards,
Bill Clark


From: Bill Clark [mailto:bc...@co...]
Sent: Monday, March 19, 2012 9:12 AM
To: tur...@li...<mailto:tur...@li...>
Subject: Re: [Turnserver-devel] Turnserver Performance Testing...

Resending without attachment to avoid message size limits and requiring moderator approval.

From: Bill Clark [mailto:bc...@co...]
Sent: Friday, March 16, 2012 12:20 PM
To: tur...@li...<mailto:tur...@li...>
Subject: [Turnserver-devel] Turnserver Performance Testing...

Hi Sebastien,

We're hitting a wall of 203 simultaneous connections on the turnserver.  Could you please provide any server-level or turnserver configuration that would increase this number?

Attached is a netstat capture (netstat -aptn | grep turn) of all sockets open on turnserver.

We're stressing the Turnserver using a modified test_turn_client and netcat as the peer.  The test_turn_client simply allocates, sets permissions and waits for peer to send data.  Once test_turn_client is notified of connection attempt, it binds and echoes data back to peer.

We've increased the number of 'open file' handles to 65535 for all users in /etc/security/limits.conf and ensured value persists across reboots using 'ulimit -a'

Setup:

1)      Configuration

a.       Range of allowable sockets increased 40K

                                                               i.      max_port = 65535

                                                             ii.      min_port = 25535

b.      turn_tcp = true

c.       using user file for authentication

2)      User file contains 40K users (ex user1, user2, ..., user40000) with appropriate password, domain and authorized syntax.

Execution:

1)      All clients (aka test_turn_client) processes execute on own server (IP 10.11.205.2)

2)      All peers (aka netcast) execute on own server (IP 10.11.205.4)

3)      Turnserver is running on own server (IP 10.11.205.5)

Any help on this matter would be greatly appreciated.

Regards,
Bill Clark

Re: [Turnserver-devel] Turnserver Performance Testing...

[Bill C. <bc...@co...>]

Recompiling with switch '--enable-fdsetsize=65535' allows us to get past the 203 simultaneous connection limit.

Once we formulate our findings, we'll post to group.

Regards,
Bill Clark


From: Bill Clark [mailto:bc...@co...]
Sent: Monday, March 19, 2012 9:12 AM
To: tur...@li...
Subject: Re: [Turnserver-devel] Turnserver Performance Testing...

Resending without attachment to avoid message size limits and requiring moderator approval.

From: Bill Clark [mailto:bc...@co...]
Sent: Friday, March 16, 2012 12:20 PM
To: tur...@li...<mailto:tur...@li...>
Subject: [Turnserver-devel] Turnserver Performance Testing...

Hi Sebastien,

We're hitting a wall of 203 simultaneous connections on the turnserver.  Could you please provide any server-level or turnserver configuration that would increase this number?

Attached is a netstat capture (netstat -aptn | grep turn) of all sockets open on turnserver.

We're stressing the Turnserver using a modified test_turn_client and netcat as the peer.  The test_turn_client simply allocates, sets permissions and waits for peer to send data.  Once test_turn_client is notified of connection attempt, it binds and echoes data back to peer.

We've increased the number of 'open file' handles to 65535 for all users in /etc/security/limits.conf and ensured value persists across reboots using 'ulimit -a'

Setup:

1)      Configuration

a.       Range of allowable sockets increased 40K

                                                               i.      max_port = 65535

                                                             ii.      min_port = 25535

b.      turn_tcp = true

c.       using user file for authentication

2)      User file contains 40K users (ex user1, user2, ..., user40000) with appropriate password, domain and authorized syntax.

Execution:

1)      All clients (aka test_turn_client) processes execute on own server (IP 10.11.205.2)

2)      All peers (aka netcast) execute on own server (IP 10.11.205.4)

3)      Turnserver is running on own server (IP 10.11.205.5)

Any help on this matter would be greatly appreciated.

Regards,
Bill Clark

Re: [Turnserver-devel] Turnserver Performance Testing...

[Bill C. <bc...@co...>]

Resending without attachment to avoid message size limits and requiring moderator approval.

From: Bill Clark [mailto:bc...@co...]
Sent: Friday, March 16, 2012 12:20 PM
To: tur...@li...
Subject: [Turnserver-devel] Turnserver Performance Testing...

Hi Sebastien,

We're hitting a wall of 203 simultaneous connections on the turnserver.  Could you please provide any server-level or turnserver configuration that would increase this number?

Attached is a netstat capture (netstat -aptn | grep turn) of all sockets open on turnserver.

We're stressing the Turnserver using a modified test_turn_client and netcat as the peer.  The test_turn_client simply allocates, sets permissions and waits for peer to send data.  Once test_turn_client is notified of connection attempt, it binds and echoes data back to peer.

We've increased the number of 'open file' handles to 65535 for all users in /etc/security/limits.conf and ensured value persists across reboots using 'ulimit -a'

Setup:

1)      Configuration

a.       Range of allowable sockets increased 40K

                                                               i.      max_port = 65535

                                                             ii.      min_port = 25535

b.      turn_tcp = true

c.       using user file for authentication

2)      User file contains 40K users (ex user1, user2, ..., user40000) with appropriate password, domain and authorized syntax.

Execution:

1)      All clients (aka test_turn_client) processes execute on own server (IP 10.11.205.2)

2)      All peers (aka netcast) execute on own server (IP 10.11.205.4)

3)      Turnserver is running on own server (IP 10.11.205.5)

Any help on this matter would be greatly appreciated.

Regards,
Bill Clark

[Turnserver-devel] TurnServer 0.6 release

[Sebastien V. <seb...@tu...>]

Hi all,

TurnServer version 0.6 is released. It is mainly a bug fixes release.

Best regards,
--
Sebastien Vincent

Re: [Turnserver-devel] bug in allocate response?

[Sebastien V. <se...@ji...>]

Hi,

If the client has not send its USERNAME/REALM attribute in message, 
server cannot determine which couple of user/password it has to compute 
MESSAGE-INTEGRITY.

Can you send us pcap trace so that we can better analyze ?

Regards
--
Seb

Le 10/02/12 17:58, sthustfo a écrit :
>
> There was a typo in there in the first sentence... I meant 
> MESSAGE-INTEGRITY attribute and not fingerprint.
>
>
> On Fri, Feb 10, 2012 at 10:27 PM, sthustfo <sth...@gm... 
> <mailto:sth...@gm...>> wrote:
>
>     Hi Seb,
>
>     I am using turnserver-0.5 and seeing that the 401 response to
>     allocate request does not have the fingerprint attribute. This
>     might be the case with other responses as well, but I have not
>     checked.
>
>     But RFC 5389 sec 10.2.3 mentions that
>
>     The client looks for the MESSAGE-INTEGRITY attribute in the
>     response (either
>     success or failure). If present, the client computes the message
>     integrity over
>     the response as defined in Section 15.4, using the same password
>     it utilized for
>     the request. If the resulting value matches the contents of the
>     MESSAGE-
>     INTEGRITY attribute, the response is considered authenticated.
>     RFC4250 If the
>     value does not match, or if MESSAGE-INTEGRITY was absent, the
>     response MUST be
>     discarded, as if it was never received. This means that
>     retransmits, if
>     applicable, will continue.
>
>     So as per the above statement, the stun/ice client might just
>     discard the 401 response and wait for the proper 401 response for
>     ever. Looking at the security perspective as well, I think adding
>     the message-integrity attribute makes sense even when sending
>     error response messages.
>
>     Let me know what you think.
>
>     Thanks,
>     sthustfo
>
>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Turnserver-devel mailing list
> Tur...@li...
> https://lists.sourceforge.net/lists/listinfo/turnserver-devel

Re: [Turnserver-devel] bug in allocate response?

[sthustfo <sth...@gm...>]

There was a typo in there in the first sentence... I meant
MESSAGE-INTEGRITY attribute and not fingerprint.


On Fri, Feb 10, 2012 at 10:27 PM, sthustfo <sth...@gm...> wrote:

> Hi Seb,
>
> I am using turnserver-0.5 and seeing that the 401 response to allocate
> request does not have the fingerprint attribute. This might be the case
> with other responses as well, but I have not checked.
>
> But RFC 5389 sec 10.2.3 mentions that
>
> The client looks for the MESSAGE-INTEGRITY attribute in the response
> (either
> success or failure). If present, the client computes the message integrity
> over
> the response as defined in Section 15.4, using the same password it
> utilized for
> the request. If the resulting value matches the contents of the MESSAGE-
> INTEGRITY attribute, the response is considered authenticated. RFC4250 If
> the
> value does not match, or if MESSAGE-INTEGRITY was absent, the response
> MUST be
> discarded, as if it was never received. This means that retransmits, if
> applicable, will continue.
>
> So as per the above statement, the stun/ice client might just discard the
> 401 response and wait for the proper 401 response for ever. Looking at the
> security perspective as well, I think adding the message-integrity
> attribute makes sense even when sending error response messages.
>
> Let me know what you think.
>
> Thanks,
> sthustfo
>
>
>