Keeping Customers Happy - Another New Elastic Load Balancer Feature

We added SSL support to the Elastic Load Balancer a couple of weeks ago. This met the needs of many of our users, but not all of them. Some of our users wanted to be able to tell if the HTTP requests arriving at their EC2 servers had been transmitted across the Internet using HTTPS. For example:

One question. How will the webservers know the original request came from HTTPS?
We currently add the "X-Forwarded-Proto: https" header when that happens.

As I always do, I passed this feedback along to the proper team for consideration. The "voice of the customer" is highly valued at Amazon, and feedback like this helps us to assign the proper priority to each feature.

I am happy to be able to report that we were able to turn this request around very quickly and I am happy to say that requests processed by newly created Elastic Load Balancers now include two additional headers:

• X-Forwarded-Proto specifies the protocol ("http" or "https") of the original request made to the Elastic Load Balancer.
• X-Forwarded-Port specifies the port of the original request.

These headers are injected when the request arrives at the Elastic Load Balancer. If the headers are present on incoming requests they will be overwritten.

If you would like to be part of a team that can turn on a dime, check out the following jobs:

• Software Development Engineer - Elastic Load Balancing.
• Senior Software Development Engineer - Elastic Load Balancing.

-- Jeff;

Comments

[Michael]

Amazing! I just requested this feature a few days ago and someone suggested I setup https to forward to port 8080. Well I did and that worked fine but I'm very impressed with how quickly you added this feature! Great job guys!

[Jesper Mortensen]

What you have implemented here today is the industry-standard way of preserving HTTPS protocol information. Every load balancer with SSL termination can do this, and almost every customer needs this.

Quote: "I am happy to ... that we were able to turn this request around very quickly" and "team that can turn on a dime". That language irks me a little. _Not_ having this working in the first release of SSL termination on ELB was a design blunder; you're fixing something that should have worked when SSL termination on ELB was introduced.

OK, so it's fixed now, and SSL termination via ELB is usable now. That's good news.

[Esh]

w00t! We'll be converting to ELB and using this feature soon!

--
Eric Hammond

[Kvz]

Wow that's fast. I only asked that like 10 days ago : )
Now if you also let us win the startup challenge, I could probably hook us up with some Best Friends Forever bracelets. Just saying.

[finnh]

How about adding ports to ELB? Port 25 for load-balancing inbound mail would be pretty useful.

[finnh]

update to anyone reading my prior comment: the AWS team updated ELB to allow for arbitrary ports a few revs ago. last time I checked it was HTTP ports only, but no longer!

[jayson]

when can we have the ability to update the ports for an existing ELB? similar to what we can do to 'Security Groups'.

[Ryan]

How do you know that the X-Forwarded-Proto and X-Forwarded-Port headers are coming from your ELB and not some other client/server with malicious intent?

Because there is no way to setup a security group that only allows traffic from an ELB (because there is no fixed IP for an ELB), you have to open up all IPS (or 10.X.X.X) on your instances behind the ELB.

So someone could easily inject those headers to "trick" your web server into thinking the request was coming from an HTTPS request when it was not...

Is there a workaround/solution for this scenario? Feature request: I'd REALLY like to setup a security group that blocks all HTTP/HTTPS traffic except that coming directly from my ELB (drastically cuts down on DOS/DDOS attacks...). I understand why this feature is slow to come as it will be difficult to implement.

[Ryan]

While I'm asking for features :)...

Can you also entertain the idea of exposing the fact you can add an instance to multiple load balancers in the AWS console GUI for ELB?

You can do it via command line tools/api - would be nice if it was exposed in the GUI (today it only allows you to select instances that are not already associated with an ELB).

Reason this multi ELB association is needed is cuz an ELB can only accept one ssl certificate. If you have instances that serve multiple domain names (each with their own ssl cert) - you need to make 1 ELB per cert, and point each ELB to the instances.

Another way to solve the problem (and save customers money) would be to allow an ELB to handle multiple certs...

[DingDong]

Hi Jeff

What port are you talking about: the client-side TCP port, or the server-side TCP port?

[Jeff Barr]

DingDong - The server-side port of the original request.