ASP.net design problem, forcing redirect to HTTP if on HTTPS

On my master page I have the functions:

/// <summary>
/// Forces user to use unsecure HTTP connection
/// </summary>
public void FoceUnsecure()
{
    SSLHTTPDirect(false);
}

/// <summary>
/// Forces user to redirect to SSL
/// </summary>
public void ForceSSL()
{
    SSLHTTPDirect(true);
}

/// <summary>
/// Perform the redirect to self
/// </summary>
/// <param name="SSLRequired">True = Force HTTPS, False = Force HTTP</param>
private void SSLHTTPDirect(bool SSLRequired)
{
    if (int.Parse(ConfigurationManager.AppSettings["UseSSL"].ToString()) == 1)
    {
        bool IsOnSSL = HttpContext.Current.Request.Url.Scheme.ToLower() == "https";
        if (SSLRequired && !IsOnSSL)
            Response.Redirect(ConfigurationManager.AppSettings["SecureDomainRoot"] + "" + Request.RawUrl);
        else if (!SSLRequired && IsOnSSL)
            Response.Redirect(ConfigurationManager.AppSettings["MasterDomainRoot"] + "" + Request.RawUrl);
    }
}

On my SSL required pages, it works fine. I just do Master.ForceSSL() and it redirects to the secure connection if they are on HTTP.

The problem is, I want to redirect all other pages to HTTP if they are on HTTPS without having to manually trawl th开发者_StackOverflowrough the pages adding the function call to ForceUnsecure().

Whatever I try, I can't seem to work out from the Master page if the ForceSSL() function has been called (using flags and such). Ideally I want something like

if(!SSLRequired && OnHTTPS){ForceUnsecure()}

But whatever I try the master page seems to perform all its checks BEFORE the content page makes a call to ForceSSL(). So I can never know the values the content page is setting.

---

In response to the comments, I'm turning this into an answer:

I know this isn't a direct answer to your question; however, I feel strongly enough about this to get on a soap box, so to speak.

---

First off, if whatever you have is sensitive enough to require a username and password, then you shouldn't kneecap your users by sending their session cookie data unencrypted by forcibly turning off SSL after the initial login procedure.

For most sites the amount of extra bandwidth and/or processing power necessary is trivial compared to loss of trust in the event that one or more accounts get hijacked. Only you can decide if it's worth it to turn OFF ssl.

If you believe that performance concerns may outweigh your business reputation, then use standard profiling tools against your application to see exactly what the impact is. These include one off tools like YSlow on up to "real" off the shelf tools like those included in the upper end versions of visual studio.

Worthwhile links:
(discussing performance impact of SSL)
How much overhead does SSL impose?
HTTP vs HTTPS performance

(discussing why turning off SSL after login is a bad idea)
http://codebutler.com/firesheep
http://codebutler.com/firesheep-a-week-later-idiot-shepherds
http://codebutler.com/firesheep-three-weeks-later-fallout

(stack overflows take on its security - or lack thereof) https://meta.stackexchange.com/questions/69171/why-doesnt-the-stack-overflow-team-fix-the-firesheep-style-cookie-theft

All of this said, there are special circumstances that should be taken into account. Namely, what is the potential downfall in the event an attacker intercepts and impersonates a user on your site? If there is zero or close to zero negative aspects then turning off ssl might be okay. Even then I'd only think about going this route if the cost of not doing it was more than I could bear.

---

Instead of doing it in your code, there is a module created by Matt Sollars that allows you to use the web.config to specify what pages need SSL and what ones do not. The library, article, and code is available at http://www.codeproject.com/KB/web-security/WebPageSecurity_v2.aspx.

---

You might want to take a look at the HttpModule class. These let you intercept requests and someone has done something along the lines of what you are trying to do.

---

Another aspect that has not been addressed so far is the effect on SEO. If you have two versions of a page that is linked to in both http and https format, then this can cause duplicate content issues in Google. In this instance, you should use 301 redirects to the appropriate protocol version of the page. So if your login page is https://mysite/login then you should do a 301 redirect if you are on http://mysite/login to the https version. Similarly, if you are linking back to the home page of your site from a secure url, you should use the non secure version of the home page url as this is what is most likely to be indexed in search engines. If this is not possible, then you can use canonical tags in the page to tell search engines that the preferred format of the page is http or https - which will have less efficacy than a 301 redirect, but better than nothing.

See this link for more info: http://www.mattcutts.com/blog/seo-advice-url-canonicalization/