SSL Linking Strategy In Applications

Question

I'm interested in hearing what others do when, in a given application, some pages need to be secure and others don't. Take any solution off the table that requires a separate domain/subdomain. In this case, all calls, secure or insecure, will link to the same domain. I see a few options:

1. The ham-fisted, just secure it all approach.
2. A URI rewrite solution that ensure the pages that need to be secure are accessed via the https protocol and either ignores other pages or, alternatively, forces those to standard http
3. An application-centric approach where each link is responsible for knowing whether it's pointing and applying the correct protocol. In this solution, all links would have to be fully qualified.
4. A laissez-fair version of the application-centric approach where links to secure pages are fully qualified and links to other pages are not. In this case, the protocol would be inherited for pages not handled explicitly and inconsequential pages may be accessed via https.

I've used several of these from time to time, but they all have drawbacks. What's everyone else doing in these situations? Is there another path I haven't considered?

UPDATE:

vartec's answer below made me realize that I'd left out one critical piece of information. In my network config, all SSL-handling is taken care of at the load balancer level. The LB, then, communicates with the web server cluster via port 80. As a result, the applications themselves have no idea whether traffic arrived securely. All they see is a port 80 connection.

Thanks.

Answer 1

I use a mixture of #4 and #2: try to specify absolute URLs where possible when I need to switch protocols, and implement server-side redirection to catch any links I haven't used absolute URLs on (or if someone accesses the URL directly, not by following a link).

In my view, the one essential thing is that the pages which need to be accessed securely (form submissions etc.) are accessed securely, and for that I use Apache's SSLRequireSSL directive. It makes it easy to verify to myself that certain pages will never be accessed except over SSL.

Answer 2

I'm for the ham-fisted secure it all approach, but then you took my real solution off the table by (strangely to my mind) excluding domain/subdomain solutions. Errors in securing the site are far more dangerous than a bit of processing overhead.

We have our main site, which is insecure (but mainly marketing) and then we have the application site which is a different subdomain. Simple, easy and effective. Why take that option off the table?

Answer 3

Application centric approach, where controller for each page knows if it has to be secure. If it needs to be secure, but it's accessed via insecure http, redirect to https, passing along all of parameters.