Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com