Menu
Followed the Engine Yard docs at https://support.cloud.engineyard.com/entries/21715452-use-elastic-load-balancing-with-engine-yard-cloud
Got this set up and appeared to working well allowing us to use SSL Terminated at the ELB instead at the server. In theory this should allow us to use and multiple SSL certs in a single environment.
This setup means the traffic between the browser and the ELB load balancer is SSL, but the onward traffic from the ELB to the application servers is decrypted. This caused us a problem with our rails 3.2.8 application forcing SSL - it redirects every decrypted request back to it's https equivalent, which sends a decrypted request from the load balancer to the application server again, causing an infinite loop condition.
If we disable the forcing of SSL in our app we need to test each request to see if it came from an SSL connection, if it did we can respond, if not, redirect it.
According to this release note ( http://aws.amazon.com/releasenotes/7778622769836370 ) the ELB will pass the X-Forwarded-Proto header containing 'https' when traffic is passed from a https connection.
Firstly there is no header called 'X-Forwarded-Proto' in the request on Engine Yard. 'HTTP_X-FORWARDED_PROTO' does exist, but it always contains 'http' even when traffic is sent over SSL to the ELB.
Can anyone offer any insight into this or ideas for a workaround? I've tried EY support without much luck so far.
615
The X-Forwarded-For (XFF) request header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through a proxy server.
The X-Forwarded-For request header is automatically added and helps you identify the IP address of a client when you use an HTTP or HTTPS load balancer. Because load balancers intercept traffic between clients and servers, your server access logs contain only the IP address of the load balancer.
But the ALB seems to strip the header and replace it with its own (which becomes X-Forwarded-Proto: http ), and then the backend application on the ECS servers sees http and writes all it's links/resource paths as http, causing an insecure mixed content warning in Safari, Chrome, etc.
Host headers and load balancing Every request to a website contains a unique piece of identifying information called the Host header. The Host header helps route each request to the correct origin server so the end user is sent the information they requested from the start.
You can check for the X-Forwarded-Port header, which is 443 if the request came to the load balancer over ssl. That would be HTTP_X_FORWARDED_PORT in the rack env.
We use this modified rack-ssl gem in our Engine Yard Rails app as a workaround.
142
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
