Menu

#1319 Bug: "Unsupported SSL protocol version" Error

closed-fixed
None
5
2015-02-08
2014-01-02
No

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

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2014-01-02
    • status: open --> closed-fixed
    • assigned_to: Daniel Stenberg
     
  • Daniel Stenberg

    Daniel Stenberg - 2014-01-02

    Thanks for your report. This is indeed a bug and we have already fixed in git by Barry Abrahamson since commit 4bb74005298bb0c51

    Case closed!

     
  • Adrian Sandu

    Adrian Sandu - 2014-01-29

    $ 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

     
    • Quanah Gibson-Mount

      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
  • Quanah Gibson-Mount

    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

     
  • Christos Chatzaras

    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

     
  • Andre Nathan

    Andre Nathan - 2015-02-02

    I still have this issue, even with 7.40.0:

    ~/src/curl-7.40.0/src $ ./curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v --tlsv1
    *   Trying 201.18.41.183...
    * Connected to qasecommerce.cielo.com.br (201.18.41.183) port 443 (#0)
    * successfully set certificate verify locations:
    *   CAfile: /etc/ssl/certs/ca-certificates.crt
      CApath: none
    * TLSv1.2, TLS handshake, Client hello (1):
    * Unknown SSL protocol error in connection to qasecommerce.cielo.com.br:443 
    * Closing connection 0
    curl: (35) Unknown SSL protocol error in connection to qasecommerce.cielo.com.br:443
    

    It works fine on older versions like 7.22.0 on Ubuntu 12.04:

    $ curl https://qasecommerce.cielo.com.br/servicos/ecommwsec.do -v --tlsv1
    * About to connect() to qasecommerce.cielo.com.br port 443 (#0)
    *   Trying 201.18.41.183... connected
    * successfully set certificate verify locations:
    *   CAfile: none
      CApath: /etc/ssl/certs
    * SSLv3, TLS handshake, Client hello (1):
    * SSLv3, TLS handshake, Server hello (2):
    * SSLv3, TLS handshake, CERT (11):
    * SSLv3, TLS handshake, Server finished (14):
    * SSLv3, TLS handshake, Client key exchange (16):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSL connection using AES256-SHA
    * Server certificate:
    *    subject: C=BR; ST=Sao Paulo; L=Barueri; O=CIELO S.A.; OU=SI Cielo SS; CN=qasecommerce.cielo.com.br
    *    start date: 2014-08-20 00:00:00 GMT
    *    expire date: 2015-08-20 23:59:59 GMT
    *    subjectAltName: qasecommerce.cielo.com.br matched
    *    issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
    *    SSL certificate verify ok.
    > GET /servicos/ecommwsec.do HTTP/1.1
    > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
    > Host: qasecommerce.cielo.com.br
    > Accept: */*
    > 
    < HTTP/1.1 405 Method Not Allowed
    < Date: Mon, 02 Feb 2015 12:30:04 GMT
    < Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8x
    < Content-Length: 44
    < X-Powered-By: Servlet/2.5 JSP/2.1
    < Content-Type: text/html
    < 
    * Connection #0 to host qasecommerce.cielo.com.br left intact
    * Closing connection #0
    * SSLv3, TLS alert, Client hello (1):
    
     
  • Daniel Stenberg

    Daniel Stenberg - 2015-02-02

    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?

     
  • Andre Nathan

    Andre Nathan - 2015-02-02

    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?

     
  • Jay Satiro

    Jay Satiro - 2015-02-02

    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':

    • SSLv3, TLS handshake, Client hello (1):
    • SSLv3, TLS alert, Server hello (2):
    • error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
    • Closing connection 0
      curl: (35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

    --tlsv1.0 ok:

    • SSLv3, TLS handshake, Client hello (1):
    • SSLv3, TLS handshake, Server hello (2):
    • SSLv3, TLS handshake, CERT (11):
    • SSLv3, TLS handshake, Server finished (14):
    • SSLv3, TLS handshake, Client key exchange (16):
    • SSLv3, TLS change cipher, Client hello (1):
    • SSLv3, TLS handshake, Finished (20):
    • SSLv3, TLS change cipher, Client hello (1):
    • SSLv3, TLS handshake, Finished (20):
    • SSL connection using AES256-SHA

    --tlsv1.1 shows 'Unsupported protocol':

    • SSLv3, TLS handshake, Client hello (1):
    • error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
    • Closing connection 0
      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':

    • SSLv3, TLS handshake, Client hello (1):
    • Unknown SSL protocol error in connection to qasecommerce.cielo.com.br:443
    • Closing connection 0
      curl: (35) Unknown SSL protocol error in connection to qasecommerce.cielo.com.br:443

    Andre please try --tlsv1.0

     
  • Jay Satiro

    Jay Satiro - 2015-02-03

    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, TLS handshake, Client hello (1):
    • TLSv1.0, TLS handshake, Server hello (2):
    • TLSv1.0, TLS handshake, CERT (11):
    • TLSv1.0, TLS handshake, Server finished (14):
    • TLSv1.0, TLS handshake, Client key exchange (16):
    • TLSv1.0, TLS change cipher, Client hello (1):
    • TLSv1.0, TLS handshake, Finished (20):
    • TLSv1.0, TLS change cipher, Client hello (1):
    • TLSv1.0, TLS handshake, Finished (20):
    • SSL connection using TLSv1.0 / AES256-SHA

    --tlsv1.2 shows 'unsupported protocol' and there's no hang:

    • TLSv1.2, TLS handshake, Client hello (1):
    • error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
    • Closing connection 0
      curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
     
  • Andre Nathan

    Andre Nathan - 2015-02-03

    Jay, --tlsv1.0 works fine for me too. In fact I see the exact same behavior you described with the other flags.

     
  • Jay Satiro

    Jay Satiro - 2015-02-06

    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
  • Andre Nathan

    Andre Nathan - 2015-02-06

    Hi Jay

    I can confirm it works with 600ccb2 and OpenSSL 1.0.2.

     
  • Jay Satiro

    Jay Satiro - 2015-02-08

    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