AWS Elastic Load Balancing: Support for SSL Termination | Hacker News Reader

AWS Elastic Load Balancing: Support for SSL Termination

aws.typepad.com

40 pointsabraham17 comments

If you use this, your customers' data is now in cleartext between the ELB and your instance. Now, that may be fine, you're already trusting EC2 if you keep cleartext data on disk. But it's worth keeping in mind.

Is there a reason why you cant have one of these forward to an HTTPS port that's using a long-lived self-signed certificate? That way you'd keep things SSL'ed the whole way, but updating your certs becomes easier (upload a new one to the ELB vs distribute it to all your servers).

I haven't tried this myself and the docs dont say if its (im)possible, but it seems like that'd be a good feature.

Is there a reason why you cant have one of these forward to an HTTPS port that's using a long-lived self-signed certificate?

Much better: Forward via HTTPS to EC2 instances which are using short-lived certificates. When you boot a new instance to add to your load balancing cluster, have it generate an SSL key which ELB is told to trust. If a node is compromised, you just tell ELB to not trust that certificate any more.

But that doesn't seem to be possible, and it still doesn't make up for the fact that putting SSL stacks and $BIGNUM SSL keys together is practically begging to be attacked.

I'm not a security expert by any means, but why is telling ELB "dont trust cert X" any better than removing the compromised instances from the ELB via the API (or just terminating the instance entirely)?

because in theory, the private key that was stored on that trusted instance could have been stolen ready to be used to impersonate that machine later on.

Is that hop private?

No more or less private than connections between EC2 nodes.

Sorry for my ignorance here, but is the connection between EC2 nodes isolated (per account), or is it shared amongst multiple accounts?

Theoretically traffic over the EC2 network is private. In practice, I wouldn't want to rely on the assumption that no packet ever ends up going somewhere it ought not to; nor would I want to rely on the assumption that information doesn't leak in other ways (e.g., timing side channels -- many routers leak information about recent source packet destination addresses due to the caching of routing table lookups).

SSL is nice, but I want to assign an elastic IP to my ELB (or just an A record) so I can get around the CNAME-only problem.

Yes! That is simply the biggest problem with EC2 right now.

Please! We were on with our AWS account manager today and mentioned this to them again. He says they hear that quite a bit. Hopefully that means they're listening to the feedback and will be adding it.

This is some pretty sweet news. This was one of the reasons why I ended up not using AWS ELBs. I wonder if this will make an impact on Heroku's pricing for SSL. I assume they had to somehow get around the technical difficulties themselves.

I wonder if this was one of the reasons Engine Yard doesn't use ELBs? Instead they use ha-proxy, which unfortunately can not terminate SSL, and due to unchangeable kernel settings on EC2 can not pass a direct TCP connection through. The result: you can't see client IPs on SSL requests on EY AppCloud! We got burned pretty bad by this due to the fact that we are a global VOD site that depends on geo location for film availability. It wasn't terribly difficult to workaround, but it's not the kind of thing you'd expect as a web developer.

I would LOVE to get on an ELB, assuming that failover can be handled gracefully.

I've also seen this named "ssl offloading" and anecdotally I found responsiveness to greatly increase on my zimbra webmail server once I placed an nginx web proxy ahead of it just to do decryption (this wasn't through AWS).

I would love to see what crypto card offload cluster they built for this.

I wouldn't be surprised if x86 is now cheaper than crypto cards.

Reply on news.ycombinator.com