AUTHOR: http://aws.typepad.com/aws/2010/10/elastic-load-balancer-support-for-ssl-termination.html LINK!

Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« AWS Management Console Now Supports Amazon SNS | Main | Upcoming AWS Events in Asia »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c534853ef0133f4c6bef1970b

Listed below are links to weblogs that reference AWS Elastic Load Balancing: Support for SSL Termination:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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

The comments to this entry are closed.

Featured Events

The AWS Report


Brought to You By

Jeff Barr (@jeffbarr):



Jinesh Varia (@jinman):


Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30