Is it rude that SSL Labs publishes those who got Fs?
It publishes all of them, I thought, unless you select the "do not publish my results" box on the main screen.
Getting an A+ on the SSL Labs test in Node.js and Io.js
31–40 of 51 posts
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#32This isn't prioritizing quite the right ciphers. The CBC mode construction in TLS has serious problems (MAC-then-encrypt instead of encrypt-then-MAC) and should be considered cryptographically broken. It's incredibly fragile and difficult to implement correctly.
You want to make sure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is negotiated, at least where browsers support it. (It's spelled "ECDHE-RSA-AES128-GCM-SHA256" in OpenSSL.) There's a small handful of others that are also acceptable, but between ECDSA certificates being rare and CHACHA20_POLY1305 still being standardized, that's the one you want. All the rest are legacy baggage.
Mozilla has some server-side recommendations here: https://wiki.mozilla.org/Security/Server_Side_TLS
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#33This isn't prioritizing quite the right ciphers. The CBC mode construction in TLS has serious problems (MAC-then-encrypt instead of encrypt-then-MAC) and should be considered cryptographically broken. It's incredibly fragile and difficult to implement correctly. You want to make sure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is negotiated, at least where browsers support it. (It's spelled "ECDHE-RSA-AES128-GCM-SHA256" in…
Just out of curiosity, why are you proposing that AES 128 is the one to go with? According to SSL Labs AES 256 is preferable and has broad support among browsers.
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#34This isn't prioritizing quite the right ciphers. The CBC mode construction in TLS has serious problems (MAC-then-encrypt instead of encrypt-then-MAC) and should be considered cryptographically broken. It's incredibly fragile and difficult to implement correctly. You want to make sure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is negotiated, at least where browsers support it. (It's spelled "ECDHE-RSA-AES128-GCM-SHA256" in…
Just out of curiosity, why are you proposing that AES 128 is the one to go with? According to SSL Labs AES 256 is preferable and has broad support among browsers.
This article points to an attack that applies to AES-256, but not 128.
https://www.schneier.com/blog/archives/2009/07/another_new_a...
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#35Is it rude that SSL Labs publishes those who got Fs?
There's a "don't publish" checkbox on the main page right below where your URL is entered. Also, anecdotally, most of the F's I see are from untrusted certs. (I.e. the encryption is fine, the site in question just didn't pay the CA protection money.)
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#36Earlier quoted context omitted.
Just out of curiosity, why are you proposing that AES 128 is the one to go with? According to SSL Labs AES 256 is preferable and has broad support among browsers.
This article points to an attack that applies to AES-256, but not 128. https://www.schneier.com/blog/archives/2009/07/another_new_a...
Except that the attack you mention has no bearing on the standard 14-round AES-256 that everybody uses.
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#37This isn't prioritizing quite the right ciphers. The CBC mode construction in TLS has serious problems (MAC-then-encrypt instead of encrypt-then-MAC) and should be considered cryptographically broken. It's incredibly fragile and difficult to implement correctly. You want to make sure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is negotiated, at least where browsers support it. (It's spelled "ECDHE-RSA-AES128-GCM-SHA256" in…
Just out of curiosity, why are you proposing that AES 128 is the one to go with? According to SSL Labs AES 256 is preferable and has broad support among browsers.
AES_128_GCM is much much preferable to AES_256_CBC. AES_256_GCM does not have broad support (not supported by Chrome or Firefox) and isn't really worth the performance tradeoff.
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#38Earlier quoted context omitted.
Edit: added reply to 'vkjv' below as I have hit the comment threshhold and have been unable to reply to this account. Since HN seems to be somewhat unsure of node's concept of IO (why I imagine the downmods) and why it's significantly different to common Python and Ruby setup (Tornado and EventMachine excepted). The main point of nginx is event based, non-blocking IO. That's why traditionally blocking languages (like…
While node.js is great at non-blocking IO, it's not great at the blocking kind. E.g., shuffling bytes. While you are correct that node.js is happily not blocking the main thread while reading from disk, once that returns it still needs to serialize that data from I/O to the request and that is both blocking and slow. I highly advise that you don't use node.js to service static content outside of a development environ…
> it still needs to serialize that data from I/O to the request and that is both blocking and slow.
That's incorrect. See edit to parent post (sorry I couldn't reply earlier).
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#39Earlier quoted context omitted.
Yes, I think is better to put nginx in front to handle this and sooner or later you will need some kind of reverse proxy as soon as your application grows. The reasons might be load balancing or just to map components of your app like "app.com" and "app.com/api" being different applications. One big difference to note is that nginx link to the local openssl while node binaries embeds an openssl. If there is a bug in…
>Personally I think nginx is awesome. They are going to support JavaScript soon Whaaaaaaat?
Can't find a better source but it was announced few months ago:
http://www.infoworld.com/article/2838008/javascript/nginx-ha...
Re: Getting an A+ on the SSL Labs test in Node.js and Io.js
#40Earlier quoted context omitted.
Do you have any particular security holes in mind that nginx guards which node.js / io.js are open for ?
Not off the top of my head, although I know the recommendation at least used to be that Node was not run with full public access. I think it makes sense to separate the security and low level details of serving a public site, and the details of hosting an application though. This is common practice with Django, using gunicorn and nginx, and I believe with Ruby as well in a similar manner.
Django and Ruby /can't/ serve static content at any speed as they block their main thread. Node and nginx use the same model for io, as does Tornado and Eventmachine (though the latter two are nowhere near as popular).