

AWS Elastic Load Balancing: Support for SSL Termination - abraham
http://aws.typepad.com/aws/2010/10/elastic-load-balancer-support-for-ssl-termination.html

======
js2
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.

~~~
mcodik
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
_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.

~~~
mcodik
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)?

~~~
pilif
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.

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

~~~
krobertson
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.

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

~~~
dasil003
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.

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

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

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

