5 ms·

AWS Elastic Load Balancing: Support for SSL Termination

40 points by abraham 16y ago

wmwong 16y ago
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 16y ago
  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 16y ago
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).
js2 16y ago
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 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 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? 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 ago
      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 16y ago
        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.
- nopal 16y ago
  Is that hop private?
  - cperciva 16y ago
    No more or less private than connections between EC2 nodes.
    - nopal 16y ago
      Sorry for my ignorance here, but is the connection between EC2 nodes isolated (per account), or is it shared amongst multiple accounts?
      - cperciva 16y ago
        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).
cagenut 16y ago
I would love to see what crypto card offload cluster they built for this.
- wmf 16y ago
  I wouldn't be surprised if x86 is now cheaper than crypto cards.
sdh 16y ago
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.
- shykes 16y ago
  Yes! That is simply the biggest problem with EC2 right now.
- krobertson 16y ago
  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.

40 points by abraham 16y ago

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 16y ago
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 16y ago

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

js2 16y ago

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 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 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? 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 ago
    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 16y ago
      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.
nopal 16y ago
Is that hop private?
- cperciva 16y ago
  No more or less private than connections between EC2 nodes.
  - nopal 16y ago
    Sorry for my ignorance here, but is the connection between EC2 nodes isolated (per account), or is it shared amongst multiple accounts?
    - cperciva 16y ago
      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).

cagenut 16y ago

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

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

sdh 16y ago

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.

shykes 16y ago
Yes! That is simply the biggest problem with EC2 right now.
krobertson 16y ago
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.