Ssl_Connect Syscall Returned=5 Errno=0 State=Sslv2/V3 Read Server Hello a - Faraday::Error::Connectionfailed

SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A - Faraday::Error::ConnectionFailed

Thanks to @mislav who give the hint to change SSL version.

I had to change this because my partner has its application built using asp.net and uses this version of SSL. More info at https://mislav.net/2013/07/ruby-openssl/

So the final code is as follows:

Rails.application.config.middleware.use OmniAuth::Builder do
client_id = 'my_client_id'
client_secret = 'secret'

ssl_options = {}
ssl_options[:version] = :TLSv1

ssl = {}
ssl[:ssl] = ssl_options

provider :partner, client_id, client_secret,
client_options: { connection_opts: ssl} ,
setup: ->(env){
req = Rack::Request.new(env)
token_url = "https://#{req.params.fetch('shop')}"
env['omniauth.strategy'].options[:client_options][:token_url] = token_url
}
end

Excon::Error::Socket: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A (OpenSSL::SSL::SSLError)

It works when I switch from windows to Linux.

OpenSSL::SSL::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 read server hello A

This is a problem at the server site. It looks like the server is exclusively accepting TLS 1.2 and does not show the usual behavior when the client requests something lesser (like downgrading or sending SSL alert) but instead just closes the connection.

TLS 1.2 is not supported by OpenSSL 0.9.8 and additionally your code enforces SSLv3. You get TLS 1.2 only when upgrading to OpenSSL 1.0.1.

Some browsers will also fail to connect to this server, even if they have ways to work around such broken servers. But while Firefox will only try to downgrade the connection to lesser SSL version (which often helps) Chrome manages to connect with TLS 1.2.

Edit: I've analyzed the issue further and now I cannot get a connection with TLS1.2 anymore but I can get a connection with TLS1.0 or SSL3.0, but only if the ciphers is hard coded to RC4-SHA. I've tried others like AES128-SHA or DES-CBC3-SHA and they don't work.
So while it looks like a really messed up system explicitly setting

http.ssl_version = 'TLSv1'       -- or SSLv3, but TLSv1 is better
http.ssl_cipher = 'rc4-sha'

should work. I'm not a ruby user so the exact syntax might differ, but I've tested with OpenSSL s_client.

ERROR -- : Caught an error during Google geocoding call: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A

I wasn't going to comment but no one has posted anything. Since your particular error message included an SSL warning, I would check if you need to explicitly require openssl and/or that your openssl setup is correct. I've had a similar problem with geocoding timing out in my application though the stack trace was a bit different. It took a long time for the Geocoding to complete (because the address was really weird for example) but the rest of my code kept going. I think the stack trace is a bug in Geokit. Since you don't have control over how fast this runs you should consider first of all doing something to reduce the number of times you're making this call, so at a bare minimum:

def full_address
@full_address ||= Geocoder.address("#{self.latlon.x}, #{self.latlon.y}")
end

You should also consider storing full_address as a calculated field since the above code will still run every time that instance of the model is accessed the first time. So getting rid of the code above and instead adding a full_address field and a before save hook:

in a migration file:

add_column :models, :full_address, :string

and in your model.rb:

before_save :geocode_address

def geocode_address
self.full_address = Geocoder.address("#{self.latlon.x}, #{self.latlon.y}") if self.changed.include?("latlon")
end

This way the call only runs when the latlon.x and latlon.y variables are updated, not every time the address is accessed.

Connecting using https to a server with a certificate signed by a CA I created

I assume that your Tomcat doesn't like the protocol version that Ruby tries to negotiate. Ruby uses SSLv23 by default, but I've heard other cases where this was a problem for Java-based web servers. The error message you are getting indicates that the handshake fails while setting up the connection and trying to read the server's response. Try adding either

http.ssl_version = :TLSv1

or

http.ssl_version = :SSLv3

and see if that already helps.

If this does not fix the problem yet, it would be very interesting to see why your server rejects the connection attempt. Try running your Tomcat with -Djavax.net.debug=ssl and please post the relevant parts (connection information, exception stacktrace) as to why the attempt fails.



Related Topics



Leave a reply



Submit