One of my legacy Ruby application still uses Ruby 1.8.7. It makes a lot of HTTP requests on third-party web services and some of them are over SSL.
Those third-party services are dropping their support of SSLv3 as of the POODLE vulnerability and I'd like to patch my clients to continue connecting to them.
Ruby's standard library Net::HTTP doesn't seem to have a way to change the SSL version used.
In Ruby's openssl (ssl-internal.rb) there is a way to change the version. Sadly, this is not exposed by Net::HTTP (https.rb).
Are we (users of Ruby 1.8.7) that screwed?
Edit : In fact, it seems that the client is switching to TLSv1 if the server doesn't support SSLv3. I have an SSL enabled website without SSLv3 support, behind Nginx, and I've verified that my 1.8.7 client is switching to TLSv1 and the request works. If you want to verify by yourself, take a look here : https://serverfault.com/questions/620123/how-can-i-let-nginx-log-the-used-ssl-tls-protocol-and-ciphersuite
In fact, it seems that the client is switching to TLSv1 if the server doesn't support SSLv3
It is more the other way around. Inside the SSL handshake the client shows to the server what it can (protocol, ciphers) and the server then picks from this the best it can too. Usually the client is just defaulting to SSLv23 which does not restrict the client itself to a specific protocol. If the server then offers TLSv1 they will continue with it, if the server only offers SSLv3 they will use SSL 3.0.
If you want to restrict the client to pick the best but not allowing SSL 3.0 anymore have a look at https://stackoverflow.com/a/24237525/3081018 on how to disable SSLv3 by setting the ssl_options.
Related
I try to read the website https://www.eroids.com/reviews with Indy and always get a 403.
This website seems only to load when I set the ssl version to sslvTLSv1_1. If I do that, this website loads fine, but other websites not. Most other seems to use sslvTLSv1_2.
As long I only add [sslvTLSv1_1] to the sslversion, it works, but when I add [sslvTLSv1_1, sslvTLSv1_2], the mentioned site does not load anymore (again 403), but any other site does.
My question is: How can I determine what sslversion a website need? Do I need to try to access the site with each ssl version until I get a 200 back or is there something to me unknown integrated into indy to automatically do that?
How can I determine what sslversion a website need?
In general, you can't. However, most servers support version negotiation during the TLS handshake, so that clients supporting multiple/different TLS versions can negotiate with the server for which TLS version to use. But, it sounds like maybe this particular server does not support that.
However, the fact that you are even getting an HTTP 403 response at all for an HTTPS url means a TLS session is being created fine, so the issue is something else.
Unless the server is ignoring all TLS errors during the handshake and creating a simple TLS session, THEN is sending an HTTP error in reply to an earlier TLS error. Which is rare, but not unheard of.
Do I need to try to access the site with each ssl version until I get a 200 back
In this particular situation, probably so, yes. Start with [sslvTLSv1_1, sslvTLSv1_2], and if that fails then retry with [sslvTLSv1_2], then retry with [sslvTLSv1_1], and so on.
is there something to me unknown integrated into indy to automatically do that?
Indy does not have that capability at this time, no.
I'm using Go 1.6 and want to make a HTTP2-only request over http://.
Attempting to do this currently results in:
Head http://localhost:2076/completed/764c1b6bc55548707507a2dd25570483a7216bf4: http2: unsupported scheme
To force http2, I believe I need http.Client.Transport.TLSConfig.NextProtos set to []string{"h2"}.
What else is required?
You need to use https, not http. The http2 transport doesn't recognize the http scheme.
The HTTP/2.0 by default works on highly secured connections. It uses high quality ciphers. So it can only run on HTTPS connections. Moreover, to make HTTPS connections, you also need to have your SSL enabled and have the required certificates installed.
So I just upgraded to nginx 1.9.5 which supports HTTP2.
I replaced all listen spdy by listen http2, removed spdy_headers_comp directive and also removed add_header Alternate-Protocol 443:npn-spdy/3;
Then I opened my site in Firefox, opened network monitor, and voila: Version: HTTP/2.0
But how does Firefox know my site supports HTTP2? Does it always first try to connect via HTTP2 before trying HTTP1.1?
HTTP/2 sites are deployed over TLS.
Browsers use a TLS extension called ALPN to tell the server what protocols they can speak.
Browsers always send this TLS extension, and always include both HTTP/2 and HTTP/1.1 (and may also include the old SPDY protocol).
The server receives the list of protocols that browsers can speak, and if the server supports HTTP/2 (and if a number of other conditions are met - in particular regarding the TLS protocol version and the cipher suite), the server decides to speak HTTP/2 with the browser, and sends the chosen protocol back to the browser, again using the ALPN extension.
If the server does not support HTTP/2 then it will send to the browser that it can only speak HTTP/1.1 via the ALPN extension.
If the server does not support the ALPN extension, then it will not send it to the browser, and the browser will default to speak HTTP/1.1 to that server.
In Ruby, is an OpenSSL::SSL::SSLSocket an implementation of RFC 2246?
Yes, it provides a SSL/TLS client or server socket. With the cipher list on the OpenSSL Context object you can pass to the initializer, you can control which protocol exactly is spoken by that socket.
The OpenSSL classes of ruby are a rather thin wrapper around the base OpenSSL API. So you might want to read its cipher documentation too.
Yes, Ruby's SSL implementation does support TSL v1.0 and higher by utilizing the OpenSSL library that is installed on your system. By default, the behavior will be lenient, and Ruby will choose the "best" protocol being supported by the peer, but if you want finer-grained control and enforce an actual protocol, you may do this by setting appropriate values with OpenSSL::SSL::SSLContext#ssl_version=.
That said, the newest versions of TLS, 1.1 and 1.2, will only be supported if you have one of the recent OpenSSL versions installed on your system. It is highly recommended to continuously upgrade, only the newest versions receive all the security-related bug fixes!
I have a server I am trying t communicate to and it requires the usage of gnuTLS or SSL encryption. Is it possible for me to include the certificate in my cocoa application and use it for SSL communication and do I really need to use gnuTLS or is there any other way of using SSL connection from cocoa?
To address the second question, it requires TLS or SSL. gnuTLS is just one implementation of TLS. If it's compliant, there is no way for the server to know which implementation you're using, and if it isn't compliant practically nobody will be able to interoperate with it, so why be the first?
Most people use OpenSSL from C or C++.