reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] TLS Handshake failure on debian 8

The first output was just the informations provided by the tool (https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) ;
Not 100% sure neither what it confirms, but just to say the first test indicates a « done » status,
(which I can reproduce with any other working STUN / TURN server)
And the second one a « not reachable? » one.



The test client you have never seen is just a screenshot of my browser (Google Chrome),
When I browse to https://turn.my-domain.com.
I do not have a web application running behind, but just an « empty » nginx instance, to check the validity of the certificate.

So I assume the same thing…
I am quite sure the certificate is valid.


I missed the point of it actually, I ran it on my personnal computer (client)…
I’ll check how to run it on CLI on my VPS.

Is there any alternative way to get more precise informations about the TLS handshake ?
No chance you could know what this « wrong version number » error could mean?


Thanks again,

Florent Schildknecht
UX-designer et développeur web auto-entrepreneur
+33 6 78 41 74 79 (France)
+46 7 64 15 32 64 (Sweden)

On 30 Jan 2017, at 20:52, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

...inline...

On Mon, Jan 30, 2017 at 12:14 PM, Florent SCHILDKNECHT <florent.schildknecht@xxxxxxxxx> wrote:
Hey Scott,


Thanks for your reply,
I’ll try to answer as best as I can.

Not sure if it matters, but I am wish to use this TURN server as a relay for a WebRTC application.
I already have working JS clients and a signaling server.

To test my turn server, I use this tool :

I first set the 3478, unencrypted address, then I try using the port 5349, which is my TlsTurnPort.

First test (port 3478, seems to work) :

URL : turn:turn.my-domain.com:3478
username : test
credential : « my-hashed-password »

Time        Component   Type        Foundation   Protocol     Address         Port     Priority
0.002       1           host         1026183099   udp         My_Local_IP     51014   126 | 32542 | 255
0.002       2           host         1026183099   udp         My_Local_IP     59034   126 | 32542 | 254
0.044       1           srflx       3160557839   udp         My_Public_IP     34652   100 | 32542 | 255
0.049       2           srflx       3160557839   udp         My_Public_IP     34653   100 | 32542 | 254
0.102        1           host         1940501323   tcp         My_Local_IP     9       90 | 32542 | 255
0.102        2           host         1940501323   tcp         My_Local_IP     9       90 | 32542 | 254
0.165        1           relay       4193894297   udp         My_Server_IP         49156   2 | 32542 | 255
0.168        2           relay       4193894297   udp         My_Server_IP         49157   2 | 32542 | 254
0.169                                                                               Done

[Scott]  I don't understand what this output is.  Is this tracerte output from your client? 
 
Second test (port 5349) :

URL : turn:turn.my-domain.com:5349
username : test
credential : « my-hashed-password »

Time     Component   Type    Foundation   Protocol     Address Port    Priority
0.002   1   host    1026183099   udp My_Local_IP    58981           126 | 32542 | 255
0.002   2   host    1026183099   udp My_Local_IP    58354           126 | 32542 | 254
0.103   1   host    1940501323   tcp My_Local_IP    9               90 | 32542 | 255
0.103   2   host    1940501323   tcp My_Local_IP    9               90 | 32542 | 254
9.560                                                               Not reachable?


1. I’ve set the logger level to DEBUG in the reTurnServer.config file.

Now, I have those logs :

## Server start

INFO | 20170130-171540.513 | reTurnServer | RETURN | 140023855642432 | UdpServer.cxx:30 | UdpServer started.  Listening on X.X.X.X:3478
INFO | 20170130-171540.513 | reTurnServer | RETURN | 140023855642432 | TcpServer.cxx:35 | TcpServer started.  Listening on X.X.X.X:3478
INFO | 20170130-171540.515 | reTurnServer | RETURN | 140023855642432 | TlsServer.cxx:73 | TlsServer started.  Listening on X.X.X.X:5349
INFO | 20170130-171540.515 | reTurnServer | RETURN | 140023855642432 | UdpServer.cxx:30 | UdpServer started.  Listening on Y:Y:Y:Y:Y:Y:3478
INFO | 20170130-171540.515 | reTurnServer | RETURN | 140023855642432 | TcpServer.cxx:35 | TcpServer started.  Listening on Y:Y:Y:Y:Y:Y:3478
INFO | 20170130-171540.516 | reTurnServer | RETURN | 140023855642432 | TlsServer.cxx:73 | TlsServer started.  Listening on Y:Y:Y:Y:Y:Y:5349

## When I try to connect my webrtc

DEBUG | 20170130-173043.614 | reTurnServer | RETURN | 140023809464064 | TlsConnection.cxx:44 | TlsConnection started.
WARNING | 20170130-173047.462 | reTurnServer | RETURN | 140023809464064 | TlsConnection.cxx:80 | TlsConnection handshake failure, error=336130315-wrong version number
DEBUG | 20170130-173047.462 | reTurnServer | RETURN | 140023809464064 | TlsConnection.cxx:32 | TlsConnection destroyed.

The openssl version I am using is :
OpenSSL 1.0.1t  3 May 2016

[Scott]  Interestingly enough the error in this log is different than what you previously posted.  This shows "wrong version", previous error was "short read".  Not sure what that means at this point.  So I'm assuming there was no errors about reading or parsing your certificate files?

2. Not exactly sure of what you mean by « installed » ;
I am using letsencrypt, so unless I really get something wrong,
The root CA is the one of LetsEncrypt, which usually does not need any installation ?

Here is a screen of the certificate when I access the domain on port 443 (Using nginx, no web-application of any kind on this domain though)

<certificate-screen.jpeg>


(Which means the certificate is valid... Right?)

[Scott]  I have never used that test client, so I'm not familiar with it.  However is appears to be a browser base app, so I would assume if the browser is happy with the root CA, then you will be good, but I can't say for sure.  The bottom line is that the client needs to trust the certificate that the server presents.  I think the wireshark trace will help confirm here.

3. I really think so, even though I am using the webrtc.github.io tool,
The URL that is set is indeed turn.my-domain.com, which is the Common Name of my certificate.

[Scott]  OK good. :) 

4. I have never used wireshark, so it’s not easy to understand how it works, but I gave it a try.
Not actually sure what kind of information I am looking for?

Here is a screen of some frames that I could consider related, given the fact that it is the good server IP address…

<wireshark-screen.jpeg>

[Scott]  I'm not sure what I'm looking at in this screenshot.  You should be running wireshark on the reTurn machine and start tracing port 5349 or filter you output to only view TCP port 5349.  You should be able to decode the traffic on this port as SSL/TLS traffic and see the handshake messaging.
 

Thanks again in advance,

Best regards,

Florent Schildknecht
UX-designer et développeur web auto-entrepreneur
+33 6 78 41 74 79 (France)
+46 7 64 15 32 64 (Sweden)

On 30 Jan 2017, at 14:49, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

Hi Florent,

Things to look for:
1.  Was there any errors in the logs when reTurn started surrounding the loading of certificates?  Conversely, do you see success messages reading your certificate file?
2.  Does the client have the root certificate installed?
3.  Is the client connecting using the domain that matches the Common Name in the certificate?
4.  Take a wireshark capture of the TLS handshake to try to get more information on why the connection is closing.  Is is the client or server disconnecting?  Do the certificates presented from the server to the client look valid?

Some other general notes from the wiki (http://www.resiprocate.org/Certificates):
 "Certificates in the this file should be specified from top down. Ie. Highest level certificate first and root certificate last."

I'll let someone more linux savey answer your other questions about file permissions, etc.  :)

Scott

On Mon, Jan 30, 2017 at 5:22 AM, Florent SCHILDKNECHT <florent.schildknecht@gmail.com> wrote:
Hey,


I am trying to set-up reTurn server for a project requiring SSL/TLS encryption,
On a debian 8 server (installed with the official packets, apt-get install resiprocate-turn-server)
The server seems to work fine on unencrypted port, but I have troubles with TLS.

I am using letsencrypt to generate certificates, not with the certbot utility but another client.

I have the following valid certificates for my subdomain (turn.my-domain.com) ;
(Regenerated automatically every 3 months)

cert.pem (certificate part only)
chain.pem (chain part only)
combined.pem (combines the full-chain and the certificate private key)
fullchain.pem (it includes all the issuers chain)

Plus I of course have the keys

public.pem
private.pem

All those files are set in a specific location on my server, and are 0600, owned by a specific user (let say « acme »)

Few informations about my /etc/reTurn/reTurnServer.config :

TurnPort = 3478
TlsTurnPort = 5349

I am running the server with the user who owns the certificates (so they can be read) :
RunAsUser = acme
RunAsGroup = acme

And settings the absolute paths of the certificates

TlsServerCertificateFilename = /[...]/fullchain.pem
TlsServerPrivateKeyFilename = /[...]/private.pem


Authentication is working fine on port 3478, with the test user I’ve set ;
However, it doesn’t work on port 5349 (got some kind of timeout).

In the log file, I can see a "TlsConnection handshake failure error » :

WARNING | 20170130-105917.582 | reTurnServer | RETURN | 140414884460288 | TlsConnection.cxx:80 | TlsConnection handshake failure, error=335544539-short read


But I don’t understand what’s going on exactly ;
Do you know if there is something specific to check about TLS configuration, certificates or whatever ?
Am I supposed to provide the « fullchain.pem » certificate, or another one ?
(I’ve already tested with the four differente certificates, without success)

I’m also interested to know if there would be a better practice that running the server with my « acme » user,
But how to access the certificates ?


Best regards,

Florent Schildknecht
UX-designer et développeur web auto-entrepreneur
+33 6 78 41 74 79 (France)
+46 7 64 15 32 64 (Sweden)


_______________________________________________
resiprocate-users mailing list
resiprocate-users@resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail