AWS Elastic Load Balancing: Support for SSL Termination

You can now create a highly scalable, load-balanced web site using multiple Amazon EC2 instances, and you can easily arrange for the entire HTTPS encryption and decryption process (generally known as SSL termination) to be handled by an Elastic Load Balancer. Your users can benefit from encrypted communication with very little operational overhead or administrative complexity.

Until now, you had to handle the termination process within each EC2 instance. This added to the load on the instance and also required you to install an X.509 certificate on each instance. With this new release, you can simply upload the certificates to your AWS account and we'll take care of getting them distributed to the load balancers.

1. Create or purchase a certificate.
2. Upload the certificate to your AWS account using the AWS Management Console or the iam-servercertupload command, then retrieve the ID of the uploaded certificate.
3. Create a new load balancer which includes an HTTPS listener, and supply the certificate ID from the previous step.
4. Configure a health check and associate EC2 instances with the load balancer as usual.

As you may know, you can use the AWS Management Console to create and manage your Elastic Load Balancers. As you can see from the second and third screen shots below, you can now select one of your existing SSL certificates or upload a new one when you create a new Elastic Load Balancer:

A lot of our users have asked for this feature and we are happy to be able to meet their needs.

Update: We've gotten some good feedback on this post already. Here are some replies:

1. The team is looking in to supplying the X-Forwarded-Proto header. This would allow your application to verify that the request was made using HTTPS, or to treat HTTP and HTTPS requests differently.
2. Session stickiness is supported for HTTPS/SSL.

-- Jeff;

PS - The Elastic Load Balancer team is looking for developers.

Comments

[Michael Sitarzewski]

If this works the way I hope it does, it changes everything for my company. Thanks team!

[Jaka]

Out of curiosity, what is the problem with just keeping the certs on the instances?

Also, is there a way for the instance to know whether a connection was received over a secure channel other than setting up another http port, to differentiate between the two?

[Brian Long]

Great stuff!

[Satoshi Takezawa]

It's very nice!
Does ELB with HTTPS listener also add Forwarded-For request header to identify the client's IP?

[AWS Evangelist]

> Does ELB with HTTPS listener also add Forwarded-For request header to identify the client's IP?

This is what the team told me:

> It operates the same way that http does wrt forwarded-for. It gets added in and passed along.

[Craig Box]

> Out of curiosity, what is the problem with just keeping the certs on the instances?

Previously, with an ELB which received SSL traffic, you would lose the source IP address of incoming requests. You couldn't have someone connect securely, and restrict them based on their location, at the same time. (A big deal for anyone using GeoIP.)

This new setup will allow the packet to be opened at the ELB, thus an X-Forwarded-For header can be added to the packet.

> If this works the way I hope it does, it changes everything for my company. Thanks team!

+1 with feeling!

[Yannick Menager]

Hurray !!!

:-)

[Kvz]

Great! We can now probably ditch stunnel we keep in front of node.js :)
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.
Do the EBLs add something similar?

[Greg]

Very interesting. Moving SSL processing from EC2 unit to load balancer is probably a good thing. However, I'm not sure how it works. When https rerquest comes to load balancer, it is SSL-decrypted, and then forwarded to EC2, but on what port? 443? 80? If on 443, than it will probably not work, because my EC2 server expects SSL-encoded transfer on port 443 and will throw error otherwise. If on 80, than application will think the communication is not encrypted - and we have logic which requires https for some URLs, and http for others. So is there some reliable way to decide if the original communication was encrypted in such a case?

[Rob Mills]

Does this mean that instances will be "sticky" even using SSL? I remember that feature wouldn't work before with an encrypted connection.

[Bryan Field-Elliot]

Sticky sessions with SSL? No mention was made of this in the post. Are sticky sessions supported now? This would be even more useful and important to us than offloading SSL processing to the load balancer.

[Rob Mills]

Greg almost made a good point about whether our own code in the EC2 instance can determine whether or not the request was encrypted. Will the load balancer provide some indicator? Perhaps a header?

[Peter]

Still waiting for wildcard domain support (DNS A-Record) or the ability to assign an Elastic IP to an ELB

[Luis Camargo]

We just configured our applications to take advantage of this and everything works perfectly. The trick is to properly configure the app servers on the ec2 instances so the applications can know the request was made over HTTPS. We use Tomcat and the apps use request.getScheme() to know whether requests are made over http or https and build CloudFront URLs with the same scheme.

This what our connector looks like:

The Proxy name and proxy port settings force redirects to use port 443. Without them redirects go to port 80.

I'm not familiar with other app servers, but the basic idea should apply.

[Luis Camargo]

The connector configuration was removed from my previous post, probably because of the brackets. Here it is without the starting or ending brackets:

Connector port="443" protocol="HTTP/1.1" SSLEnabled="false"
executor="tomcatThreadPool" secure="true"
connectionTimeout="20000"
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml"
scheme="https" proxyName="smc-service-cloud.respondus2.com" proxyPort="443"

[jayson]

hi, how about existing ELB instances?

[Jozef]

We tried this with our Ruby/Rails service-desk management app too. Works great!
Ec2 instance uses Nginx+Phusion Passenger+Rails and there was no need to change anything.
We have just removed https from ec2 (from Nginx config) and moved certificate to ELB - simple and straightforward.
Simplifies private key and certificate management a lot.

[Sam]

If the ELB is set to accept HTTPS connections on 443 and forward the decrypted traffic to origin servers on port 80 (or some other port), is it possible to restrict the origin servers so that connections are only accepted from the load-balancer?

That is, can anyone from the public internet just connect by plain HTTP to the origin server?

[Jimmy]

Are there any figures showing how fast ELB terminates SSL?

[Mark]

@Bryan Field-Elliot - Sticky session have always been supported. Its in the aws documentation, however here is a pretty decent article about it http://shlomoswidler.com/2010/04/elastic-load-balancing-with-sticky-sessions.html

[Bruno]

I don't see new comments on this thread since last year, and I'm pretty sure there are some still pending answers for the questions in this thread.
A few pending questions:

How an EC2 instance can determine whether or not the request was encrypted. Will the load balancer provide some indicator? Perhaps a header?

Is there any update about "X-Forwarded-Proto header"? Is it possible to initiate a new SSL connection between the Load Balancer and the EC2 instances? If possible, can we use Self Signed Certificates for that purpose?

[Lawrence Coffin]

If the traffic between the SSL load balancers and the EC2 instance is sent insecurely (over port 80), what keeps that traffic secure from eavesdropping within the AWS network -- i.e. from other EC2 instances that other AWS customers set up? Is there something special about the AWS network that keeps those communications secure? Otherwise mapping from port 443 to port 80 seems to defeat the purpose of keeping the communication secure from client all the way through to the server.

---Lawrence