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!
Related
I'm looking for a way to establish TLS sessions using out-of-bound PSK in Go. I control both the server and client.
Reading Golang TLS implementation, it seems like the library only supports PSK in session resumption where PSKs are obtained from previous sessions. In my scenario, though, PSK are established between the server and the client out-of-band, which AFAIK is "permitted" according to RFC 8446 ("TLS PSKs can be established out of band.") Does anyone know if Go supports that already or if there are other TLS libraries that do?
TLS-PSK (or the RSA/DHE variants) is not currently (Go 1.15) supported in the standard library.
There is an issue that has been open since 2013 but no movement on it. Multiple comments in that issue advertise forks of crypto/tls with purported support for external pre-shared keys; use at your own risk.
I've received the notice that one of my servers will disable early TLS and use only TLS1.2. And they said to upgrade the protocols from my soap integrations.
Is it really possible? And so, how do i do that?
You will need to ensure that whatever you use that calls to Magento utilizes TLS1.2 (or at least supports it as a fallback).
For example, if you wrote a program to call Magento SOAP web services in Java, you would need to make sure that it was a version of Java that supported TLS1.2, and that your configuration of Java utilized that as a protocol.
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.
I tried to look this over in the Netty documentation but was unable to find it : which all websocket protocols does Netty websocket implementation support ?
I am trying to check for browser compatibility and hence also wanted to see the protocols as mentioned above. Going through the websocket server example in Netty 3.5.3 , I see in the WebSocketServerIndexPage class that window.MozWebSocket is also used , hence am I right that hybi-07 and hybi-10 is also supported without any specific code to be written? (Pardon me I am not much aware of the differences in the various protocols but it seems to be mentioned everywhere).
Netty supports protocol versions HyBi 00 (which is the same as Hixie 76), HyBi 8-10 and HyBi 13-17 (17 is the same as IETF 6455).
Each browser supports a single version of the protocol. HyBi 00-76 covers current released versions of iOS. IETF 6455 covers recent versions of Chrome and Firefox (and Opera if once they enable it by default), and IE 10. For browsers without native WebSocket support but with Flash you can use web-socket-js as a fallback and that supports IETF 6455 (albeit without binary data types).
In other words, Netty supports basically all browsers that have WebSocket support.
According to the netty api docs, it supports 3 versions of the Hybi drafts - 00, 07 and 10 as well as RFC 6455.
This will give you support for most browsers as summarised by http://en.wikipedia.org/wiki/WebSocket.
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++.