2.0.3 cannot connect to freeswitch wss

One more issue just found out after upgrading from 1.9.5 to 2.0.3.

One of the haproxy backends proxies webrtc connection to a freeswitch:

backend 86_fs_backend
  # Remove the ACL header
  reqdel ^X-Haproxy-ACL
  option httpchk GET /testpage_fs.html
  http-check expect string OK
  balance roundrobin
  cookie appcoookie insert nocache indirect httponly secure
  server sp-useast-001 sp-useast-001.dom.com:8380 ssl ca-file /mnt/s3vol-common/crt/_.86.com.freeswitch-wss.pem cookie sp-useast-001 weight 10 check port 80
  server sp-useast-006 sp-useast-006.dom.com:8380 ssl ca-file /mnt/s3vol-common/crt/_.86.com.freeswitch-wss.pem cookie sp-useast-006 weight 10 check port 80

The certificate is just a simple self-signed one:

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, CN=FreeSWITCH
        Validity
            Not Before: Aug 22 11:11:34 2017 GMT
            Not After : Aug  5 11:11:34 2117 GMT
        Subject: C=US, CN=FreeSWITCH
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption

Browser’s SIPML js code is set to use this websocket url: s_websocket_server_url=wss://86.dom:443/fs
(86.dom is a frontend domain for AWS ELB which sends traffic to haproxy instances)

It used to work well for version 1.9.5:

Jul 31 10:08:32 31.41.x.y:47401 [31/Jul/2019:10:08:24.898] lb-useast~ 86_fs_backend/sp-useast-006 117/1/0/0/3/10/7747 --VN 106/92/7/3/0 0/0 "GET /fs HTTP/1.1" 101 {|||Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770} ireq_size=3398 resp_size=3291 172.30.1.30:443 54.172.x.y:8380 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2

After upgrading to 2.0.3 haproxy is not able to setup connection to the freeswitch:

Jul 31 10:08:19 31.41.x.y:47369 [31/Jul/2019:10:08:19.521] lb-useast~ 86_fs_backend/sp-useast-006 117/1/0/0/1/1/120 --VN 51/51/0/0/0 0/0 "GET /fs HTTP/1.1" 400 {|||Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770} ireq_size=757 resp_size=70 172.30.1.30:443 54.172.x.y:8380 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2

openssl connects to the server without issues:

# echo | openssl s_client -connect 54.172.68.75:8380 -CAfile /mnt/s3vol-common/crt/_.86.com.freeswitch-wss.pem
CONNECTED(00000003)
depth=0 C = US, CN = FreeSWITCH
verify return:1
---
Certificate chain
 0 s:/C=US/CN=FreeSWITCH
   i:/C=US/CN=FreeSWITCH
---
Server certificate
...
subject=/C=US/CN=FreeSWITCH
issuer=/C=US/CN=FreeSWITCH
---
No client certificate CA names sent
---
SSL handshake has read 759 bytes and written 479 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: E8FA7347E6C44E85F0A132C5AA234F31B3CEC3AF77520CB113F6A4EDF9E075ED
    Session-ID-ctx:
    Master-Key: 0E2548DD7E2B2C77B8FB3955EED52D60F9EF577E80C026ED8827554200308CB2A6D495CDFBDB54C4B4582D314B953C71
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
...
    Start Time: 1564569086
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

Any ideas why that happens?

From your logs the SSL connection is fine, but your backend server returns a 400 error response.

I suggest you look into the backend server log to fine out what exactly the server doesn’t like.

You can try disabling HTX by putting no option http-use-htx into the default section - to confirm whether or not htx mode is causing this.

Disabling http-use-htx has fixed the issue! Thank you!

That’s a workaround only.

The legacy mode you are using will be removed from haproxy in 2.1. Troubleshooting why htx mode fails is therefor still required. I suggest you take a look at the server side logs.

I’ve done quick tests with WebSockets and everything seems to work as expected. The error is returned by the server, so there is something your server don’t like in the HTX request. Just an idea. In HTX, all headers are sent in lower case to servers while in the legacy mode the case is unchanged. Be sure your server is fully RFC compliant in this regard.

1 Like