Ask Ben: Enforcing An SSL (HTTPS) Connection Based On Request

Posted July 28, 2009 at 9:24 AM

Tags: ColdFusion, Ask Ben

Hey Ben!! I have a question for you that I really need help with. I have developed a website that didn't need to be encrypted. Now I was told that I had to incorporate SSL encryption. The problem is that user have the website http://yoursite.com bookmarked, and now when they come to the website they get a loading error on the website. What I need is some how to find out in the application.cfc what URL you are coming to i.e. http://yoursite.com or https://yoursite.com If you are coming from http://yoursite.com redirect you to https://yoursite.com I need to do all this before the application loads. Any Idea how to do this? I just not sure on how to pull in the protocol into the function. Thanks in advance.

Switching from SSL to non-SSL connections and vice-versa is something that's been blogged about a bunch of times, but I've never blogged about it personally. And so, I'll take this opportunity to share my methodology. To accomplish this request-switch, all we need to do is figure out two things:

1. Is the current request using an HTTPS connection?
2. Does the current request require an HTTPS connection?

Fortunately, the first piece of information is very easy to figure out. Using the CGI object, we can check the use of https using: cgi.https. This value of this property is not quite a boolean, but rather a on/off value. If the current request is using HTTPS, the value of cgi.https will be "on"; and, if the current request is not using HTTPS, the value of cgi.https will be "off."

The second piece of information - whether or not the current request requires an HTTPS connection - is more complex to figure out because the rules dictating this vary from application to application. Sometimes this is done based on the requested file; sometimes this is done based on the parent directory; sometimes this is done based on an action variable (ex. URL.action, URL.fuse); and, sometimes this is done based on something else altogether. That said, the solution I am providing shows a few options, but is in no way exhaustive.

Because this logic can be complicated, I have factored it out into its own function. This way, our logic is centralized and easy to read and maintain. And, because this logic needs to be run for every page request, I have put it right in the Application.cfc:

Application.cfc

 Launch code in new window » Download code as text file »

SSL connections are slow. As such, we only want the user to be using them when they have to. Therefore, it is just as important to enforce an HTTP connection as it is to enforce an HTTPS connection. In our Application.cfc function above, enforceSSLRequirement(), notice that I am forcing the current request to align itself properly with the requirements of the page, even it the current page does not require an SSL connection. In this way, we don't have to worry about what happens when a user leaves a secure part of the site to explore non-secure parts.

Keep in mind that the CFLocation we are using to forward the user to the proper protocol will break any form posts. This kind of code is not meant to auto-wire all of your HTTPS connections - you still need to post to the appropriate protocol from within your HTML forms (if necessary). This code is only meant to enforce SSL requirements - not to perform all SSL logic.

Like I said above, determining which pages require an SSL connection will require different logic from application to application. This demonstration was not meant to be exhaustive, but rather to examine how these SSL checks can be performed and enforced for each page request. I hope this helps.

Download Code Snippet ZIP File

Post Comment  |  Ask Ben  |  Permalink  |  Other Searches  |  Print Page

• Add To Del.icio.us
• Add To Digg
• Add to Spurl.net
• Add to Wists
• Add to Simpy
• Add to Newsvine
• Add to BlinkList
• Add to Furl
• Add to reddit
• Add to FARK
• Add to BlogMarks
• Add to Yahoo! My Web
• Add to smarking
• Add to Ma.gnolia
• Add to Segnalo

Reader Comments

Hi Ben,

Food for thought:

<cfset local.url = local.protocol & application.domainName>
<cfif cgi.script_name neq '/index.cfm'>
<cfset local.url = local.url & cgi.script_name>
</cfif>
<cfif cgi.query_string is not ''>
<cfset local.url = local.url & '?' & cgi.query_string>
</cfif>
<cflocation url="#local.url#" addtoken="no" statuscode="301">

This makes sure the user is at the domain name we want (maybe we want to force 'www.').
Then it only uses query strings if needed. It's a cleaner url.
And it uses 301 status code so search engines get the hint - stop indexing the page with the protocol we do not want to serve through.

@Jules,

Yes, enforcing a given sub-domain is also a really good idea. As far as the 301 is concerned, I think that makes more sense for the sub-domain idea and less sense for the SSL connection. Ideally, I don't think you want a search engine to be indexing things that are behind an SSL connection. I wonder if they even will? Hmmm, never thought about that.

I'd also note that the cgi.https flag doesn't seem to respond well when behind a hardware load balancer. At my last job, the connection was secure to the load balancer, but not between the load balancer and the CF servers, so CF never saw itself as being on HTTPS. I'm not sure if that was just an issue with the hardware configuration though, so it may be different other places.

Ben, you have to be careful using the CGI object. In our setup, SSL is done outside of the web server, on either accelerators or our load balancing server so the value of CGI.http is alwasy 'off'. To get around this, we constructed custom headers only set by the web server, as it receives http requests on one port and https requests on the other, as determined by the load balancer.

@Jon, @Phil,

Very interesting. I have not had the opportunity yet to play with a load balancer. Sounds like each solution is a bit different (between you and Jon).

@Ben,

My mind always thinks 'ecommerce' when I hear SSL. But of course SSL is ideal for extranets, too.

Following the thought of ecommerce... the largest way a visitor comes to the site is through a search engine. If you want to force visitors to use a certain protocol, then the best way to achieve that is to have them come over with that protocol in the first place.

And if the site is private, the 301 doesn't hurt anything anyway.

Here's a solution I found a few months back that I'm using on a CF7 site (that started as CF6). The site is still using Application.cfm instead of Application.cfc. This is the first few lines of code in Application.cfm.

<cfif not CGI.SERVER_PORT_SECURE>
<cfif CGI.QUERY_STRING neq ''>
<cflocation url="https://#CGI.SERVER_NAME##CGI.SCRIPT_NAME#?#CGI.QUERY_STRING#" addtoken="no" />
<cfelse>
<cflocation url="https://#CGI.SERVER_NAME##CGI.SCRIPT_NAME#" addtoken="no" />
</cfif>
</cfif>

I'd rather handle the protocol switch at the Apache level if the application needs to be completely protected by SSL at all times.

<Directory "/path/to/your/app">
# Force SSL on
RewriteEngine on
RewriteCond %{HTTPS} !=on
#RewriteCond %{SERVER_PROTOCOL} !^http [NC]
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [NC,L,R=301]
</Directory>

See http://claude.betancourt.us/how-to-force-a-url-to-use-https/ for more details.

In my case, we're running CF on IIS, so changes at the Apache level is not an option.

yes, content behind ssl can/will be indexed so long as it's publicly available (i.e., you don't have to be "logged in" to view it).

I usually handle this with IIS.

1) Create an empty index.htm page
2) Set index.htm as a server-side redirect to https://yourdomain.com/yourdefaultpage.cfm
3) Change the "SSL Required" error page to index.htm
4) Force SSL sitewide
5) Exempt index.htm from SSL requirement.

I assume you could easily do the same thing with apache in htaccess.

For some reason I went the route of creating a custom error template in IIS for this failure, which redirects, by way of a CF page, to the https address. I seem to recall that if I used SSL I had to require it, but it has been a while since I set this up so I could be mistaken. Otherwise it would seem that per-application redirection would be the way to go.

@Claude,

Does doing a rewrite on the HTTP->HTTPS actually do the same thing as the client actually making an HTTPS connection? Isn't there some kind of encryption that needs to be taking place on both ends for the HTTPS to work? It would seem that if this was being on via a rewrite, it would only be "on" for the server, but not for the client?

@JC,

That's an interesting idea. How do you force SSL such that an SSL error might be thrown. Is that a setting in IIS itself?

Aye, Ben.

In IIS, right click on a web site and choose properties > Directory Security > Secure Communications > Edit > Require Secure Channel (SSL)

Then do the same thing on the default file and uncheck it there, which exempts it.

I think I left out one step though -- you have to change the default homepage for the site to the nonsecure redirect one as well. That way people going to the / of the site get handled properly as well.

Apache's mod_rewrite is very odd. Claude's example will actually cause Apache to issue an HTTP redirect (what <cflocation /> does).

I was searching this topic thinking that the basic way to do this was on the secure pages use cflocation if the url is not already https. All other pages would be forced to be non SSL. I am surprised to see so many more complicated solutions. Usually only a few pages need to be secure, so I thought that would be the way to go. You all have me thinking that I am oversimplifying this.

Mark, When you say some pages do you mean only encrypting the login for example, or maybe only pages with sensitive info? I'm no expert on the subject but here are my thoughts. Many people don't initially think about the fact that every request to a domain/app includes applicable cookies. One thing to consider is that if someone has your cookies they can access the application as if they were you as session is based around cookies. They don't need your username and password. Requiring encryption for an entire application will not only encrypt the data submitted and pages accessed but also keep cookies secure from this sort of session hijacking.

@Mark, to a person who is an Apache/IIS expert and ColdFusion hacker, Apache/IIS configuration is dead simple while writing ColdFusion code to enforce something as simple as an HTTPS requirement is far too complex for the requirement.

I was thinking ecommerce, so login, and checkout pages. The more I think about it, the more I think that I need a url variable to distinguish http or https as Ben has done (top-secret).

I can't imagine any situation where a url-param indicating secure-connection-is-required would be useful. What I can imagine, however, is how insecure such a url-param would be.

@JC,

Ah, ok interesting. I've never seen that before. Cool tip.

@Justice,

Are you saying that the mod-rewrite shouldn't be doing a relocation? Or are you just clarifying that that is what it is doing (not just altering the script from the server standpoint)?

As far as a URL parameter determining security, this would happen in any front-controller based application where there are no "pretty" urls. For example, you might have a bunch of urls that look like:

index.cfm?action=account
index.cfm?action=help
index.cfm?action=security.login

In this case, the "action" url parameter would be the only thing that determines SSL requirements.

@Ben, mod_rewrite has a particular way of working which is not necessarily intuitive to everyone immediately. I was simply noting that the given example caused a HTTP 301 redirect, as can be seen from the "R=301" attribute.

A url-param like "?require-secure=true" is not very secure; that type of url-param seems to be what was implied. Using url-params to mimic Rails path routing or to mimic Django path matching, and then determining whether security is required for a given action, where the action requested is determined by the url-params, is perfectly reasonable (when done in a good way).

@Justice,

Ah, ok, that's what I figured you were saying. I know nothing about mod-rewrite, so nothing is obvious to me. I did not realize that R=301 did a redirect, thanks for the tip.

As far as URL-parameters, I agree with what I think you are saying - a parameter that determines security alone is not good; but, if the URL parameter is used for page flow, then it's all good (as the security enforcement is coupled to the workflow, not left on its own).

Post Comment  |  Ask Ben

Post A Comment

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Formatting: <strong>bold</strong> <em>italic<em>
	Remember my information
	Subscribe to entry *
	Send me a copy of this comment (as part of the comment thread)

 

* If you subscribe, any new posts to this thread will be sent to your email address.