Ruby SSL handshake not receiving Server Hello back - using proxy Net::HTTP

1
votes

I am connecting to an external API using Ruby SSL two way authentication.

My latest script is here:

namespace :rnif_message do
  # With Proxy
  task send_test_index: :environment do
  our_cert         = File.read(File.join(Rails.root, 'ssl', 'invoice', 'test', 'cert20190116_ourcert.der'))
  their_test_cert  = File.read(File.join(Rails.root, 'ssl', 'invoice', 'test', 'testcert2016_theircert.der'))


  cert_store = OpenSSL::X509::Store.new
  # Contains their intermediate CA files
  cert_store.add_path File.join(Rails.root, 'ssl', 'invoice', 'test', 'ca')
  cert_store.add_cert  OpenSSL::X509::Certificate.new(their_test_cert)

  uri = URI("https://xml.digital.com/wm.rn/receive")

  proxy_host = "us-static-02.qg.com"
  proxy_port = "port"
  proxy_user = "user"
  proxy_pass = "pass"

  proxy_request = Net::HTTP.new(uri.hostname, '443', proxy_host, proxy_port, proxy_user, proxy_pass)

  proxy_request.verify_mode = OpenSSL::SSL::VERIFY_PEER
  proxy_request.use_ssl = true
  proxy_request.ssl_version = :TLSv1_2
  proxy_request.ciphers = ["AES256-SHA:AES128-SHA:DES-CBC3-SHA"]

  proxy_request.cert = OpenSSL::X509::Certificate.new(our_cert)
  proxy_request.cert_store = cert_store

  post_request = Net::HTTP::Post.new(uri)

  response = proxy_request.request(post_request)
end

Response back (since I updated the ciphers) is now

OpenSSL::SSL::SSLError: SSL_connect SYSCALL returned=5 errno=0 state=unknown state

Instead of the older from my two previous questions

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

 # /Users/me/projects/proj/lib/tasks/rnif_message_builder.rake:217:in `block (2 levels) in <top (required)>'

Here is my latest wireshark

wireshark

In the initial configuration of my certificate and IP on THEIR server configuration, I may have given them the wrong IP address, so I may be getting blocked by their firewall. Is there ways using openssl s_client I can test this?

So far i've been trying

openssl s_client -showcerts -connect xml.digitaloilfield.com:https

But I am not very familiar with using openssl s_client

Any help on troubleshooting this would be greatly appreciated!

Update

Thanks you very much for your help so far. I am experimenting with those commands you sent me and trying to see what info I can get from them to help me with this. Currently, after they changed my IP address and allowed me through the firewall, I am getting this 

 EOFError: end of file reached /Users/me/projects/xtiri/xtiri.com/lib/tasks/rnif_message_builder.rake:219:in `block (2 levels) in <top (required)>'
1
ruby-on-railsrubysslopensslnet-http
Here's a good example of using client certificates with s_client: “verify error:num=20” when connecting to gateway.sandbox.push.apple.com. – jww

1 Answers

0
votes

This will usually connect to nearly all servers. It uses TLS 1.2 and SNI. That should establish the TCP connection and start the TLS handshake. The handshake may fail later, but that's a different problem.

$ openssl s_client -connect xml.digitaloilfield.com:443 -tls1_2 \
    -servername xml.digitaloilfield.com -debug
<hang>
connect: Connection timed out
connect:errno=110

However, while s_client is hanging, jump over to another terminal and issue:

$ sudo netstat -a | grep openssl
$

Netstat does not show you the SYN_SEND state, so use tcptrack:

$ sudo tcptrack -i eth0
# <next, use s_client>

172.16.2.4:43302      208.38.22.37:443      SYN_SENT     15s    0 B/s

You are in TCP's wait timer. The other side did not perform the three-way handshake with you. In fact, they did not acknowledge your SYN. There could be a few reasons for it, but ...

Given the target, it looks like you encountered a firewall. Rather than Reject'ing connections, it is Drop'ing connections. Its sometimes called "Stealth Mode"; it makes it appear there's no server running on the machine. That's consistent with OpenSSL's connect: Connection timed out message.

The problem could be with the proxy. You really want to run the tests from there, but you probably won't be able to. It could be you are using the ciphers, protocols and ports as specified by the remote site; but the proxy is doing its own thing. Also see Jarmock's SSL Interception Proxies and Transitive Trust.

Here are a couple of references: