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

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


Hey @Daniel,

Very good to know, thanks for the information.

Actually, when I try the following connections from my local computer,
It indeed turns out that only tls v1.0 is working (resiprocate-turn-server current official debian package release is 1.9) :



$ openssl s_client -connect turn.my-domain.com:5349
CONNECTED(00000003)
54883:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:[...]

—> Could potentially be the TLS Handshake error I am having?


Then, when I force the TLS v1.0 option, it succeeds :

$ openssl s_client -connect turn.my-domain.com:5349 -tls1
CONNECTED(00000003)
depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
[…]


Is there any server-side way to handle this properly?


I am not sure if this could be specified in the RTCConfiguration dictionnary (_javascript_, client-side) ;
Actually I do not think it’s possible to specify anything else than :
- the URL : "{stun|turn|turns}:turn.my-domain:XXXX"
- The optional credentials (username / credential)

Or would it be any way to specify it directly within the URL,
Something like : "turns:turn.my-domain.com:5349?encryption=tlsv1.0" ?


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 01 Feb 2017, at 12:06, Daniel Pocock <daniel@xxxxxxxxxx> wrote:

On 31/01/17 14:22, Scott Godin wrote:
Glad you got it working.  :)


There is one known bug in there for TURN over TLS, fixed in the latest
code a few months ago

Some time ago I went through most of the code and changed it from TLSv1
to SSLv23 (dynamical selection of TLS version 1, 1.1, 1.2, ...).  When I
fixed that for SIP, I didn't make the corresponding change in the TURN
code.  So it would only accept connections from TLS v1.0 clients.  I'm
not sure how fussy the web browsers are about this, maybe some will work
and others won't.  The problem is, web browsers give visual feedback
when a HTTPS connection to load a page fails, but they don't give very
good feedback when a connection to a WebSocket or TURN server fails, you
often have to detect things like this by looking at the packet sniffer
or enabling browser debug logs.

Now it is also changed in the reTurn server:

https://github.com/resiprocate/resiprocate/commit/a6d67ea1319939dafca99931de408a5842276906

and that is in the 1.11 release, I recently created a beta build for 1.11

Regards,

Daniel


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

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