4 ms·
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 t
by mcodik 16y ago
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.
- cperciva 16y agoIs 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.
- mcodik 16y agoI'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)?
- pilif 16y agobecause 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.