Execute FAIL-s SSL-VERIFY for Google Translate

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Patch the standard Ruby HTTP.rb temporarily with the following debug 
expediencies, in HTTP.rb (attached):
  *  Changes tagged = :$wm001
  *  Also the debug output D has been patched to identify the module with "[h]".
2. Note the hack in HTTP::connect( ) 
    self.verify_mode = OpenSSL::SSL::VERIFY_NONE   if defined? $wm001
    self.verify_mode = OpenSSL::SSL::VERIFY_PEER   if defined? $wm002
    D "[h] With SSL, verify-mode: #{self.verify_mode}"

3. Run attached file: (demo.rb)
4. Observe success from the Execute call over SSL.

5. Edit demo.rb to uncomment "$wm002" definition.
7. Run demo.rb again
8. Observe translation fails and that 'verify_mode' is OpenSSL::SSL::VERIFY_PEER

9. This is one party of a larger scenario.  The Ruby::Net module doesn't seem 
to encourage using OpenSSL::SSL::VERIFY_PEER.  At least using it isn't easy.  
(See expected output).

What is the expected output? What do you see instead?

1(a). A warning -- When a HTTPS web service is (abused/used) WITHOUT using the 
OpenSSL::SSL::VERIFY_PEER site validation.  I won't say it is an error because 
there are good reasons to not choose to verify such as testing or debugging.  
There ought to be a report of this 'use' as a warning level error or as 
information.

1(b).  Keep support for the VERIFY_PEER site validation.  It is useful (see #2 
and #3 below).  Just Alert folk.  For example point #3(c) would permit the 
Google-API-Ruby-Client to enforce (or at least, monitor) SSL::VERIFY_PEER for 
'Production' class API access.

2. Some Diagnostics on Error -- Validation fails when using VERIFY_PEER, I see 
that as a Ruby (:Net module) problem myself, though I accept that others may 
disagree. 

  Nonetheless, there will also be situations whereby a Google-Api client may choose to use or nominate a specific alternative CA-Bundle or PEM certificate file.  When verification fails, it would help if the API gem can report the 'active' applied Certificate Authority and the source file (.PEM) or bundle (.CRT)

3. Option to (a) turn-on diagnostics and (b) some service level diagnostics.  

3(a). Using any API can be a problem (there will be bugs).  My personal 
experience with web services is that if you can't see 'behind the veil' then it 
takes a VERY long time to resolve non-trivial problems.  Diagnostics at the 
Google-API-Ruby-Client Gem level are essential because this is a Remote 
Operations sub-layer that mediated to all kinds of services (as I understand 
the intention in the source I've scanned).  It is going to be busy.  

3(b). Where a service (such as gmail) supports some extra logging, diagnostics 
or other debugging help -- Provide a way to expose that.  My preference would 
be for a generic diagnostics API supported by the gem.  NIL or "not 
implemented" place holders can be used for service that don't do diagnostics.  
I'd also recommend instrumentation and statistics features (e.g. 
response-turn-around-time) if you like that.

3(c) Pass these comments 'down' the stack for API implementers.  I don't see 
diagnostics and instrumentation being a main-line thing, rather I'm speaking to 
the idea of distinct modes, like: 'Test' and 'Development', 'Prototype' or 
'Alpha' modes for the interface API-s themselves.  I'd go further myself and 
provide that level of access vial the existing Key mechanism.  So I can have my 
API-key and alpha mode might use the key as KEYSTRING(alpha) or some such 
enhancement.  That way the google overlords can 'monitor' the use and get other 
market-level metrics like 'how challenging was my API for clients'?

What version of the product are you using? On what operating system?

-- Google-API-Ruby-client v0.1.3
-- Ruby v1.9-p180
-- jRuby v1.5
-- Ruby v1.8.7
-- Windows/XP sp3
-- Java (windows) 1.6.0_22-b04

Please provide any additional information below.

Please consider commenting on the Stack Overflow question I posted relating to 
this issue: 

* Ruby OpenSSL Set-up or Configuration for your Application Code
   -- http://stackoverflow.com/questions/5233169/ruby-openssl-set-up-or-configuration-for-your-application-code

I think as people implementing a sound API layer atop a network protocol, you 
have good insight into what's needed.  As an aside, I'm afraid people on *nix 
and PC-s have become spoilt.  In the old-times on mainframes we regularly used 
client API-keys for even for on-board library access to system services and 
secure resources.  

Btw, most of my observations here about about how to use the SSL better, I've 
not got a complaint about the API gem's workings.  It seems like the Service or 
ROSE layer need not be too involved with the network when it works sufficiently 
well.

Thanks ... w.

Original issue reported on code.google.com by William....@gmail.com on 9 Mar 2011 at 4:44

Attachments:

• demo.rb
• http.rb

[GoogleCodeExporter]

Original comment by bobaman@google.com on 11 Mar 2011 at 7:32

[GoogleCodeExporter]

I won't be downgrading SSL verification errors to warnings.  However, I will be 
exposing more of the internals for configuration to allow developers to make 
adjustments as necessary.  You may find that using Typhoeus or some other HTTP 
stack other than Net::HTTP might be beneficial.  The httpadapter gem that the 
client uses makes swapping out the HTTP stack pretty trivial.  Note that I'm 
currently in the process of making some sweeping changes to httpadapter though 
(mostly to enable the configuration changes I mentioned) so expect that gem to 
be unstable for a bit.

Original comment by bobaman@google.com on 11 Mar 2011 at 7:38

[GoogleCodeExporter]

Hi Bob.  

I don't think you can 'blame' the stack.  The API call works fine in the first 
instance.  It is ONLY later on when the google-api-ruby-client code calls 
translate in 'execute()' that the wheels fall off.

My guess is the second connection swaps in or uses a variable that has been set 
to Nil initialised, or released.  Both connections seem to be using SSL, and 
only one, the second doesn't work.  That's why I'm thinking the stack itself is 
OK (besides, lots and lots of code use the Net::HTTP module with little drama).

w

Original comment by William....@gmail.com on 11 Mar 2011 at 11:57

[GoogleCodeExporter]

I just updated the httpadapter gem to allow things like this:

adapter = HTTPAdapter::NetHTTPAdapter.new do |http|
  # You should never actually do this.  But you could.
  http.connection.verify_mode = OpenSSL::SSL::VERIFY_NONE
end

Or this:

adapter = HTTPAdapter::NetHTTPAdapter.new do |http|
  http.connection.ca_file = 'cacert.pem'
end

I'll be updating the rest of the gems to use this new way of using HTTP 
adapters shortly.

I'm not actually going to draw any conclusions about the code you posted in 
this issue because your environment is still the root of the problem.  However 
this code change should allow you to work-around the SSL issues you're having 
and/or debug them more easily.  Once the remainder of the updates I'm doing are 
in place, I'll be happy to help you further diagnose the issue.

Original comment by bobaman@google.com on 12 Mar 2011 at 12:59

[GoogleCodeExporter]

The client has been updated to use the latest version of HTTP adapter, which 
allows for the new functionality described above.

Original comment by bobaman@google.com on 4 May 2011 at 12:32

• Changed state: Fixed
• Added labels: Type-Enhancement
• Removed labels: Type-Defect