NodeBalancer SSL

NodeBalancers now support the HTTPS protocol, meaning they can terminate SSL connections for you. In order to do this, create a new configuration profile using port 443 (typically), set the Protocol to HTTPS, and then provide the certificate and its private key (without a passphrase). Chained intermediate certificates are also supported. Here's a screenshot showing the new options:



Using this new configuration a NodeBalancer will terminate SSL connections for you, and have the functionality and behavior you already enjoy from HTTP mode, including correctly setting an X-Fowarded-For header with the requester's IP address, session cookies for backend node stickiness, etc.

NodeBalancer info

- NodeBalancer Product Page
- NodeBalancers - Getting Started
- NodeBalancers - Reference Guide

NodeBalancer SSL Beta

SSL support for NodeBalancers is available to everyone, right now. There is no need to open a ticket or anything - just select HTTPS from the Protocol drop-down.

We could really use your testing and feedback!

Thanks,
-Chris

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

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

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

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

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.

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

-Tim

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

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

_________________
'If debugging is the process of removing bugs, then programming must be the process of putting them in.' //Edsger Dijkstra
'Nothing is withheld from us which we have conceived to do.' | 'Do things that have never been done.' //Russell Kirsch

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

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.

_________________
Matt Nordhoff (aka Peng on IRC)

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).