I am writing a soap request over SSL using Savon and HTTPi, a Ruby soap client and an interface for Ruby HTTP clients, respectively. Here's the code:
client = Savon::Client.new(original_class.constantize.wsdl_url)
client.http.auth.ssl.cert_key_file = "path_to_the_key"
client.http.auth.ssl.cert_key_password = 'secret'
client.http.auth.ssl.cert_file = "path_to_the_certification"
client.http.auth.ssl.verify_mode = :none
#response = client.request :ins0, action do
soap.body = encoded_body
end
That's the only way I get this to work. But, I know that there is three others verify modes, which are:
:peer (SSL_VERIFY_PEER)
:fail_if_no_peer_cert (SSL_VERIFY_FAIL_IF_NO_PEER_CERT)
:client_once (SSL_VERIFY_CLIENT_ONCE)
If I change the verify mode to any other of the above, I get this error:
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
Then comes my questions (among others I have):
Am I doing wrong if I keep the verify mode to :none? Is there any lack of security?
What does the error really mean? That my code is wrong or that my certificate (which is self-assigned --- I am in development environment) is not good?
I read the OpenSSL documentation about verify modes:
http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html
About SSL_VERIFY_NONE, on Client Mode, says:
The result of the certificate verification process can be checked
after the TLS/SSL handshake using the SSL_get_verify_result(3)
function. The handshake will be continued regardless of the
verification result.
Should I be worried about it? Should I see verify mode :none as a dangerous thing?
I am asking that because since I can't make it work with the others verify modes, I would like to release the soap request over SSL feature the way it is working now. But I surely wouldn't do it if that could be dangerous.
It is NOT safe to set verify mode to :none (SSL_VERIFY_NONE). This opens up the code to being susceptible to man-in-the-middle attacks. With :none, there will be not server authentication. If an attacker intercepts the connection from my client, my client will not detect the difference and will give any sensitive data communicated through this socket to the attacker.
The mode flags :fail_if_not_peer_cert and :client_once are only for a server; meaning nothing to the client, it ignores them.
For client purpose, :peer (SSL_VERIFY_PEER) is the only one the matters. In order to use :peer, I need to have the root certificate used by the certificate in the client trustedstore.
A big thanks to Dave Thompson from OpenSSL User Support Mailing List. After I joined this list, I finally got help.
Related
I am trying to connect via TCP socket to an old, unmaintained game server. When I try to do so using OpenSSL and Socketry, I get following error.
hostname "xxx" does not match the server certificate
This is how my code works.
ssl_context = OpenSSL::SSL::SSLContext.new
ssl_context.verify_mode = OpenSSL::SSL::VERIFY_NONE
ssl_context.ciphers = "AES128-SHA"
ssl_context.cert = OpenSSL::X509::Certificate.new(File.open("certificate.crt"))
ssl_context.key = OpenSSL::PKey::RSA.new(File.open("certificate.key"))
socket = Socketry::SSL::Socket.new(ssl_context: ssl_context)
socket.connect(address, port)
I've had to force cipher to AES128-SHA, as otherwise I would get a different error.
SSL_connect returned=1 errno=0 state=error: dh key too small (OpenSSL::SSL::SSLError)
How can I bypass these errors and just force connection to said server? The certificate itself has expired 10 years ago.
Socketry doesn't include much documentation about this, so you need to turn to the source. Depending on exactly what you're trying to do, you might try one of the following:
Passing verify_hostname: false to Socket#connect.
Rescuing Socketry::SSL::HostnameError yourself.
Rescuing Socketry::SSL::CertificateVerifyError.
At least one of these ought to address your specific issue. If not, the source offers other places you might monkey-patch or refine for your use case.
I am relating to Application and invalid certificate errors
When i initiate the call with Twilio REST API, and then pick up the phone, i can hear that error occured and Certificate Invalid - Could not find path to certificate appears in my alert dashboard.
However, certificate is located in the mozila certificate program, i can find certificate at Public All Intermediate Certs List. I dont use self signed certificate.
As soon as i disable SSL Certificate Validation inside Twilio Console Account settings, the problem is gone.
My result from qualys ssl lab are:
Summary:
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
This server accepts RC4 cipher, but only with older protocols. Grade capped to B.
The server does not support Forward Secrecy with the reference browsers.
This server's certificate chain is incomplete. Grade capped to B.
Configuration:
SSL 3 INSECURE
Cipher Suites:
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 4096 bits FS WEAK
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE
Protocol details:
Secure Renegotiation Supported
POODLE (SSLv3) Vulnerable INSECURE SSL 3: 0xa
Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported
RC4 Yes INSECURE
Forward Secrecy With some browsers
Shall i disable SSL or do you have any ideas what can i do?
Twilio developer evangelist here.
I am hoping that your https://ssllabs.com/ssltest has scared you sufficiently enough. You need to upgrade your server from SSLv3 to TLS as SSLv3 and a lot more of your setup is insecure and will not protect you in the face of an attack.
Twilio has deprecated support for SSLv3 and supports TLS. This is likely why you are getting an invalid certificate error.
For the sake of your and your users own security and safety, please upgrade your server.
SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: sslv3 alert handshake failure (OpenSSL::SSL::SSLError)
This error is a pretty common one to anyone using ruby on windows.
For me, the solution has always been this. It has worked great on any computer I have put it on and I've loved it.
Just this week it stopped working. Has anyone else had this happen?
I've tried getting the cert from curl again just in case the cert was no longer valid. I tried removing and adding the environmental I use mechanize and tried to reference it as suggested here.
I've also tried going to different urls, "https://google.com" and others, for example.
Nothing so far. Anyone have a better solution for this? It has happened on all windows computers that I have this cert referenced this way.
Your problem seems to be different to the one you linked to. There it failed to verify the certificate returned by the server. Here it erros earlier when it reads the server hello. Do you have any more debug information eg stacktrace or a pcap of the interaction?
A (highly) speculative explanation is that you sent an sslv2 compatible client hello and the server returned an ssl alert as it will only accept sslv3/tls format client hello
I have a Ruby polling script that runs on a set of servers in an IP range. I very strongly prefer to do this polling by IP address, not by hostname, because:
1) I have defined IP address ranges to poll, and hostnames are arbitrary/change a lot
2) Because they change a lot, most of the hostnames do not have a reverse DNS lookup, so I can't engineer a list of hostnames from IPs
Before our web servers had no problem with this polling, but on a new server that does not accept SSLv3 communication, this is the error I get when I run my poll:
/home/dashboard/.rvm/rubies/ruby-2.1.6/lib/ruby/2.1.0/net/http.rb:923:in `connect': SSL_connect returned=1 errno=0 state=unknown state: tlsv1 unrecognized name (OpenSSL::SSL::SSLError)
On the server side, this is the error:
nss_engine_init.c(1802): start function ownSSLSNISocketConfig for SNI
nss_engine_init.c(1827): Search [val = 172.16.99.18] failed, unrecognized name
When I run the poll with hostname, everything works fine.
Here is the crux of the HTTP Client code in Ruby:
def init_http(url)
uri = URI.parse(url)
http = Net::HTTP.new(uri.host, uri.port)
http.verify_mode = OpenSSL::SSL::VERIFY_PEER
http.read_timeout = 10
http.use_ssl = true
#http.ssl_version = 'TLSv1'
return [http, uri]
end
As you can tell, I've been playing around with TLS and SSL version, because I figured that might be the issue. My next thought (that Google only has evidence of for Java) is, "How easy is it to just disable the SNI extension on my client?" The more general question is, "Can I keep using IP addresses with Ruby net/http while taking advantage of newer, more secure communication protocols?"
... tlsv1 unrecognized name (OpenSSL::SSL::SSLError)
This is in most cases not a problem you can solve by disabling SNI on the client side. SNI is required when you have multiple certificates on the same IP address and if you just connect by IP address and don't send the requested hostname (i.e. disabling SNI) the server will not know which certificate it should provide - which then results in the above error.
I very strongly prefer to do this polling by IP address, not by hostname, ...
If you have to deal with server which require SNI then you have to use SNI and you have to use SNI with the proper hostname, which is not necessarily the same name as you get from reverse lookup.
The easiest way to solve this is to add the patch that #steffenullrich mentioned for bug 10613.
All I did was look at the diff, and edit the file myself, but you can use the Linux patch tool if you're familiar with it.
For those who are unsure of where /net/http.rb is located, it is in the same location as the rest of your Ruby sources. For example, mine was here:
/home/myuser/.rvm/rubies/ruby-2.1.6/lib/net/http.rb
Once you patch the file, set the .disable_sni property of your HTTP object to true, and SNI will not be required, allowing the use of IP addresses in mixed-TLS communication.
I am new to HTTPS/SSL.
I need to write a HTTPS client which will reject all the connection by saying unknown CA . As I understand (through wireshark capture) during SSL connection, first client will send the 'client hello' message. In reply to this server will send message with three record - 'server hello', certificate, 'server hello done'.
What I am trying to achieve here is when the server will send certificate, client should always reject it.
I am trying to achieve it with following code but no luck.
How can I get LWP to validate SSL server certificates?
It's ok if solution is in some other language.
It should be enough to do the connection with no (or dummy) CA certificates known to the client. Have you tried setting SSL_ca_path and SSL_ca_file to dummy values?
Edit:
If any language goes, why not try openssls s_client?
openssl s_client -connect www.stackoverflow.com:443