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

Question

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 through 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.

Can't you place the SSL checks in a base class for the pages instead?Then you would have full control over the execution order of the checks and redirects. — PHeiberg, Mar 25 '11 at 19:57
@Chris, as I understand it, HTTPS is an expensive connection from both client + server point of view (it makes pages load slower). I only want my login/register pages secure, then the rest of the content can be HTTP. Problem is when they login it directs to HTTPS, then all the relative links after that will now point to the HTTPS relative pages. — Tom Gullen, Mar 25 '11 at 19:58
@Tom Gullen: HTTPS may be more expensive but using SSL only for some pages and not others can be a security risk. Someone can intercept whatever token you originally generated securely because it is used on non-SSL pages. See http://en.wikipedia.org/wiki/Firesheep — Brian Lyttle, Mar 25 '11 at 20:01
@Brian, are you suggestion all pages where a user is logged in should be SSL protected to prevent cookie hijacking? I haven't seen any sites that do that. — Tom Gullen, Mar 25 '11 at 20:04
@Tom Gullen: It is a bit more expensive, but not so much that you should actually be concerned. You might want to review: http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose and the answers here: http://stackoverflow.com/questions/149274/http-vs-https-performance — NotMe, Mar 25 '11 at 20:05
@Chris, thanks. I'm confused now, that people are suggesting any page where a user is logged in needs SSL. Is this true? SO doesn't do it. — Tom Gullen, Mar 25 '11 at 20:09
Finally, if you do **1 thing today**, read this: http://codebutler.com/firesheep — NotMe, Mar 25 '11 at 20:11
All I want to do is protect raw usernames and passwords at each point they are entered. That is all. — Tom Gullen, Mar 25 '11 at 20:12
@Tom: I've taken this very thing up on the meta site. In the words of Jeff Atwood: "we don't think the risk of someone stealing your Stack Overflow account is very dangerous" http://meta.stackexchange.com/questions/69171/why-doesnt-the-stack-overflow-team-fix-the-firesheep-style-cookie-theft SO is indeed failing. At least they thought about it whether I agree with them or not is immaterial. — NotMe, Mar 25 '11 at 20:14
@Chris, ok, I'm quite convinced now! I see it's not computationally expensive anymore, but how about extra bandwidth? And also total page load times, are there any studies/numbers on this? — Tom Gullen, Mar 25 '11 at 20:19

score 1 · Accepted Answer · edited May 23 '17 at 11:54

1

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.

edited May 23 '17 at 11:54

Community

1
1

answered Mar 25 '11 at 20:32

NotMe

87,343
27
171
245

Great answer thanks, this is why I love this site because I learn something every day. I'm going to force SSL now for all pages when a user is logged in. – Tom Gullen Mar 25 '11 at 20:33
I agree with you in principle, but there are actually very common, good reasons to force users in and out of SSL: shopping. There is no reason why a users' entire session needs to be secured when the only real risk is credit card fraud when they check out. Session hijacking puts, at most, the contents of their shopping cart at risk. Also, SSL can have substantial impact on performance, pages and resources on SSL-encrypted pages are not cached. That could matter a lot on a high-traffic site. – Jamie Treworgy Mar 25 '11 at 20:37
@jamietre: Not true. After someone has successfully paid for an order, shopping sites usually let them review and/or change their other details (like addresses). Imagine someone capturing a session, taking over the account, then having the shipping address changed on the order. Also, there are sites out there (Amazon as an example) that will retain the credit card number and allow you to order additional items without entering it again. – NotMe Mar 25 '11 at 20:40
@jamietre: Also, you might want to review this link for information on how to properly cache items even in SSL mode: http://hoisie.com/post/yes_browsers_do_cache_ssl_resources__so_please_use_googles_cdn – NotMe Mar 25 '11 at 20:42
Well, it's in the implementation details. I would just make them enter their password again whenever entering the secure part of the site or before allowing any changes. I'm sure even amazon makes you put in your password again before changing it so they couldn't really 'take over' your account, and of course you'd get an email the moment anything was actaully done. The practical risk is extremely low, and the benefits to a would-be hijacker also extremely low. – Jamie Treworgy Mar 25 '11 at 20:46
re: ssl caching, interesting, I guess I did what the author warned against: putting blind trust in a blog post :) anyway, as I said I do agree with you in principle, but session hijacking is not something you're likely to see outside of public wi-fi networks. I think a much greater concern is snooping people's passwords, because people use the same ones for many different sites. Nobody should ever log in via clear text - i use hashing to avoid this when there's no SSL (e.g. for a site that's not really dealing with anything confidential). – Jamie Treworgy Mar 25 '11 at 20:51

score 0 · Answer 2 · answered Mar 25 '11 at 19:59

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.

score 0 · Answer 3 · answered Mar 25 '11 at 19:59

0

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.

answered Mar 25 '11 at 19:59

Brian Lyttle

14,558
15
68
104

score 0 · Answer 4 · answered Jul 27 '11 at 10:39

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/

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

4 Answers4