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
Related
I would like to get the recommendation on how to configure Squid (latest version) with client SSL termination.
The requirement is to provide proxy access to the internet for the client who has no ability to install a custom CA certificate.
Following the documentation here, it is possible to use HTTPS for the browser-proxy connection the same way as HTTP.
However, the only way to achieve that is to use SSL Interception with self-signed CA certificate, which cannot work in my case.
Can someone please advise?
If I understand you correctly you want to replace the client-to-server encryption offered by HTTPS with client-to-proxy-encryption followed by proxy-to-server encryption without a client needing to trust the proxy. If this would work it would make HTTPS fundamentally insecure since every man-in-the-middle attacker could just do this. So fortunately it will not work.
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.
Is it possible to have Node.js use multiple SSL certificates? I am currently using one certificate but had a new certificate issued that matches other domains.
Since my server is behind a load balancer, there are two ways to get to it and I'd like to match them. Is there a way to use two certificates, instead of creating one with both matches?
See this answer for hosting multiple domains on a single https server
In short, you can use the SNI callback from the https server.
SNI stands for Server Name Identification and it is implemented by all modern browsers.
How it works:
The browser sends the hostname unencrypted (if it supports SNI). The rest of the request is encrypted by the certificate. The HTTPs module can then let you decide which SSL certificate is going to be used to decrypt the connection.
SNI Notes:
SNI is used by AWS Cloudfront and other services, if you require a secure connection
SNI requires a modern browser for it to work.. However given that AWS uses it gives me confidence in using it too.
Depending on how you implement it, it may slow down the request.
It may be better to put a nginx proxy in front of this.
Your connection then travels like this: Client -> (HTTPS) -> NGINX -> (HTTP) -> Node
Nginx could also serve static files, which may optimise your site.
I hope this helps you. I am posting this for documentation purposes.
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.
I'm trying to implement SPDY (with Node.js) for use on a high latency connection.
Now SPDY uses TLS encryption and this would increase the packet length - something I'm trying to avoid.
Is there such thing as a SPDY implementation without the TLS encryption?
Many thanks in advance,
SPDY's framing layer does not need to run over TLS, but for deployment reasons, it almost always does. It's hard to reliably deploy without running encrypted over port 443, because of intermediaries. Note the SPDY whitepaper says: "To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken."
That said, the C++ Flip server in the Chromium repository does support running without SSL, and the Chromium browser can be configured to support this.
PS: There's also an existing node.js implementation, see http://www.chromium.org/spdy.
If you want to test your SPDY server locally and without TLS, you can force chrome to use SPDY even without the NPN upgrade. To do so, pass --use-spdy=no-ssl to Chrome when you load it up.
You can confirm that the flag is registered by opening chrome://net-internals/#spdy and checking in there.
If you are implementing a SPDY server using node-spdy, then you can use the plain: true, ssl: false options to achieve what you want.
Its possible to make requests to plain: true spdy-server using spdycat
cli utility, specifying protocol version explicitly (-3 or -2 and
--no-tls). To use it from browser, you will need to start chrome with --use-spdy=no-ssl flag.
But please keep in mind, that SPDY is supposed to on TLS(SSL) server
or behind TLS(SSL) terminator, and otherwise not-suitable for serving
web-content.
https://github.com/indutny/node-spdy/issues/103
I would suggest QUIC protocol which is in development and base on UDP instead of TCP/TLS but still has the benefit like SPDY and Chrome has supported it