WARNING: Upgrading openssl to 1.0.1 may stop GeoToad to work!

[GoogleCodeExporter]

What steps will reproduce the problem?
[Please include the relevant parts of your command line, if applicable.
Don't send your password though!]
1.
2.
3.

What is the expected output? What do you see instead?
[If possible, include the last ~10--20 lines of verbose output.]

What version of the product are you using? On what operating system?
[Did you check you're using the latest version?]

Please provide any additional information below.

Original issue reported on code.google.com by Steve8x8 on 30 Mar 2012 at 12:51

[GoogleCodeExporter]

Yeah, I managed to send off an empty report. So let me start from scratch:

Today, my Debian Wheezy box, in the course of a routine update, got a new 
openssl (1.0.1).
GeoToad stopped working on the spot.
I found that it's actually *not* a GeoToad issue, but a general one, in the 
sense that ruby in general is affected, and so is curl:

$ ruby -ropen-uri -e open("https://www.geocaching.com/")
/usr/lib/ruby/1.9.1/net/http.rb:799:in `connect': Connection reset by peer - 
SSL_connect (Errno::ECONNRESET)
    from /usr/lib/ruby/1.9.1/net/http.rb:799:in `block in connect'
    from /usr/lib/ruby/1.9.1/timeout.rb:54:in `timeout'
    from /usr/lib/ruby/1.9.1/timeout.rb:99:in `timeout'
    from /usr/lib/ruby/1.9.1/net/http.rb:799:in `connect'
    from /usr/lib/ruby/1.9.1/net/http.rb:755:in `do_start'
    from /usr/lib/ruby/1.9.1/net/http.rb:744:in `start'
    from /usr/lib/ruby/1.9.1/open-uri.rb:306:in `open_http'
    from /usr/lib/ruby/1.9.1/open-uri.rb:775:in `buffer_open'
    from /usr/lib/ruby/1.9.1/open-uri.rb:203:in `block in open_loop'
    from /usr/lib/ruby/1.9.1/open-uri.rb:201:in `catch'
    from /usr/lib/ruby/1.9.1/open-uri.rb:201:in `open_loop'
    from /usr/lib/ruby/1.9.1/open-uri.rb:146:in `open_uri'
    from /usr/lib/ruby/1.9.1/open-uri.rb:677:in `open'
    from /usr/lib/ruby/1.9.1/open-uri.rb:33:in `open'
    from -e:1:in `<main>'

$ openssl version -a
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Mar 19 19:39:04 UTC 2012
platform: debian-i386-i686/cmov
options:  bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -march=i686 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

$ curl -Iv https://www.geocaching.com/
* About to connect() to www.geocaching.com port 443 (#0)
*   Trying 66.150.167.189...
* connected
* Connected to www.geocaching.com (66.150.167.189) 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.geocaching.com:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to www.geocaching.com:443 

I have found related reports, and will try to identify the underlying problem. 
As Debian Wheezy is "testing", this issue may vanish within a couple of days 
(but it's still confusing).

For now, it's better to "hold" the openssl and libssl1.0.0 packages.

Original comment by Steve8x8 on 30 Mar 2012 at 12:56

• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

Reverting to 1.0.0h resolves the issue.
Don't forget to "hold" the packages "openssl" and "libssl1.0.0" (and, if you 
decide so, "libssl-dev" and "libssl-doc").

Note that there's no fix on the GeoToad level as long as curl is also affected 
(and ruby's low-level stuff).

Original comment by Steve8x8 on 30 Mar 2012 at 1:17

• Changed state: Accepted

[GoogleCodeExporter]

*If* you want to try a small patch - which seems not to harm GeoToad operation 
with openssl 1.0.0h - with openssl 1.0.1, here you are:

--- shadowget.rb.ORIG   2012-03-31 18:10:24.000000000 +0200
+++ shadowget.rb        2012-03-31 18:01:36.000000000 +0200
@@ -246,6 +246,11 @@
       http = Net::HTTP.new(uri.host, uri.port)
     end
     if uri.scheme == 'https'
+      # for openssl 1.0.1+: limit to TLS 1.0 since gc doesn't renegotiate
+      # source:
+      # 
http://www.velocityreviews.com/forums/t860716-how-to-use-tls1-but-not-sslv2-3-in
-https.html
+      # 
http://compgroups.net/comp.lang.ruby/how-to-use-tls1-but-not-sslv2-3-in-https/21
3754
+      http.instance_eval { @ssl_context = OpenSSL::SSL::SSLContext.new(:TLSv1) 
}
       http.use_ssl = true
       http.verify_mode = OpenSSL::SSL::VERIFY_NONE
     end

(to be applied inside the lib/ directory; patch is also attached). Feedback is 
appreciated! To be honest, I don't completely understand what's going on but 
this openssl thing has the potential to be a BIG show-stopper with a lot of 
HTTPS servers out there...

Original comment by Steve8x8 on 31 Mar 2012 at 4:14

Attachments:

• shadowget.tls.diff

[GoogleCodeExporter]

Diving deeper into the details of SSL connection negotiation, I became aware 
that my first approach was too simplistic and very prone to random (!) failure.
Since I meanwhile had reverted the upgrades of openssl and libssl Debian Wheezy 
packages, and put them on hold, I wasn't too worried...
... until today there was another update, to both packages as well as curl and 
its libs.
Which I installed, of course.
Which turned out to be desastrous to my daily work, despite the preliminary 
patch above.
So after going back again, I decided to finally find out what was going on, and 
how to fix that.
First I recognized that "large headers" would be an issue, and TLS1.2 support 
in OpenSSL 1.0.1 was only triggering a problem that had been hiding for quite a 
long time - actually, the longer list of negotiable ciphers seemed to have 
caused a couple of servers to choke.
Going back to a blog article from 2009, I found how to limit the list of 
ciphers to the one that was negotiated with older OpenSSL versions: RC4-SHA. 
For me, that choice brought the final breakthrough even with . As always, YMMV 
- that's why I'd like to ask you to test the patch (which has been committed to 
branch as r1122 as well). Please give feedback by email or twitter (@GeoToad_).

Original comment by Steve8x8 on 15 Apr 2012 at 6:16

• Changed state: Started

Attachments:

• 237-force_TLSv1.diff

[GoogleCodeExporter]

Issue 240 has been merged into this issue.

Original comment by Steve8x8 on 23 Apr 2012 at 10:22

[GoogleCodeExporter]

Will be in 3.16.0

Original comment by Steve8x8 on 2 May 2012 at 1:22

• Changed state: FixAvail

[GoogleCodeExporter]

If you run into OpenSSL problems while using Ruby 1.8, please try 1.9 before 
complaining. (Part of the fix only works with recent ruby versions.)

Original comment by Steve8x8 on 25 May 2012 at 12:26

• Changed state: Fixed