What does force_ssl do in Rails?

In a previous question I found out that I should be setting nginx ssl termination and not having Rails process encrypted data.

Then why does the following exist?

config.force_ssl = true

I see this commented out in the production config file. But if the expectation is that nginx will handle all the ssl stuff so that my rails app doesn't deal with encrypted data then what does config.force_ssl = true do?

Should I leave it commented out in production if I know I will always be using nginx?

It doesn't just force your browser to redirect HTTP to HTTPS. It also sets your cookies to be marked "secure", and it enables [HSTS][1], each of which are very good protections against SSL stripping.

Even though HTTPS protects your app at "https://example.com/yourapp" against MITM attacks, if someone gets between your client and your server they can rather easily get you to visit "http://example.com/yourapp";. With neither of the above protections, your browser will happily send the session cookie to the person doing the MITM.

[1]: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security "HSTS"

Setting config.force_ssl includes ActionDispatch::SSL. The ActionDispatch::SSL docs describe the functionality as follows (emphases added for clarity):

> See the includes here and the docs for ActionDispatch::SSL here.

###DOCS

This middleware is added to the stack when config.force_ssl = true, and is passed the options set in config.ssl_options. It does three jobs to enforce secure HTTP requests:

1. TLS redirect: Permanently redirects http:// requests to https:// with the same URL host, path, etc. Enabled by default. Set config.ssl_options to modify the destination URL (e.g. redirect: { host: "secure.widgets.com", port: 8080 }), or set redirect: false to disable this feature.

2. Secure cookies: Sets the secure flag on cookies to tell browsers they mustn't be sent along with http:// requests. Enabled by default. Set config.ssl_options with secure_cookies: false to disable this feature.

3. HTTP Strict Transport Security (HSTS): Tells the browser to remember this site as TLS-only and automatically redirect non-TLS requests. Enabled by default. Configure config.ssl_options with hsts: false to disable. Set config.ssl_options with hsts: { … } to configure HSTS:

• expires: How long, in seconds, these settings will stick. Defaults to 180.days (recommended). The minimum required to qualify for browser preload lists is 18.weeks.
• subdomains: Set to true to tell the browser to apply these settings to all subdomains. This protects your cookies from interception by a vulnerable site on a subdomain. Defaults to true.
• preload: Advertise that this site may be included in browsers' preloaded HSTS lists. HSTS protects your site on every visit except the first visit since it hasn't seen your HSTS header yet. To close this gap, browser vendors include a baked-in list of HSTS-enabled sites. Go to https://hstspreload.appspot.com to submit your site for inclusion. To turn off HSTS, omitting the header is not enough. Browsers will remember the original HSTS directive until it expires. Instead, use the header to tell browsers to expire HSTS immediately. Setting hsts: false is a shortcut for hsts: { expires: 0 }.

Requests can opt-out of redirection with exclude:

config.ssl_options = { redirect: { exclude: -> request { request.path =~ /healthcheck/ } } }

This setting forces HTTPS by redirecting HTTP requests to their HTTPS counterparts. So a browser visiting http://domain.com/path will be redirected to https://domain.com/path.

Leaving the setting commented out would allow both protocols.

You still have to configure your web server to handle HTTPS requests.

It forces all communication with the server to be encrypted and use SSL, i.e. through HTTPS.

When you include it in a controller that controller will only accept HTTPS requests.

Helpful links:

1. http://api.rubyonrails.org/classes/ActionController/ForceSSL/ClassMethods.html
2. http://rubydoc.info/docs/rails/ActionController/ForceSSL
3. http://railscasts.com/episodes/270-authentication-in-rails-3-1?view=comments