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/894506

---
** [bugs:#1319] Bug: "Unsupported SSL protocol version" Error**
**Status:** closed-fixed
**Created:** Thu Jan 02, 2014 07:44 PM UTC by Mohammad Hossekh Sekhavat
**Last Updated:** Fri Feb 06, 2015 06:10 PM UTC
**Owner:** Daniel Stenberg
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
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.