Since I have upgraded from version 7.33 to 7.34, I am getting "Unsupported SSL protocol version" error with SSLv3.
In order to reproduce the problem, run the command:
curl -v -3 -g 'https://aur.archlinux.org/'
Following output error will be showin in my machine:
Hostname was NOT found in DNS cache
Adding handle: conn: 0x237e040
Adding handle: send: 0
Adding handle: recv: 0
Curl_addHandleToPipeline: length: 1
- Conn 0 (0x237e040) send_pipe: 1, recv_pipe: 0
Trying 78.46.78.247...
Trying 2a01:4f8:120:34c2::2...
Immediate connect fail for 2a01:4f8:120:34c2::2: Network is unreachable
Connected to aur.archlinux.org (78.46.78.247) port 443 (#0)
Unsupported SSL protocol version
Closing connection 0
curl: (35) Unsupported SSL protocol version
My System Info:
$curl -V
curl 7.34.0 (x86_64-unknown-linux-gnu) libcurl/7.34.0 OpenSSL/1.0.1e zlib/1.2.8 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
$uname -a
Linux mohammad-tp 3.12.6-1-ARCH #1 SMP PREEMPT Fri Dec 20 19:39:00 CET 2013 x86_64 GNU/Linux
Thanks for your report. This is indeed a bug and we have already fixed in git by Barry Abrahamson since commit 4bb74005298bb0c51
Case closed!
$ curl https://www.lynda.com/ -v
Hostname was NOT found in DNS cache
Trying 69.20.127.243...
Connected to www.lynda.com (69.20.127.243) port 443 (#0)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs SSLv3, TLS handshake, Client hello (1):
Unknown SSL protocol error in connection to www.lynda.com:443
Closing connection 0
curl: (35) Unknown SSL protocol error in connection to www.lynda.com:443
$ curl -V
curl 7.27.0 (x86_64-unknown-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
This is because you are using libcurl 7.35.0... Try updating your libcurl version to 7.36.0
Last edit: Quanah Gibson-Mount 2014-05-01
This still appears to be broken in some cases with 7.36.0:
/opt/zimbra/curl/bin/curl --version
curl 7.36.0 (x86_64-unknown-linux-gnu) libcurl/7.36.0 OpenSSL/1.0.1f zlib/1.2.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
/opt/zimbra/curl/bin/curl -vvv --cacert /opt/zimbra/conf/ca/ca.pem https://mail.company.com:7071
Rebuilt URL to: https://mail.company.com:7071/
Hostname was NOT found in DNS cache
Trying 1.2.3.4...
Connected to mail.company.com (1.2.3.4) port 7071 (#0)
successfully set certificate verify locations:
CAfile: /opt/zimbra/conf/ca/ca.pem
CApath: none
SSLv3, TLS handshake, Client hello (1):
Unknown SSL protocol error in connection to mail.company.com:7071
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to mail.company.com:7071
This worked fine with curl/libcurl 7.31.0
I have the same issue:
curl https://www.vivapayments.com/ -v
Hostname was NOT found in DNS cache
Trying 162.13.22.246...
Connected to www.vivapayments.com (162.13.22.246) port 443 (#0)
successfully set certificate verify locations:
CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none SSLv3, TLS handshake, Client hello (1):
Unknown SSL protocol error in connection to www.vivapayments.com:443
Closing connection 0
curl: (35) Unknown SSL protocol error in connection to www.vivapayments.com:443
I still have this issue, even with 7.40.0:
It works fine on older versions like 7.22.0 on Ubuntu 12.04:
I tried both 7.38.0 on my debian and 7.41.0-DEV and they work fine. Using OpenSSL/1.0.1k
Which OpenSSL version are you using?
I tried 7.35 from Ubuntu Trusty, 7.38 from Ubuntu Vivid and 7.40 compiled from source.
Does the command above (
curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v --tlsv1
) work for you?I can confirm what Andre reported in Ubuntu 14 x64 with OpenSSL 1.0.1f. I did a bisect and it traces back to https://github.com/bagder/curl/commit/ad34a2d I think because that's where the TLS protocol maximum version becomes TLSv1.2.
The server identifies as Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8x. AFAIK 0.9.8 cannot use TLSv1.1 or TLSv1.2. The server does accept TLSv1.0. I don't know why it hangs on a maximum value of TLSv1.2, hopefully someone can fill us in on this.
OpenSSL s_client hangs as well, tested Windows 7 x64/OpenSSL 1.0.1j and Ubuntu 14 x64/OpenSSL 1.0.1f:
openssl s_client -connect qasecommerce.cielo.com.br:443
Loading 'screen' into random state - done
CONNECTED(0000019C)
write:errno=10054
-debug shows no server hello received in response to the client hello. Adding -bugs fixes it though...
I checked curl tool built from ad34a2d with every protocol version for that server, here are the results.
curl 7.33.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.33.1-DEV OpenSSL/1.0.1f zlib/1.2.8
src/curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v
--sslv3 shows 'wrong version number':
curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
--tlsv1.0 ok:
--tlsv1.1 shows 'Unsupported protocol':
curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
--tlsv1 and --tlsv1.2 there's a hang after client hello, then shows 'Unknown SSL protocol':
curl: (35) Unknown SSL protocol error in connection to qasecommerce.cielo.com.br:443
Andre please try --tlsv1.0
I did the same protocol tests in Windows 7 x64 with curl and --tlsv1 works fine...
curl 7.40.0-DEV (i386-pc-win32) libcurl/7.40.0-DEV OpenSSL/1.0.1j
--tlsv1.2 shows 'unsupported protocol' and there's no hang:
curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
Jay, --tlsv1.0 works fine for me too. In fact I see the exact same behavior you described with the other flags.
Andre, using commit 600ccb2 2015-02-05 with OpenSSL 1.0.2 works in both Ubuntu 14.04 x64 and Windows 7 x64. I think they made some change in OpenSSL since 1.0.1f. I will run wireshark at some later time to find out the differences. Can you try 600ccb2 from the repo with OpenSSL 1.0.2? I made static builds of both:
cd openssl-1.0.2
./config
make
sudo make install
/usr/local/ssl/bin/openssl version -a
# OpenSSL 1.0.2 22 Jan 2015
cd ../curl
./buildconf
LIBS=-ldl ./configure --with-ssl=/usr/local/ssl --disable-shared
make
sudo make install
curl --version
# curl 7.41.0-DEV (x86_64-unknown-linux-gnu) libcurl/7.41.0-DEV OpenSSL/1.0.2 zlib/1.2.8
curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v --tlsv1
Last edit: Jay Satiro 2015-02-06
Hi Jay
I can confirm it works with 600ccb2 and OpenSSL 1.0.2.
My final follow up on this, a comparison of the client hellos can be found at https://www.diffchecker.com/k5eq1piw
The server hangs with the 1.0.1f client hello but replies with the 1.0.2 client hello. The record for 1.0.1f has a description of 'SSL Record Layer' instead of 'TLSv1 Record Layer' because that's how Wireshark classifies the client hello when there's no server hello reply.
Interesting the OpenSSL 1.0.2 tool the server still hangs when -bugs isn't specified but I didn't take a capture of that.
TL;DR notes
After sorting the ciphers added and removed nothing was actually removed. 20 TLS_DH_ ciphers and 1 TLS_RSA_WITH_IDEA_CBC_SHA were added for OpenSSL 1.0.2.
If I specify a single common cipher I can get a connection. For example curl,libcurl 05792d6 2015-02-06 with OpenSSL 1.0.1f this works:
curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v --tlsv1 --ciphers AES256-SHA
I'm not sure what's going on here entirely but it's probably a cipher issue. If you're interested in pursuing this further you could do a git bisect in the OpenSSL repo. To do that the easiest way would be to build a shared libcurl and curl tool against your installed shared openssl, if you don't have all that already. Then you build your replacement SSL libs but you wouldn't have to install them each time you'd just override the location using LD_PRELOAD
Terminal window 1:
export LD_PRELOAD=/your-openssl-repo/libcrypto.so.1.0.0:/your-openssl-repo/libssl.so.1.0.0
confirm using ldd and curl --version that it's using your just built openssl
Terminal window 2:
Run the bisect and rebuild openssl each time.
git bisect start
git bisect good OpenSSL_1_0_2
git bisect bad OpenSSL_1_0_1f
make clean
(whatever bootstrapping is required)
./config shared
make
Terminal Window 1:
curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v --tlsv1
Terminal Window 2:
Based on the result in term 1 mark the commit good or bad. You may have to run bisect skip if there's a commit that doesn't build or the sos don't load properly to skip it. And there's a way to automate the whole thing with a run script you pass to bisect. Check the man page for all that.
Also I found a similar 'unsupported protocol' report:
http://stackoverflow.com/q/13463782
Last edit: Jay Satiro 2015-03-23