WebRTC - How do you verify from the log, if its TLS or TCP or UDP connection?

[Sprogrammer]

Google Canary M39, M38, M36, M35 used as Turn client.

I have setup the Turnserver as UDP, TCP, TLS. but when Turn client (from enterprise proxy server/firewalls) connects to the Turnserver they auto close connections and do not continue "relay".

therefore, from log how do you verify for 100% to be sure that weather this connection was TLS or TCP or UDP? 

I get following log from them, how do you determine from following log, if it was a TLS or TCP connection attempts from Google Chrome/Canary??

Aug 19 01:50:41 ns429490 turnserver: 59501: IPv4. tcp or tls connected to: 54.90.24.232:44760
Aug 19 01:50:43 ns429490 turnserver: 59502: session 005000000000000018: TCP socket closed remotely 54.90.24.232:44760

Aug 19 01:50:43 ns429490 turnserver: 59502: session 005000000000000018: closed (2nd stage), user <>, local 37.x.74:80, remote 54.90.24.232:44760, reason: TCP connection closed by client (callback)
Aug 19 02:20:38 ns429490 turnserver: 61297: IPv4. tcp or tls connected to: 54.166.137.181:53465
Aug 19 02:20:40 ns429490 turnserver: 61299: session 002000000000000009: TCP socket disconnected: 54.166.137.181:53465
Aug 19 02:20:40 ns429490 turnserver: 61299: session 002000000000000009: closed (2nd stage), user <>, local 37.x.74:443, remote 54.166.137.181:53465, reason: TCP socket buffer operation error (callback)
Aug 19 04:28:08 ns429490 turnserver: 68948: IPv4. tcp or tls connected to: 125.107.157.53:1039
Aug 19 04:28:09 ns429490 turnserver: 68949: session 006000000000000011: TCP socket closed remotely 125.107.157.53:1039
Aug 19 04:28:09 ns429490 turnserver: 68949: session 006000000000000011: closed (2nd stage), user <>, local 37..74:443, remote 125.107.157.53:1039, reason: TCP connection closed by client (callback)

[Sprogrammer]

FYI - From the following link how do we determine if it was a TLS connection or not? it says "IPv4. tcp or tls". This connection attempt, failed to do successful connection and successful relay, even the candidates where forced to use relay

Aug 19 11:19:27 ns429490 turnserver: 93626: IPv4. tcp or tls connected to: 103.230.104.26:53626
Aug 19 11:19:27 ns429490 turnserver: 93626: IPv4. Local relay addr: 37.x.74:55706
Aug 19 11:19:27 ns429490 turnserver: 93626: session 000000000000000005: new, username=<root>, lifetime=600
Aug 19 11:19:27 ns429490 turnserver: 93626: session 000000000000000005: user <root>: incoming packet ALLOCATE processed, success
Aug 19 11:19:27 ns429490 turnserver: 93626: session 000000000000000005: user <root>: incoming packet ALLOCATE processed, success
Aug 19 11:19:37 ns429490 turnserver: 93636: session 006000000000000012: TCP socket closed remotely 103.230.104.26:53626
Aug 19 11:19:37 ns429490 turnserver: 93636: session 006000000000000012: closed (2nd stage), user <>, local 37.x.74:80, remote 103.230.104.26:53626, reason: TCP connection closed by client (callback)
Aug 19 11:24:58 ns429490 turnserver: 93957: session 000000000000000005: TCP socket closed remotely 103.230.104.26:20857
Aug 19 11:24:58 ns429490 turnserver: 93957: session 000000000000000005: closed (2nd stage), user <root>, local 37.x:80, remote 103.230.104.26:20857, reason: TCP connection closed by client (callback)
Aug 19 11:24:58 ns429490 turnserver: 93957: session 000000000000000005: delete: username=<root>

[Oleg Moskalenko]

Unfortunately that's not possible at the moment.

Sent from my iPhone

--
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.

[Sprogrammer]

OK - Thank you very much. 

* it would be nice to have that clearly mentioned in the log somewhere which will clearly explain weather its Google Canary bug or not 

( https://code.google.com/p/webrtc/issues/detail?id=1179 )

[Sprogrammer]

@Oleg: What am i doing wrong? is the TURNSERVER listening on TLS requests?

When i trace the TURNSERVER ssl logs coming form Google Canary M39 latest for TURN/TLS i am getting following:

The call is not successful, i have issue like showing "Connecting..."

[root@ns429490 ~]# ssldump -i eth0
New TCP connection #1: aircel-gprs-15.32.251.27.aircel.co.in(38566) <-> ns429490.ip-37-187-150.eu(22)
New TCP connection #2: dD5E036FE.access.telenet.be(63473) <-> ns429490.ip-37-187-150.eu(5349)
2 1  0.0273 (0.0273)  C>S  Handshake

      ClientHello

        Version 3.3  

        cipher suites

        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

        Unknown value 0xcc14

        Unknown value 0xcc13

        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

        TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

        TLS_ECDHE_RSA_WITH_RC4_128_SHA

        TLS_DHE_RSA_WITH_AES_128_CBC_SHA

        TLS_DHE_DSS_WITH_AES_128_CBC_SHA

        TLS_DHE_RSA_WITH_AES_256_CBC_SHA

        TLS_RSA_WITH_AES_128_GCM_SHA256

        TLS_RSA_WITH_AES_128_CBC_SHA

        TLS_RSA_WITH_AES_256_CBC_SHA

        TLS_RSA_WITH_3DES_EDE_CBC_SHA

        TLS_RSA_WITH_RC4_128_SHA

        TLS_RSA_WITH_RC4_128_MD5

        compression methods

                  NULL

2 2  0.0297 (0.0023)  S>C  Handshake

      ServerHello

        Version 3.3  

        session_id[0]=


 

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

        compressionMethod                   NULL

2 3  0.0297 (0.0000)  S>C  Handshake

      Certificate

2 4  0.0297 (0.0000)  S>C  Handshake

      ServerKeyExchange

Not enough data. Found 327 bytes (expecting 32767)

2 5    0.0297   (0.0000)    S>C    Handshake

        ServerHelloDone

2 6    0.0568   (0.0270)    C>S    Handshake

        ClientKeyExchange

Not enough data. Found 64 bytes (expecting 16384)

2 7    0.0568   (0.0000)    C>S    ChangeCipherSpec

2 8    0.0568   (0.0000)    C>S      Handshake

2 9    0.0573   (0.0004)    S>C    Handshake

2 10   0.0573   (0.0000)    S>C    ChangeCipherSpec

2 11   0.0573   (0.0000)    S>C      Handshake

  2      0.1302   (0.0729)    C>S    TCP FIN

  2      0.1303   (0.0001)    S>C    TCP RST

New TCP connection #3: 92.222.235.122(49167) <-> ns429490.ip-37-187-150.eu(5349)

3 1  0.0417 (0.0417)  C>S  Handshake

      ClientHello

        Version 3.3  

        cipher suites

        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

        Unknown value 0xcc14

        Unknown value 0xcc13

        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

        TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

        TLS_ECDHE_RSA_WITH_RC4_128_SHA

        TLS_DHE_RSA_WITH_AES_128_CBC_SHA

        TLS_DHE_DSS_WITH_AES_128_CBC_SHA

        TLS_DHE_RSA_WITH_AES_256_CBC_SHA

        TLS_RSA_WITH_AES_128_GCM_SHA256

        TLS_RSA_WITH_AES_128_CBC_SHA

        TLS_RSA_WITH_AES_256_CBC_SHA

        TLS_RSA_WITH_3DES_EDE_CBC_SHA

        TLS_RSA_WITH_RC4_128_SHA

        TLS_RSA_WITH_RC4_128_MD5

        compression methods

                  NULL

New TCP connection #4: 92.222.235.122(49168) <-> ns429490.ip-37-187-150.eu(5349)

4 1  0.0417 (0.0417)  C>S  Handshake

      ClientHello

        Version 3.3  

        cipher suites

        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

        TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

        Unknown value 0xcc14

        Unknown value 0xcc13

        TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

        TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

        TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

        TLS_ECDHE_RSA_WITH_RC4_128_SHA

        TLS_DHE_RSA_WITH_AES_128_CBC_SHA

        TLS_DHE_DSS_WITH_AES_128_CBC_SHA

        TLS_DHE_RSA_WITH_AES_256_CBC_SHA

        TLS_RSA_WITH_AES_128_GCM_SHA256

        TLS_RSA_WITH_AES_128_CBC_SHA

        TLS_RSA_WITH_AES_256_CBC_SHA

        TLS_RSA_WITH_3DES_EDE_CBC_SHA

        TLS_RSA_WITH_RC4_128_SHA

        TLS_RSA_WITH_RC4_128_MD5

        compression methods

                  NULL

3 2  0.0440 (0.0023)  S>C  Handshake

      ServerHello

        Version 3.3  

        session_id[0]=


 

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

        compressionMethod                   NULL

3 3  0.0440 (0.0000)  S>C  Handshake

      Certificate

3 4  0.0440 (0.0000)  S>C  Handshake

      ServerKeyExchange

Not enough data. Found 327 bytes (expecting 32767)

3 5    0.0440   (0.0000)    S>C    Handshake

        ServerHelloDone

4 2  0.0440 (0.0022)  S>C  Handshake

      ServerHello

        Version 3.3  

        session_id[0]=


 

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

        compressionMethod                   NULL

4 3  0.0440 (0.0000)  S>C  Handshake

      Certificate

4 4  0.0440 (0.0000)  S>C  Handshake

      ServerKeyExchange

Not enough data. Found 327 bytes (expecting 32767)

4 5    0.0440   (0.0000)    S>C    Handshake

        ServerHelloDone

3 6    0.0796   (0.0355)    C>S    Handshake

        ClientKeyExchange

Not enough data. Found 64 bytes (expecting 16384)

3 7    0.0796   (0.0000)    C>S    ChangeCipherSpec

3 8    0.0796   (0.0000)    C>S      Handshake

4 6    0.0796   (0.0355)    C>S    Handshake

        ClientKeyExchange

Not enough data. Found 64 bytes (expecting 16384)

4 7    0.0796   (0.0000)    C>S    ChangeCipherSpec

4 8    0.0796   (0.0000)    C>S      Handshake

4 9    0.0801   (0.0004)    S>C    Handshake

4 10   0.0801   (0.0000)    S>C    ChangeCipherSpec

4 11   0.0801   (0.0000)    S>C      Handshake

3 9    0.0801   (0.0004)    S>C    Handshake

3 10   0.0801   (0.0000)    S>C    ChangeCipherSpec

3 11   0.0801   (0.0000)    S>C      Handshake

  4      0.1509   (0.0708)    C>S    TCP FIN

  4      0.1510   (0.0000)    S>C    TCP RST

  3      0.1679   (0.0878)    C>S    TCP FIN

  3      0.1680   (0.0000)    S>C    TCP RST

1    3.7430 (3.7430)  C>S  TCP FIN

1    3.7435 (0.0004)  S>C  TCP FIN

For the same call TURNSERVER says:

Aug 20 10:31:54 ns429490 turnserver: 177173: IPv4. tcp or tls connected to: 92.222.235.122:49167



Aug 20 10:31:54 ns429490 turnserver: 177173: IPv4. tcp or tls connected to: 92.222.235.122:49168

Aug 20 10:31:54 ns429490 turnserver: 177174: session 006000000000000030: TCP socket disconnected: 92.222.235.122:49168

Aug 20 10:31:54 ns429490 turnserver: 177174: session 006000000000000030: closed (2nd stage), user <>, local 37.187.150.74:5349, remote 92.222.235.122:49168, reason: TCP socket buffer operation error (callback)

Aug 20 10:31:54 ns429490 turnserver: 177174: session 005000000000000029: TCP socket disconnected: 92.222.235.122:49167

Aug 20 10:31:54 ns429490 turnserver: 177174: session 005000000000000029: closed (2nd stage), user <>, local 37.187.150.74:5349, remote 92.222.235.122:49167, reason: TCP socket buffer operation error (callback)

 

Aug 20 10:36:12 ns429490 kernel: device eth0 left promiscuous mode

[Oleg Moskalenko]

Shamun, i cannot say what is wrong, i've not seen such a problem. That may be a protocol problem or a certificate problem, i do not know.

Oleg

[Sprogrammer]

Oleg, FYI

Two thing i observed related to certificate concern (TLS without Turnserver and TLS check with Turnserver for my wildcard certificates):

1 - properly got reply for same certificate

$ openssl s_client -connect NOTturnserver.mydomain.com:443
 

    Start Time: 1408533632

    Timeout   : 300 (sec)

    Verify return code: 0 (ok)

2 - not properly replied for same certificate

$ openssl s_client -connect TURNSERVER.mydomain.com:443



    Start Time: 1408538317

    Timeout   : 300 (sec)

 

    Verify return code: 21 (unable to verify the first certificate)

Could it be the reason Google Chrome M36 and Google Canary M39 failing sometimes because TURNSERVER return code 21? 

On other hand when i do check $ openssl s_client -connect 104.130.135.92:443 i get always perfect reply and there service always working with Google Chrome M36 and Canary M39

[Sprogrammer]

After reading the CA certificate file the verify return error is now fixed, but showing two errors:

139787582711624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40

 

139787582711624:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

Start Time: 1408555977

    Timeout   : 300 (sec)

    Verify return code: 0 (ok)

And when i do real call its failing to connect, like showing forever: "Connecting..."

[Sprogrammer]

Very weird, is this a TURNSERVER BUG?. 

Since i started to read the --CA-file it does not connect anymore, when i read only the --pkey and --cert and do not use --CA-file, then it connects at-least, but show errors when i use openssl checking tools.

Following logs were taken while using --CA-file , --pkey, --cert and connection fail, it does not intialize any TLS session

Aug 20 19:43:17 ns429490 turnserver: 571: IPv4. tcp or tls connected to: 213.224.54.254:50593
Aug 20 19:43:17 ns429490 turnserver: 571: session 003000000000000004: TCP socket disconnected: 213.224.54.254:50593
Aug 20 19:43:17 ns429490 turnserver: 571: session 003000000000000004: closed (2nd stage), user <>, local 37.187.150.74:443, remote 213.224.54.254:50593, reason: TCP socket buffer operation error (callback)
Aug 20 19:43:18 ns429490 turnserver: 572: IPv4. tcp or tls connected to: 213.224.54.254:63923
Aug 20 19:43:18 ns429490 turnserver: 572: session 004000000000000001: TCP socket disconnected: 213.224.54.254:63923
Aug 20 19:43:18 ns429490 turnserver: 572: session 004000000000000001: closed (2nd stage), user <>, local 37.187.150.74:443, remote 213.224.54.254:63923, reason: TCP socket buffer operation error (callback)

[Oleg Moskalenko]

Shamun, above your were saying that openssl s_client works fine with the TURN server. I have no idea why M39 has problems. We are using the standard openssl libraries. We do not program manually the SSL negotiation - whatever openssl is doing, we use that. If the client_s works fine, then any normal program must work fine.

As for the CA-file, it must be a well formed certificate. See the example in examples/etc/turn_server_cert.pem (a self-signed certificate). That example works just fine - if the client does not require a CA-signed certificate. Run the example (examples/scripts/longtermsecure/secure_relay_cert.sh together with examples/scripts/longtermsecure/secure_tls_client_cert.sh) and see yourself that everything works fine. Check the capture between the server and the client and compare with your negotiations, and check what is different.

[Sprogrammer]

Shamun, above your were saying that openssl s_client works fine with the TURN server. 

> NO - Please note that it works with abnormal settings let me elaborate it

A) When i only used: pkey and cert but not CA-file, then M36, M39 both worked but $ openssl s_client check on turnserver shows an invalid return code. in normal networking this setup works but when same setup i am testing with complicated networks such as Enterprise with proxy etc etc then Google Chrome M36, M39 same working browsers do not work. My wild guess is that because its very abnormal settings 

B) When i only used: pkey + cert + CA-file. Then M36, M39 both fails to even gather candidates and process the relay. But $openssl s_client check on turnserver shows return correctly with two error lines as shown in my previous paste

Now to summarise A and B both is not solving the real reliable "relay" problem here. 

Depending on random networks its working sometimes and sometimes its not working. 

Also what is very confusing here is that when you check turnserver with $ openssl s_client -connect TURNSERVER.mydomain.com:443 , return results are very weird and that could be 

the main reason Google Chrome/Canary is doing abnormal.  

I have no idea why M39 has problems. We are using the standard openssl libraries. We do not program manually the SSL negotiation - whatever openssl is doing, we use that. If the client_s works fine, then any normal program must work fine.

> FYI - client_s are not working fine for A to Z networks, few of them working fine, if i consider the settings of point A mentioned above

As for the CA-file, it must be a well formed certificate. 

> YES - its is official certificate. we are using for a while with HTTP Apache web server works when we do check with $ openssl s_client..

See the example in examples/etc/turn_server_cert.pem (a self-signed certificate). That example works just fine - if the client does not require a CA-signed certificate. Run the example (examples/scripts/longtermsecure/secure_relay_cert.sh together with examples/scripts/longtermsecure/secure_tls_client_cert.sh) and see yourself that everything works fine. Check the capture between the server and the client and compare with your negotiations, and check what is different.

> OK - that is something new i should now try, because all the rest did not yet helped.

Thank you very much.

[Oleg Moskalenko]

I ll try to look into it, i ll see whether i can find anything.

Sent from my iPhone

[Sprogrammer]

OK - FYI still same connecting.. forever and never gets connected with M36, M39.

1 - I tried like you suggested:

$ turnserver --syslog -a --max-bps=3000000 -f -m 10 --user=root:root -r turn.xx.com --cert=ssl.crt --pkey=ssl.key --CA-file=ssl.ca -v --cipher-list="ALL:SSLv2:!eNULL:!aNULL:!NULL"

2 - Then checking with the certificate:

$ openssl s_client -connect turn.xxxx.com:443



CONNECTED(00000003)

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA

verify return:1

depth=1 C = US, O = DigiCert Inc, CN = DigiCert Secure Server CA

verify return:1

depth=0 C = BE, ST = Oost-Vlaanderen, L = Buggenhout, O = xxxx, CN = *.xxx.com

verify return:1

140290482374472:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40

140290482374472:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

---

Certificate chain

 0 s:/C=BE/ST=Oost-Vlaanderen/L=Buggenhout/O=xxx/CN=*.xxx.com

   i:/C=US/O=DigiCert Inc/CN=DigiCert Secure Server CA

 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Secure Server CA

   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIGrDCCBZSgAwIBAgIQCYoD9ORWB3XN8v8s3sfQRDANBgkqhkiG9w0BAQUFADBI

MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSIwIAYDVQQDExlE

aWdpQ2VydCBTZWN1cmUgU2VydmVyIENBMB4XDTE0MDIxNjAwMDAwMFoXDTE1MDIy

NTEyMDAwMFoweTELMAkGA1UEBhMCQkUxGDAWBgNVBAgTD09vc3QtVmxhYW5kZXJl

bjETMBEGA1UEBxMKQnVnZ2VuaG91dDEaMBgGA1UEChMRVGVsZXBvcnRlbCBFdXJv




-----END CERTIFICATE-----

subject=/C=BE/ST=Oost-Vlaanderen/L=Buggenhout/O=xxx/CN=*.xxx.com

issuer=/C=US/O=DigiCert Inc/CN=DigiCert Secure Server CA

---

Acceptable client certificate CA names

/C=US/O=DigiCert Inc/CN=DigiCert Secure Server CA

---

SSL handshake has read 3446 bytes and written 138 bytes

---

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1.2

    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

    Session-ID:

    Session-ID-ctx:

    Master-Key: 9E1CD696455E4002546D8D657AE1456583A661735E97013531F315F1A2A0EB4247F8F998E0EC4785A916023E2CE0287A

    Key-Arg   : None

    Krb5 Principal: None

    PSK identity: None

    PSK identity hint: None

    Start Time: 1408567360

    Timeout   : 300 (sec)

    Verify return code: 0 (ok)

 

---

3 - Then from Google Chrome/Canary connecting to do TLS:

65: IPv4. tcp or tls connected to: 82.143.92.19:60333



65: session 003000000000000002: TCP socket disconnected: 82.143.92.19:60333

65: session 003000000000000002: closed (2nd stage), user <>, local 37.187.150.74:443, remote 82.143.92.19:60333, reason: TCP socket buffer operation error (callback)

65: IPv4. tcp or tls connected to: 213.224.54.254:54748

65: session 006000000000000001: TCP socket disconnected: 213.224.54.254:54748

65: session 006000000000000001: closed (2nd stage), user <>, local 37.187.150.74:443, remote 213.224.54.254:54748, reason: TCP socket buffer operation error (callback)

^C

 

[root@ns429490 conf.d]# ^C

[Oleg Moskalenko]

Shamun, as far as I can see, something is not right with your keys and/or certificates. Either they are not right, or they are not in PEM format. Only PEM format is accepted by the TURN server (see the documentation). Convert your files to PEM if they are in a different format.

I performed a test and it works fine:

1) Run the server as:

  $ bin/turnserver -a -f --user=ninefingers:youhavetoberealistic --cert=examples/etc/turn_server_cert.pem --pkey=examples/etc/turn_server_pkey.pem --CA-file=examples/etc/turn_server_cert.pem -v

 2) Run the openssl connect procedure:

  $ openssl s_client -cert examples/etc/turn_server_cert.pem -key examples/etc/turn_server_pkey.pem -CAfile examples/etc/turn_server_cert.pem -connect 127.0.0.1:3478

The output:

CONNECTED(00000003)
depth=0 C = US, ST = CA, L = Walnut Creek, O = TURN Server project, OU = Development, CN = Oleg, emailAddress = mom0...@gmail.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=CA/L=Walnut Creek/O=TURN Server project/OU=Development/CN=Oleg/emailAddress=mom0...@gmail.com
   i:/C=US/ST=CA/L=Walnut Creek/O=TURN Server project/OU=Development/CN=Oleg/emailAddress=mom0...@gmail.com

---
Server certificate
-----BEGIN CERTIFICATE-----

MIIDsDCCApgCCQCmgrJCiQlGOTANBgkqhkiG9w0BAQUFADCBmDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAkNBMRUwEwYDVQQHEwxXYWxudXQgQ3JlZWsxHDAaBgNVBAoT
E1RVUk4gU2VydmVyIHByb2plY3QxFDASBgNVBAsTC0RldmVsb3BtZW50MQ0wCwYD
VQQDEwRPbGVnMSIwIAYJKoZIhvcNAQkBFhNtb20wNDAyNjdAZ21haWwuY29tMCAX
DTEyMTEyNTA4MjAxNloYDzIxMTIxMTAxMDgyMDE2WjCBmDELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAkNBMRUwEwYDVQQHEwxXYWxudXQgQ3JlZWsxHDAaBgNVBAoTE1RV
Uk4gU2VydmVyIHByb2plY3QxFDASBgNVBAsTC0RldmVsb3BtZW50MQ0wCwYDVQQD
EwRPbGVnMSIwIAYJKoZIhvcNAQkBFhNtb20wNDAyNjdAZ21haWwuY29tMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv6bYkERhZ43RjW4EuqCaTq5g+D+l
JI/GwlVzdzQ3+F4clMQDR1kp1nX+9AvwjCXz3AYwY1H9CqjmjGM4R9uNJJseK/aJ
d2DUFADkF+7I674XwX8U2Fy5on9jqWq3jdbb8eg/awcTBdrNLWNPquwfS2KVdooj
9yPkqnO0c3ko1/OzIQCcs09O3l/MPt+aOsHk3B9l79ZRs3zWkylI+we0Fnc+7tZE
psCztA+KCCoiJf7NenOvVhdKg7D1AXuzJ/P/Euvc3+CIiS9HI4pWLopY1k+HydLe
IcopqSbg9CRIKe1HOL8YTvCm2ZoTqgijwWUlGtwEDf2xxUQX/TLYiW8JFQIDAQAB
MA0GCSqGSIb3DQEBBQUAA4IBAQATbrBOLV4e8Qmsby9+srxXsdbNc60PmDZ4WiZ1
IElfWmzM7wGXm9sJg1PX/7T24R1tbwZGLIhZnkhecG372GChULZJ9Pdjh0Ab2nK5
LRKHXTpjp/xOJvx0JMCIIyRnGZT1nABPOk8uEjNW8PaU6yhQ4f5nKaSOgYGRCln6
dcy5vylCsyD9Q7GXs0KOC38XD+Ycv6VLX4zKJ2Yum50Wt643nLjG9RlGT3FXWJ1K
HUbPC5TO6bcYLdiTjaYr+X8xC/x6h/Ngdo/16w7fRmQQ4uS+TVXrg8ITmI71KX/I
m7C9jbsubwzrhW84oZXYf+o/0ATtEAhiVLnHifKCCYikqfVj
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Walnut Creek/O=TURN Server project/OU=Development/CN=Oleg/emailAddress=mom0...@gmail.com
issuer=/C=US/ST=CA/L=Walnut Creek/O=TURN Server project/OU=Development/CN=Oleg/emailAddress=mom0...@gmail.com

---
Acceptable client certificate CA names

/C=US/ST=CA/L=Walnut Creek/O=TURN Server project/OU=Development/CN=Oleg/emailAddress=mom0...@gmail.com
---
SSL handshake has read 2919 bytes and written 1755 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1

    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 2B0174C18FCCD794B3634DB1E6D2B73AD08B17555C5778ADC394AF6139C6A039
    Session-ID-ctx:
    Master-Key: 7BF6685F15230C8F9344C9ADEB5F9EE32E48F27ED36776794181F01148302671FB5D8DF35A283CED6E03D9B5E5D13C19
    Key-Arg   : None

    PSK identity: None
    PSK identity hint: None

    SRP username: None
    TLS session ticket:
    0000 - c7 eb 99 8e fe e8 a4 d4-bb 17 95 d3 3a 73 2b ec   ............:s+.
    0010 - e9 af ab 83 e6 1b be 69-28 a3 98 19 30 89 af e1   .......i(...0...
    0020 - 48 06 ce 25 90 9e 80 71-a3 e6 1e 44 a3 f0 d7 d7   H..%...q...D....
    0030 - 2c 09 1e 50 05 cb 09 38-ee 34 37 ec a5 bf 87 fd   ,..P...8.47.....
    0040 - 10 ca ed 4f eb 2c d9 9d-cd a4 2a d1 22 cc 58 f2   ...O.,....*.".X.
    0050 - 4f f6 11 67 0b cd 43 2e-ab 74 e4 3d b9 e0 d4 ee   O..g..C..t.=....
    0060 - 96 23 54 15 d4 54 34 e5-1c c3 4b 7d 4b fc ef b7   .#T..T4...K}K...
    0070 - 1d 1a ac 67 1e 3e 36 cf-97 90 c9 be 64 82 a3 83   ...g.>6.....d...
    0080 - 3b 18 c9 c9 3b 69 fc d8-a2 c3 84 bf 2c e8 9a 60   ;...;i......,..`
    0090 - 65 e0 51 ea 21 c4 12 c4-15 23 76 01 b5 19 4d 68   e.Q.!....#v...Mh
    00a0 - 3c 4a a9 5b bf a5 ee 38-35 49 18 3f 36 25 c2 05   <J.[...85I.?6%..
    00b0 - 7d db fa f8 9b 0a 7b c0-34 cf 8e 95 58 12 88 7b   }.....{.4...X..{
    00c0 - 77 d8 08 5e a7 2a b1 a8-d5 f6 d6 9b 34 05 61 b1   w..^.*......4.a.
    00d0 - 9a 6e 77 b7 16 27 48 33-26 06 1c f6 ea 56 32 83   .nw..'H3&....V2.
    00e0 - e2 2e 6b 69 62 c9 21 b4-4a 9f ce 24 41 e3 3e c7   ..kib.!.J..$A.>.
    00f0 - 0c 8b bf 6b 5d 16 7c 42-8b 5e a4 fa 71 7e 9e a0   ...k].|B.^..q~..
    0100 - e4 a0 97 ed 24 c4 7d f4-8f c0 f1 72 95 87 a0 9b   ....$.}....r....
    0110 - df 9a 8b 5a b2 94 df c5-db 56 a7 02 72 62 d0 8b   ...Z.....V..rb..
    0120 - bc 03 3d 74 c1 f3 26 2f-10 d9 44 29 dc 77 3c 22   ..=t..&/..D).w<"
    0130 - f1 1e 23 70 c6 fe 5b 41-b1 c6 40 f3 c6 8f 2b 7f   ..#p..[A..@...+.
    0140 - 12 bb 25 6b 9d 23 54 4a-9e dd c1 b8 8f 7c 69 1c   ..%k.#TJ.....|i.
    0150 - 39 72 07 b4 42 cb 8f 82-a1 c6 fa cc f0 4d c7 f2   9r..B........M..
    0160 - 76 94 01 b0 16 69 2b 05-3c bb de 36 53 03 7c 24   v....i+.<..6S.|$
    0170 - dc e4 7f e5 1c 9a 4a 71-5b 51 f4 8c ce f7 3e 19   ......Jq[Q....>.
    0180 - f8 be bd 8b 89 8d 73 f9-03 e9 d7 d6 ac ed 90 aa   ......s.........
    0190 - c0 76 f9 de 4f 2b 64 bb-5a fe 52 50 2d ba cd bc   .v..O+d.Z.RP-...
    01a0 - f2 fd e4 68 8c d2 16 0c-f0 e3 79 27 63 78 63 48   ...h......y'cxcH
    01b0 - 2f 30 48 d1 b7 29 3c 13-5f fc 73 24 75 6f 0e 61   /0H..)<._.s$uo.a
    01c0 - 6c 84 1a 22 01 fa ef 8b-07 ee 44 5c 0f ec 53 e9   l.."......D\..S.
    01d0 - 42 22 25 75 94 ad b5 78-3d 0e 21 ea e2 f7 e3 e4   B"%u...x=.!.....
    01e0 - a8 c9 90 52 0e c3 89 a9-ef 5e 4c c0 6b 21 98 71   ...R.....^L.k!.q
    01f0 - d3 fe cb 0d 03 d5 c6 ff-a9 90 f5 2a 34 e0 1f 52   ...........*4..R
    0200 - 59 b7 e1 0a 48 04 e0 03-6c 2e 32 dd c4 bd a3 c6   Y...H...l.2.....
    0210 - 81 66 20 78 49 58 e5 24-95 36 6c ff d0 ac f7 bf   .f xIX.$.6l.....
    0220 - 92 bc 51 d6 a5 92 3f 23-ca 96 8e d6 9a 9f 0e 39   ..Q...?#.......9
    0230 - 62 b5 81 89 a8 7d 0a 1d-31 25 96 c5 43 5e c3 3d   b....}..1%..C^.=
    0240 - 8d 58 2d 7e 2c f7 86 55-6b d0 df 03 cc 01 b3 22   .X-~,..Uk......"
    0250 - b2 88 af 56 84 1c 6a b3-13 9b 6a 34 d8 b6 4b 5c   ...V..j...j4..K\
    0260 - 50 2a 32 09 79 cf 06 7f-c5 cf 66 f5 e0 38 25 6e   P*2.y.....f..8%n
    0270 - ff ce 8e 4f ea 49 ec 3b-5b 3a 03 d5 bb 08 d3 c4   ...O.I.;[:......
    0280 - 9d 76 84 e2 53 68 33 b4-64 dd c5 a8 d3 7f 94 a5   .v..Sh3.d.......
    0290 - c2 b0 02 a3 d1 b3 2c f6-bd a0 14 32 a7 27 90 4e   ......,....2.'.N
    02a0 - 11 32 c5 dd 75 0b 85 1c-2b 01 61 44 87 ca d9 90   .2..u...+.aD....
    02b0 - f3 88 a2 36 b5 65 22 91-dc 91 fa 57 7d 31 9f b8   ...6.e"....W}1..
    02c0 - f2 83 9b ad 81 98 13 eb-0f 11 53 de 5b ab be 80   ..........S.[...
    02d0 - 4b bd 43 d7 d4 e2 54 21-10 85 3f 7c 4f 5c 47 4d   K.C...T!..?|O\GM
    02e0 - a4 23 d7 12 a7 57 30 58-ef 8c 9e 70 ca ab 90 1b   .#...W0X...p....
    02f0 - 28 44 36 34 30 0d fa ee-5a c4 52 5a 21 48 c5 ba   (D640...Z.RZ!H..
    0300 - 5e 07 8b 0e bd 01 e1 f1-86 55 14 cb ad 81 82 42   ^........U.....B
    0310 - 2e fc 4b 68 38 68 03 13-c4 56 8a ee 80 ad 81 02   ..Kh8h...V......
    0320 - 49 fb 4b 94 ac 96 78 e5-d8 29 32 33 30 5f d2 93   I.K...x..)230_..
    0330 - 41 cd 70 5a a5 78 20 2f-8a 8a 87 c6 22 87 80 e8   A.pZ.x /...."...
    0340 - 5f ef d4 12 1e ae 3c 80-71 5e 26 cf 9f 3d f7 2d   _.....<.q^&..=.-
    0350 - 35 ad f5 09 33 e2 39 ff-4f 7f c5 14 a6 76 08 cb   5...3.9.O....v..
    0360 - 7a b7 ca 4b 81 42 23 3f-5a a0 be f9 9f 24 6f d3   z..K.B#?Z....$o.
    0370 - 5c 61 9f 2e 50 f2 4c 52-f7 89 d4 91 b5 45 65 b6   \a..P.LR.....Ee.
    0380 - 3e 72 39 95 b6 ff ec 70-5a 0d e9 19 a9 53 f8 65   >r9....pZ....S.e
    0390 - 77 86 b7 76 23 65 d8 52-56 a2 95 5e 1a fa 59 57   w..v#e.RV..^..YW
    03a0 - 19 1d 36 68 ea 38 83 9d-00 a2 be 97 36 19 3e 82   ..6h.8......6.>.
    03b0 - 71 2e 69 64 fa 11 a4 99-5b 11 5a bf db ab e0 79   q.id....[.Z....y
    03c0 - 94 14 dc 8d 78 0a 60 2d-b1 77 e4 74 e9 3a 1a f9   ....x.`-.w.t.:..
    03d0 - 29 0b d2 a5 8b 43 2f 36-a1 13 cb 63 f9 a4 5f 67   )....C/6...c.._g
    03e0 - 32 66 13 4c bf 71 1d 5b-98 77 d2 e5 92 c5 62 e4   2f.L.q.[.w....b.
    03f0 - 1b 28 d7 12 e5 c0 3a 7f-37 73 65 89 27 a8 c1 c6   .(....:.7se.'...
    0400 - 00 fe ac b0 5f 7e e6 36-b8 1a 17 35 48 98 5c 32   ...._~.6...5H.\2
    0410 - bf ac e0 85 3d e8 dd 5d-91 33 e1 d4 20 e9 90 b0   ....=..].3.. ...
    0420 - 3f 34 d5 8f c0 1e ef 3c-60 35 7a d1 81 ff 87 a6   ?4.....<`5z.....
    0430 - 62 43 b9 83 51 cd d7 7f-df 03 d4 de 3e 14 eb e4   bC..Q.......>...
    0440 - 6e 87 42 f5 75 54 56 92-d1 06 5b 94 39 c1 13 2e   n.B.uTV...[.9...

    Start Time: 1408569819

    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

One difference that I see is that you are using TLS1.2. May be there is a problem with TLS1.2 support. I'll double-check it.

Regards,

Oleg

[Sprogrammer]

Oleg, 

OK - Thank you, thats excellent catch.

- it must be that i have not converted the original certificates i got from supplier yet, into PEM. 

i wish and hope  that is the problem, i will now change them and again retry.

- TLS1.2 support and related issues should be fixed if possible. 

This problem is a nightmare it does not have head nor tail "Connecting... problem" while testing with random networking scenarios. 

Therefore, if we can remove all those related issues out of the way, then further more testing that i am planning would be very positive.

Reg

Shamun

[Oleg Moskalenko]

Shamun, this code has been in usage for a while without changes, and nobody complained about TLS. So I do not believe that there is any serious problem with the TURN server TLS code.

I just tested TLS1.2. It works fine, too.

Another experiment:

1) Run the server without certificate:

  bin/turnserver -a -f --user=ninefingers:youhavetoberealistic --cert=examples/etc/turn_server_cert.pem --pkey=examples/etc/turn_server_pkey.pem -v

2) Run the wireshark on the server/client connection.

3) In the browser, type the URL:  https://<server-ip>:3478 and hit "Enter".

You will see the words "TURN Server" in the browser window. Then open the wireshark capture and check the TLS negotiations - they must be going without any error code. I tried that with different browsers and it works.

Regards,
Oleg

[Sprogrammer]

Oleg,

Thank you, i have done all your suggested tests i had also same results like you have mentioned. So the certificate checking is OK and via browsers if we do check https://<turnserver>:443 is also OK!

But then we have done real world 100 call tests based on following with same network or without same networks all of the calls failed: 

1 - turnserver -a -f --user=nice:isgood --cert=turn_server_cert.pem --pkey=turn_server_pkey.pem -v

2 - Most of the calls are failed and most of the time it was "Connecting..." but never connected ICE candidates gathering failed and in server we had mostly following logs:

Aug 21 07:34:58 ns429490 turnserver: 26238: IPv4. tcp or tls connected to: 103.230.107.7:59950

 

Aug 21 07:34:58 ns429490 turnserver: 26238: session 007000000000000012: TCP socket closed remotely 103.230.107.7:59950

Aug 21 07:34:58 ns429490 turnserver: 26238: session 007000000000000012: closed (2nd stage), user <>, local 37.187.150.74:443, remote 103.230.107.7:59950, reason: TCP connection closed by client (callback)

Aug 21 07:36:16 ns429490 turnserver: 26317: session 007000000000000011: closed (2nd stage), user <root>, local 37.187.150.74:443, remote 103.230.105.28:65355, reason: allocation timeout

Aug 21 07:36:16 ns429490 turnserver: 26317: session 007000000000000011: SSL shutdown received, socket to be closed (local 37.187.150.74:443, remote 103.230.105.28:65355)

Aug 21 07:36:16 ns429490 turnserver: 26317: session 007000000000000011: delete: username=<root>

Why is this happening please? (this same failed user can browse https://<same turnserver>:443 with same browser versions/network environment)

[Oleg Moskalenko]

It can be happening for million of various reasons. If the browser is connecting to the https://<ip>:3478 successfully, then TLS is not the problem, something else is. Try to run the wireshark and check the communications.

Oleg

--

[shivang bhagat]

Dear Sprogrammer,

I am getting the same error.

did you found out the bug ?

Thanks,

Shivang