I'm using ssl3 to connect to server. When the -change_session_version option is specified with the -reconnect, I want the session protocol to change to SSLv2 from SSLv3
This is my command: apps/openssl s_client -connect 10.102.113.3:443 -reconnect -change_session_version -ssl3
Now, I know that I should have either this code:
if(change_session_version)
s->session->ssl_version = SSL2_VERSION;
Or this code:
if(change_session_version)
s->version = SSL2_VERSION;
I don't know where to put this code though.
I have declared change_session_version as an int in ssl.h and have set it to 1 if the -change_session_version option is specified.
Please help me out!
Your question embodies a contradiction in terms. A 'session' in SSL comprises the protocol, the cipher suite, the key material, and the peer certificates. You can't change any of them without creating a new session.
EDIT Just changing a variable in a piece of local memory can't possibly accomplish anything useful. The peer won't know about it, and the other peers sharing the session on other connections won't know about it either. You have to re-handshake and negotiate a new session.
I don't think this is possible. First, SSLv2 is practically not supported anymore and most stacks don't even implement it while the others have disabled it. And then there is no support for session resumption in SSLv2 at all.
Related
I'm playing with a swarm of "nodes" connecting to each other, and all I really care for is that they are connected securely to each other and are all authenticated.
For this I figured the TLS module would be a good fit. I created a CA and signed a bunch of certificates, one for each node. I then hit the issue that certificates are now validated against the host from which the node connects.
Is it possible somehow to disable or work around the Common Name validation?
Is there something fundamentally flawed about this setup?
Am I correct that, as long as these certificates are signed by my CA, the connection should be secure and I am certain only my nodes can connect?
It seems like just an annoyance having to sign certificates locked to a hostname or IP (or several in case of multiple interfaces). I've learned that the requirement to validate the host is actually not a part of TLS but HTTPS - in that light, it might be a Node.js bug to do so by default?
Is it possible somehow to disable or work around the Common Name validation?
This is possible by setting the checkServerIdentity option of tls.connect to a no-op function:
const tls = require('tls')
tls.connect({
checkServerIdentity: () => undefined,
...
})
Sources:
https://nodejs.org/api/tls.html#tls_tls_checkserveridentity_host_cert
https://github.com/nodejs/node/blob/df63e534584a54dcf02b37446e1e821382e3cef3/lib/tls.js#L168-L231
https://github.com/nodejs/node/blob/79261f3003719264bc03f6a5b54cf9eddbc8b48e/lib/_tls_wrap.js#L1046
I am currently implementing OpenSSL's TLS/SSL standards into my mail service, allowing my users to select the TLS/SSL version they want. Here is the list of versions:
["TLSv1","TLSv1_server","TLSv1_client","SSLv3","SSLv3_server","SSLv3_client","SSLv23","SSLv23_server","SSLv23_client","TLS","TLSv1_1_server","TLSv1_1_client","TLSv1_1","TLSv1_2","TLSv1_2_server","TLSv1_2_client"]
I did some Googling on what the difference of the options are, and I understand that some versions are deprecated, or shouldn't be used because of security issues, such as TLSv1. I don't understand the difference between the client vs server ones, but from my own testing, the server options return errors when trying to send a mail with it.
So my question is - of that list, what should I remove?
What you show are not SSL/TLS versions but various types of SSL contexts which also include the usable SSL/TLS versions. This means the *_server "versions" are all SSL contexts which should be used on the server side where you usually also need a certificate. The *_client variants are for the client side of the TLS handshake, i.e. the one which initiates the TLS handshake.
Within a mail client you don't want to use any server specific SSL contexts because with these the mail client would expect the peer to start with the TLS handshake which it does not.
For more details see the man page of SSL_CTX_new which has a detailed description of what all these different contexts mean.
... allowing my users to select the TLS/SSL version they want.
While your specific implementation is wrong the idea of letting users chose the protocol version is wrong too. Instead you should just use a generic context without limitations (apart from disabling insecure versions) so that it automatically picks the best protocol version during the TLS exchange. Selecting specific protocol versions should only be done in case the peers TLS stack is broken, like for stacks which simply refuse a TLS 1.2 handshake instead of replying with TLS 1.0 in case they don't support TLS 1.2.
I'm using this example as a template in a server/client pair I wrote. I honestly don't understand all the details on how the secure connection is done. I understand the simple private/public RSA encryption. We encrypt with a public key, and only private keys can open it. Is it as simple here? (this is not the real question here)
So my question is: In my client part I used set_verify_mode(boost::asio::ssl::verify_none);. Does this jeopardize the secure connection I'm using? Is the connection still secure and encrypted?
No, it's not safe setting SSL_VERIFY_NONE. In this case if someone attack the connection the client won't be able to verify the sender's identity.
Detailed description of server and client behaviour for each flags on openssl site:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_verify.html
We run a nodejs https server and we noticed in one of the online SSL checker tools that we use old ciphers (And generally bad TLS options).
We don't really know much about this thing so we were wondering if there is any recommended ciphers list or specific nodejs TLS options we should pass in order to make sure we are most secured.
Thanks
P.S.
This is the online checker we use: https://www.ssllabs.com/ssltest/index.html
We would really like to get an A there
For future reference, i ended up using nginx for SSL termination, and used this guide for securing my ssl connections: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
I'm working on a project involving Socket.IO that I'd like to add encryption to. It seems kinda wrong, but being able to add a standard way to tunnel a TLS socket through my protocol would be really helpful since mine is transport agnostic, and TLS is great for negotiating and creating secure sessions (a wheel I really don't want to have to reinvent).
Ultimately, you would have BCP inside TLS inside BCP (BCP is the name of my protocol). As ugly as that is, it would guarantee that any transport medium could easily upgrade to an encrypted connection within BCP, which is great considering I don't know ahead of time which transport Socket.IO will pick (also, futureproofing and providing options for other people using BCP, etc). I understand if this is a bad idea, or impossible from TLS being too low-level, but if it can be done or you have better alternatives I'd be happy to hear your thoughts.
In general, SSL/TLS doesn't care about transport and can work even on pigeon mail (if you have enough pigeons in the cage ;). Consequently you can run it over some transport other than TCP, and you can run anything over SSL/TLS.
If I got your problem right, look at how Explicit SSL mode is done in FTPS and in SMTP. Initially non-secured session is established, then STARTTLS command is sent, then SSL handshake takes place and finally the rest of communication goes on top of SSL. And all of this happens within single socket connection.