curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to domain.com:443

Question

I'm hitting my curl on ubuntu terminal and getting this response curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to domain.com:443 . I really can't understand why it happens. I tried to show curl's error number but it did not revert any no. I am hitting another server. Below is my command :

./curl -i --tlsv1.2 -kv -H "Content-Type: application/xml" --verbose -X POST --data /var/www/html/xml.xml --cacert /root/curl_ssl/curl-7.54.1/src/cert_org.crt domain.com/otp

Please suggest some help.

Appurtenance

I am having this exact problem, but the server supports TLS 1.2 and ECDHE-RSA-AES256-GCM-SHA384. It happens on Ubuntu 20, Debian 11, but works fine on Alpine 3.12 and Windows 11. Did you find the solution? – Soph

Answer 1

For sites that use the old SSL protocol, this error may occur with CURL on Linux. According to the SSL/TLS protocol specification, the reason may be that the client hello uses the support group option that is not supported by the peer. The solution is to use sslscan for probing and get the protocol version and cipher suite supported by the peer. SSLscan (Github)

Boogeyman

Answer 2

When using Docker inside a VM the problem may also be caused by inconsistent MTU-s in the path to the HTTP server. For me the problem was fixed by adding

{
  "mtu": 1450
}

into /etc/docker/daemon.json

(make sure to run systemctl restart docker to get the changes to take effect)

In my case there was an OpenStack VM using MTU of 1450 on its interface, but the docker images still created virtual interfaces with MTU of 1500.

You have an MTU problem if curl hangs after client hello:

https://unix.stackexchange.com/questions/252977/curl-hangs-after-client-hello

Cristinecristiona

Answer 3

I recently ran into this issue when connecting to a micro service on a server. All seemed well and it should have worked but didn't. The error code was:

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ...

Found the root cause.

It is almost certainly the same issue as others have had. A little background... The server is a custom server that uses SSL SNI information to deduce which micro service it should route the TLS connection to. The sequence of events is:

1. TCP connects.
2. SSL handshake starts.
3. SNI is inspected and TLS session is not initiated.
4. New socket is opened to listening micro service.
5. Original handshake packet is forwarded as a TCP/TLS connection to micro service.

In my case the proxy server was not able to find the correct endpoint due to a combination error of wrong SNI info and incorrectly configured back-end. Hence the proxy closes the socket, in the middle of the handshake and you get error 35.

I suspect this happens with HAProxy non-terminated connections when, for example; the front end picks up, inspects SNI and the TCP backend is either not configured, can't be found, or the backend service is not running and can't be connected to.

For those having this issue, make sure that all of the above are correctly setup. In my case it was a single character typo causing the grief. Presumably other issues such as a bad certificate could also cause similar errors. I've gotten 28, 35, and a few others. All are related and resolved once the config is correct.

Hope this helps.

Nodular

Answer 4

The problem is that the site supports only ciphers that are no longer considered secure, i.e. ciphers based on 3DES and RC4. The default ciphers in the ssl library do not include these ciphers for security reasons.

To add support for these ciphers, you can manually set the default cipher Suite. The next line sets DES-CBC3-SHA as the proposed cipher.

curl --cipher DES-CBC3-SHA <your parameters>

Use this for all sites is not safe. Note that this option should only be used for this legacy site.

UPD

Use openssl ciphers to list the available ciphers available to be used with curl (thanks MarkBarry)

Scherzo

curl: (59) failed setting cipher list: DES-CBC3-SHA – Soph

This is happening due to addition of parameter in the end of curl request. try adding right after curl word – Signorino

Use openssl ciphers to list the available ciphers available to be used with curl. – Cursorial

Answer 5

I was facing similar issue when trying to curl git url.

Here's what I was running.

C:\Users\AWSAmazonCntAppIDDEV>"C:\Users\AWSAmazonCntAppIDDEV\Desktop\curl-7.78.0-win64-mingw\curl-7.78.0-win64-mingw\bin\curl.exe" -v https://gitlab.ff.xxxx-dns.com/users/sign_in
* Uses proxy env variable no_proxy == '*.xx.ffff-dns.com'
* Uses proxy env variable https_proxy == 'web-proxyapp.xx.ffff-dns.com:3128'
*   Trying 100.424.xxx.xx:3128...
* Connected to web-proxyapp.xx.ffff-dns.com:3128 (192.168.216.93) port 3128 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to gitlab.xx.ffff-dns.com:443
> CONNECT gitlab.us.bank-dns.com:443 HTTP/1.1
> Host: gitlab.xx.ffff-dns.com:443
> User-Agent: curl/7.78.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: C:\Users\AWSAmazonCntAppIDDEV\Desktop\curl-7.78.0-win64-mingw\curl-7.78.0-win64-mingw\bin\curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlab.xx.ffff-dns.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gitlab.xx.ffff-dns.com:443

After talking the the network team, they said since this is a local intranet URL, so there's no need to tunnel it through the proxy.

So removing the proxy from environment variables on the computer fixed the issue. Let me know if you need more clarification.

Alger

Answer 6

If you are requesting from an nginx server that expects to be behind a reverse proxy (utilizing proxy_protocol) you should add --haproxy-protocol to your curl command

Diplex

Answer 7

You may be too slow to sand a request/headers to the server and it decides to close the connection.

This happened to me when I was testing a nginx server config for serving static files. I decreased the client_header_timeout configuration setting too much for the load/amount of processes I was running. The connections where closed by the server resulting in that error message on the client.

Esperanzaespial