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++.
Related
I'm trying to research a device that uses TLS-PSK as its cipher suite for server authentication. However, mitmproxy nor Burp Suite support the TLS-PSK ciphers. For Burp, this is the underlying Java/BouncyCastle implementation that does not support it.
Can anyone recommend an option to proxy traffic from a device that utilizes TLS-PSK?
Are you asking for a recommendation of a proxy that supports TLS-PSK? If so, stunnel supports this : https://www.stunnel.org/auth.html
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'm trying to implement tls communication between a browser (using the forge js library) using socket.io as transport and a java application as the TLS server.
The tls traffic is base64 encoded so I cannot use a regular sniffer (like tcdump) to analyze the traffic; I can convert the traffic back to binary but it's still hard to interpret the tls records.
Is there a tool that can make sense of the messages but that does not expect any specific transport for the traffic?
You can certainly use Wireshark. If you're not using a port where SSL/TLS is normally used, you may have to right-click on a packet and choose Decode As... -> SSL.
(This being said, there's little point in implementing TLS within the browser using JavaScript: this is not going to be secure.)
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'm trying to develop a XMPP "Proxy" which will be in the middle of a standard Jabber communication.
The schema will be something like this:
Pidgin ---> Proxy <--- eJabberD
|
v
Console
The purpose of this proxy is to log all the stanzas which go over the wire. IMHO, this is very convenient when you're developing XMPP based solutions.
I'm doing this with EventMachine and Ruby, and the main problem is to know how to decypher the traffic after the TLS/SASL handshake.
Before the starttls, all works perfectly, the server and client can talk between them, but when the tls handshake begins, although it works, it is impossible to dump the clear content as all of the traffic is encrypted.
I'm not an expert in TLS/SASL thing, so I don't know which is the best approach to do this. I think one way to achieve this, should be to grab the certificate in the handshake and use it to decypher the content as it goes throught the proxy.
Thanks!
If you could do what you say (grab the certificate on the wire and use it to decrypt), then TLS would be pretty worthless. This is one of the primary attacks TLS exists to prevent.
If the server will allow it, just don't send starttls. This is not required by spec. If starttls is required by your server, then you can configure it to use a null cipher, which will leave the traffic unencrypted. Not all servers will support that of course.
You can man-in-the-middle the starttls. Respond with your own tunnel to the client, and send a separate starttls negotiation to the server. This should generate certificate warnings on the client, but since you control the client you can tell it to accept the certificate anyway.
If you control the server, you can use the private key from it to decrypt the traffic. I'm not aware with any off-the-shelf code to do that easily, but it's writable.