NodeBalancer SSL (beta)

Once the connection terminates on the NodeBalancer and gets proxied to the serving linode, is that second hop a regular unencrypted HTTP connection? Or does the NodeBalancer pass on the encrypted request to the linode over HTTPS?

It's HTTP from the NodeBalancer to the backend.

-Tim

Would an ecommerce site visitor get a certificate warning if they connect via https to a NodeBalancer setup for SSL with the NodeBalancer using http with the backends?

I'm not sure I understand your question. If you are going to be using the new HTTPS Protocol, the client will only see the encrypted connection. It knows nothing about what happens after the connection hits the system at the other end.

-Tim

@Main Street James:

Would an ecommerce site visitor get a certificate warning if they connect via https to a NodeBalancer setup for SSL with the NodeBalancer using http with the backends?
No. It would work just fine (that's kinda the whole point).

-Chris

@caker:

@Main Street James:

Would an ecommerce site visitor get a certificate warning if they connect via https to a NodeBalancer setup for SSL with the NodeBalancer using http with the backends?
No. It would work just fine (that's kinda the whole point).

-Chris
I thought so, but things tend to go rather poorly when I assume things.

It would be more helpful to display the name of the certificate as "Common Name" instead of the name of the issuer.

@Nibbler:

It would be more helpful to display the name of the certificate as "Common Name" instead of the name of the issuer.

It's a bug which I am looking in to now.

-Tim

Nibbler: The fix was pushed for this issue. You'll need to re-enter your certificate from the configuration page, and it should then have the correct information.

-Tim

The SSL config you guys are using has some very weak ciphers and is vulnerable to the BEAST attack: https://www.ssllabs.com/ssltest/analyze … Results=on">https://www.ssllabs.com/ssltest/analyze.html?d=balancer-node.hostr.co&hideResults=on

It's been a month, a response would be nice.

Kudos: Sorry for the delay. This is in the pipeline for the next batch of NodeBalancer SSL Beta updates – I don't have a timetable for when those will be pushed out, unfortunately. Thanks for the feedback!

For what it's worth, the SSL situation is not quite that simple, as discussed in several recent posts on the Qualys/SSL Labs blog. The primary way to mitigate BEAST server-side* is prioritizing the cipher RC4. However, every major browser other than Safari has fixed BEAST client-side, and the increasing number of attacks against RC4 are arguably more worrisome than BEAST is.

Your current SSL Labs report is pretty good, except for those problematic old cipher suites; you might also want to disable SSL 3. At least you support TLS 1.1 and 1.2 and modern cipher suites, too.

IMNSHO you should go with Qualys's current best practices, disregard BEAST, disable RC4 (if you can – see the next one), and enable whatever is needed to support IE/XP. Definitely IE 8, and probably all the way down to IE 6. That would mean enabling at least one cipher suite that isn't forward-secure (meaning, one that doesn't say "DHE" or "ECDHE") -- it might have to be RC4 -- and maybe SSL 3 as well. I'm not sure.

BEAST vs. RC4 is debatable -- my opinion is just that. IE/XP, that's also somewhat debatable. Some people can cheerfully disregard supporting them, but I'd bet Linode has at least one client who would scream if SSL NodeBalancers didn't support them.

• It's easy to solve BEAST 100% by disabling SSL 3 and TLS 1.0. This course of action has the slight downside of breaking support for nearly all clients. :)

@mnordhoff:

…

Your current SSL Labs report is pretty good, except for those problematic old cipher suites; you might also want to disable SSL 3. At least you support TLS 1.1 and 1.2 and modern cipher suites, too.

…

As you say, it's not simple and here's just one example: if SSL3 is disabled then sites using both Stripe.com (for credit card processing) and this new service will be broken.

Stripe has been notified of the issue and apparently is "investigating" but in the meantime their (Ruby-based) client can't connect to webhook URL's behind TLS. (Took me hours to figure that out because the calls weren't even in the nginx access log. I thought the calls weren't even being made until I finally looked in error.log and saw the ssl negotiations were timing out).

Awesome. I'm trying to think of an insulting joke about Stripe's retro sensibilities, but I'm too young to remember the 1990s.

Edit (2013-09-29): I just remembered, I've heard that Amazon CloudFront also requires an obsolete TLS configuration. That would probably catch a lot of Linode users.