Terminate SSL with a transparent proxy

[pablo platt]

Hi,

I'm trying to terminate SSL with haproxy and pass the connection to the turn server so it will handle palin TCP.
The connection is created but than immediately close:
4: IPv4. tcp or tls connected to: 193.167.56.300:34833
4: session 000000000000000001: TCP socket closed remotely 193.167.56.300:34832
4: session 000000000000000001: closed (1st stage), user <>, local 193.167.56.300:34832, remote 193.167.56.300:34832, reason: TCP connection closed by client (callback)

The Chrome client pc config is:
var pc_config = {"iceServers": [
    {"url": "stun:stun.l.google.com:19302"},
    {'url': 'turns:193.167.56.300:443?transport=tcp',
     'credential': 'sCPq0MBglszJ2cMEZlFAnPBf6do=',
     'username': '1397599345:1'}
]};

haproxy config:
frontend turn_frontend
    mode tcp
    bind *:443 ssl crt /etc/haproxy/cert.pem
    default_backend turn_backend

backend turn_backend
    mode tcp
    server turn_server 193.167.56.300:3478

When using haproxy with the turn server without SSL the relay works.

Any idea why the connection is closed in SSL?

Thanks

[Oleg Moskalenko]

It is saying saying that the "client" (in this case haproxy, right ?) is closing the connection - and this is the reason why. You can check the communication between them with the wireshark.

Oleg

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

[pablo platt]

I've tried using a self signed certificate without a proxy from Chrome 34.0.1847.116 with:
'url': 'turns:193.167.56.300:5349?transport=tcp'

I'm getting TCP socket buffer operation error:

0: pid file created: /var/run/turnserver.pid
0: IO method (main listener thread): epoll (with changelist)
0: Wait for relay ports initialization...
0:   relay 10.0.2.15 initialization...
0:   relay 10.0.2.15 initialization done
0:   relay 193.167.56.300 initialization...
0:   relay 193.167.56.300 initialization done
0:   relay ::1 initialization...
0: (src/apps/relay/turn_ports.c:turnports_create:142): allocated super memory: region id = 1262425434, chunk=1, chunks=2, total=2097152, allocated=0, want=393256
0: (src/apps/relay/turn_ports.c:turnports_create:142): allocated super memory: region id = 1262425434, chunk=1, chunks=2, total=2097152, allocated=393256, want=393256
0:   relay ::1 initialization done
0: Relay ports initialization done
0: IO method (general relay thread): epoll (with changelist)
0: turn server id=0 created
0: IPv4. UDP/DTLS listener opened on: 127.0.0.1:3478
0: IPv4. UDP/DTLS listener opened on: 127.0.0.1:3479
0: IPv4. UDP/DTLS listener opened on: 127.0.0.1:5349
0: IPv4. UDP/DTLS listener opened on: 127.0.0.1:5350
0: IPv4. UDP/DTLS listener opened on: 10.0.2.15:3478
0: IPv4. UDP/DTLS listener opened on: 10.0.2.15:3479
0: IPv4. UDP/DTLS listener opened on: 10.0.2.15:5349
0: IPv4. UDP/DTLS listener opened on: 10.0.2.15:5350
0: IPv4. UDP/DTLS listener opened on: 193.167.56.300:3478
0: IPv4. UDP/DTLS listener opened on: 193.167.56.300:3479
0: IPv4. UDP/DTLS listener opened on: 193.167.56.300:5349
0: IPv4. UDP/DTLS listener opened on: 193.167.56.300:5350
0: IPv6. UDP/DTLS listener opened on: ::1:3478
0: IPv6. UDP/DTLS listener opened on: ::1:3479
0: IPv6. UDP/DTLS listener opened on: ::1:5349
0: IPv6. UDP/DTLS listener opened on: ::1:5350
0: IPv4. TCP/TLS listener opened on : 127.0.0.1:3478
0: IPv4. TCP/TLS listener opened on : 127.0.0.1:3479
0: IPv4. TCP/TLS listener opened on : 127.0.0.1:5349
0: IPv4. TCP/TLS listener opened on : 127.0.0.1:5350
0: IPv4. TCP/TLS listener opened on : 10.0.2.15:3478
0: IPv4. TCP/TLS listener opened on : 10.0.2.15:3479
0: IPv4. TCP/TLS listener opened on : 10.0.2.15:5349
0: IPv4. TCP/TLS listener opened on : 10.0.2.15:5350
0: IPv4. TCP/TLS listener opened on : 193.167.56.300:3478
0: IPv4. TCP/TLS listener opened on : 193.167.56.300:3479
0: IPv4. TCP/TLS listener opened on : 193.167.56.300:5349
0: IPv4. TCP/TLS listener opened on : 193.167.56.300:5350
0: IPv6. TCP/TLS listener opened on : ::1:3478
0: IPv6. TCP/TLS listener opened on : ::1:3479
0: IPv6. TCP/TLS listener opened on : ::1:5349
0: IPv6. TCP/TLS listener opened on : ::1:5350
0: IO method (cli thread): epoll (with changelist)
0: IPv4. CLI listener opened on : 127.0.0.1:5766
0: IO method (auth thread): epoll (with changelist)
7: handle_udp_packet: New UDP endpoint: local addr 193.167.56.300:5349, remote addr 193.167.56.1:54809
7: session 000000000000000001: user <>: incoming packet BINDING processed, success
7: IPv4. tcp or tls connected to: 193.167.56.1:54770
7: IPv4. tcp or tls connected to: 193.167.56.1:54771
7: session 000000000000000002: TCP socket disconnected: 193.167.56.1:54770
7: session 000000000000000002: closed (1st stage), user <>, local 193.167.56.1:54770, remote 193.167.56.1:54770, reason: TCP socket buffer operation error (callback)
7: session 000000000000000003: TCP socket disconnected: 193.167.56.1:54771
7: session 000000000000000003: closed (1st stage), user <>, local 193.167.56.1:54771, remote 193.167.56.1:54771, reason: TCP socket buffer operation error (callback)

[Warren McDonald]

Hi Pablo,

Chrome 34 still has issues with TLS.  I have only had successful use on 35 and above. So I would not bother testing on 34 at all.

We are currently readying our TURN infrastructure for TLS release and still waiting for Chrome to stabilise this before we do.

Warren 

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

"TCP socket buffer operation error" mans that the remote party closed the connection (if your network is OK). The usual reason with TLS is the TLS negotiation failure. You can use the wireshark, see inside the packets and find out why it failed.

For example, there may be such reasons as:

1) You are not using a good certificate and a proper private key on the server. If that is a self-signed certificate then Chrome may simply reject the TURN server certificate. You may need a real certificate.

2) If you run the TURN server in the mode of checking the client certificate (by default it does not check it), then the server may not be able to verify the client certificate - either the client certificate is wrong, or server was not configured properly for the client certificate verification. But normally you should not run the server in that mode.

Oleg

[pablo platt]

Is there a way to tell Chrome to accept self-signed certificate for development?

Maybe from the command line?

I've tried with a real certificate by adding the local IP to /etc/hsots file with the certificate domain but I still can't make TLS work.

I don't see anything in the log file even in verbose mode.

Plain TCP works fine.

[Oleg Moskalenko]

I am not a Chrome implementation expert, I cannot tell that.

You can use the wireshark and see how the negotiation between the TURN server and the Chrome goes.

I know that people are using this TURN server with TLS (I had some correspondence plus some Issues were filed) but I have no idea which client applications they are using.

[pablo platt]

Chrome 34 requires the common name to be the IP instead of the domain.
https://code.google.com/p/chromium/issues/detail?id=306285

In Chrome Canary the turn server works with TLS with or without a proxy.

Thanks