TLS with TURN server - sockets

I'm using TURN server and I want to use TLS when authenticating with TURN server but turn it off when it starts acting as relay server. how is this possible? it gives "connection reset" error as soon as I start transmitting unencrypted text
Thanks

Related

How Postgres negotiate TLS usage?

I am puzzled a bit about Postgres option sslmode=prefer. It implies that it negotiates with the server to figure out whether the server supports TLS or not.
I am curious how it's done. Does it try TLS first and if it fails, try without TLS or am I missing something in TLS (or Postgres) which allow them to truly negotiate this?
Does it try TLS first and if it fails, try without TLS
Yes. And when both attempts fail, this might be visible, as two different error messages might be produced.
Some additional info on top of #janes answer:
https://www.postgresql.org/docs/current/protocol-flow.html
To initiate an SSL-encrypted connection, the frontend initially sends
an SSLRequest message rather than a StartupMessage. The server then
responds with a single byte containing S or N, indicating that it is
willing or unwilling to perform SSL, respectively. The frontend might
close the connection at this point if it is dissatisfied with the
response. To continue after S, perform an SSL startup handshake (not
described here, part of the SSL specification) with the server. If
this is successful, continue with sending the usual StartupMessage. In
this case the StartupMessage and all subsequent data will be
SSL-encrypted. To continue after N, send the usual StartupMessage and
proceed without encryption.

A6 gsm/gprs module TCP/IP connection to Cloud

I want to send data with A6 GSM/GPRS module to data.sparkfun.com cloud service. I am using these AT commands:
// Setting up network
AT+CGATT?
AT+CGATT=1
AT+CGDCONT=1,"IP","internet"
AT+CGACT=1,1
AT+CIPSTATUS
AT+CIFSR
// Start the TCP/IP connection to the server
AT+CIPSTART="TCP","54.86.132.254",80 // PROBLEM STARTS HERE
AT+CIPSTATUS
AT+CIPSEND
GET /input/***********?private_key=****************&temp=45.2 HTTP/1.1<cr><lf>Host:data.sparkfun.com<cr><lf>Connection:keep-alive<cr><lf>
^z
When I enter this command AT+CIPSTART="TCP","data.sparkfun.com",80 I will get back CONNECT OK(TCP connection success) and just after that it will automatically close it +TCPCLOSED:0(TCP connection is closed by remote server). There is no time to enter the AT+CIPSEND command because the TCP connection is lost.
I tried to make my own nodejs server but still the same problem.
How to keep the connection alive until I can send data and then close the connection with AT+CIPCLOSE command?
Most probably the solution is very simple.
The AT-Command
AT+CGDCONT=1,"IP","internet"
defines the PDP context and I guess the "internet" was just a generic value and you might have to replace it by the APN of your mobile network provider.

Testing RADSEC with FreeRadius

I'm new to RADIUS, servers, and the like. There doesn't seem to be that much documentation on FreeRadius, and I need to get FreeRadius server (3.0.8) running RADSEC for test purposes.
I moved etc/raddb/sites-available/tls to etc/raddb/sites-enabled/ in order to enable "RADSEC".
Questions:
I understand that I need to have a server certificate as well as a public key. I am wondering on if I could get a fake certificate/key just for testing.
Also I'm not sure how I can test the actual server, there's the radtest command (I've been trying to run radtest -P tcp -x testing password 127.0.0.1:2083 10 testing123 but it's returns:
... new connection request on TCP socket
Listening on auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Waking up in 0.4 seconds.
(0) Initiating new EAP-TLS session
(0) Setting verify mode to require certificate from client
(0) Non-TLS data sent to TLS socket: closing
Closing TLS socket from client port 40542
Client has closed connection
... shutting down socket auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Waking up in 2.9 seconds.
... cleaning up socket auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Ready to process requests
Do I need to set up another server as a client so that they can perform the TLS negotiation? And once I do that, how do I get that server to communicate with this RADSEC server?
radtest is attempting a non TLS connect to the server. And thats the reason you are seeing that the server disconnects the connection immediately.
You can explore radsecproxy. It supports TLS (RadSec), as well as RADIUS over TCP. So it can happen as intermediary for the non TLS client and TLS server.

Stunnel doesn't accept client reconnection

I am using Stunnel to connect to a server with TLS encryption. I start Stunnel, then I use any client to connect to Stunnel (e.g. telnet) and everything works fine.
If I close the client the connection with the server remains active, the connection with the client goes to state TIME_WAIT.
But here is the problem, if I try to open the client again, the connection to Stunnel is lost instantaneously.
What can be the problem?
It was a problem with the server not accepting TSL handsake renegotiation, a feature that comes by default with Stunnel and cannot be changed via configuration.
So I had to modify the source code of stunnel to force it to make the handshake each time the connection is established.

TLS Socket connection through Nodejs

Im trying to establish a TLS socket connection to chat.facebook.com port:5222 through Nodejs.
Im using the following code :
var a=require('tls');
var b=a.connect(5222,'chat.facebook.com',function(){console.log("connected");});
b.on('error',function(error){console.log(error);})
But it is not getting connected and instead giving an error :
[Error: 140089045411648:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:683:]
I have tried a similiar connection to encrypted.google.com:443 and console readily fired a "connected" .
Can someone guide me what i have been missing or what can be done to overcome this problem.
xmpp with tls uses "STARTTLS", a protocol upgrade from plaintext to encrypted. See http://xmpp.org/rfcs/rfc6120.html#tls for details.
(It means you have to send some unencrypted xml stuff first, and wait for the other end to confirm your choice to upgrade to TLS)