AWS Elastic Load Balancer有选择地启用SSL

Question

I currently have a rails-based web app that requires a small subset of pages to be served over HTTP - but prefer to serve the rest over HTTPS. In my current AWS setup, SSL terminates at the elastic load balancer and all communication with my app servers is over HTTP. Because of this, solutions like Rack SSL Enforcer aren't appropriate. Currently, I'm serving the following JS snippet in each page to handle the redirect:

<% if should_be_ssl? %>
<script>
  if (window.location.protocol != "https:"){
    window.location.href = "https:" + window.location.href.substring(window.location.protocol.length);
  }
</script>
<% else %>
<script>
if (window.location.protocol != "http:"){
  window.location.href = "http:" + window.location.href.substring(window.location.protocol.length);
}
</script>
<% end %>

This results in a relatively significant performance hit each time one of these pages is accessed. Does anyone know of a way to selectively serve certain pages over SSL and control this at the load balancer level?

Answer 1

This isn't currently supported in the ELB itself, however the ELBs provide an X-Forwarded-Proto header. You can check this to see whether the request from the client was over HTTPS. You can then serve a redirect response rather than the page content if necessary. See this blog post from the AWS guys for more information.

You'll have to implement this logic either

1. with middleware, eg rack-ssl-enforcer

   Looking at the documentation for rack ssl enforcer , it appears to support the X-Forwarded-Proto out of the box, so you may not need to do anything at all. You can see in the source that the header is respected.

2. in your application (probably with a redirect response rather than on the client)

3. in a reverse proxy, eg an haproxy between your app server and the ELB

    acl is_http hdr(X-Forwarded-Proto) http acl account_login url_beg /account/login redirect scheme https code 301 if account_login is_http 

Depending on your configuration, if you have any other reverse proxies between the ELB and whatever's checking the header, you may need to configure those to pass the X-Forwarded-Proto header correctly. See this issue , for instance.