• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 426
  • Last Modified:

HTTPS is no longer "Enforced"

We have a web app since Adam and Eve. It is a ASP.NET app running on IIS 6 over a w2003 server. When a User logged in, somehow the app changed to HTTPS. Do not ask me how as that is now a matter of original development team vs. new.

However, I know for a fact this was the case. Now, it is not. New Head developer states nothing has changed and worst, than there is no code in the app to do this.

So, if anyone has any advice, it will be really appreciated.

Thanks in advanced.
  • 5
  • 4
2 Solutions
If it isn't in the program, I'd look in the server configuration.
Review this information: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/56bdf977-14f8-4867-9c51-34c346d48b04.mspx?mfr=true
phermiAuthor Commented:

Thanks but that is too obvious. I know how to do that and i fact the server accepts HTTPS request with no problems.

Is the change to HTTPS after the user logs in what does not work.

As a workaround, while I fight the developers, I thought I could re-direct all request to http://site.com to https://site.com by doing something on IIS. I have not found the way to accomplish that either.

phermiAuthor Commented:
Forgot to add .. if you do that, REQUIERE SECURE CHANNEL, HTTP request will produce an error.
We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

most likely there was a redirect in there somewhere.  There's a number of ways to do this:
* From the asp.net code itself

* By setting up two IIS Sites.  One for the ssl site.  A second for the http site that has a redirect rule to the https site (properties -> home directory -> "a redirection to a url")

* Similar to the above but the redirect occured on the firewall/load balancer instead.  If the developers say nothing has changed, and if whoever manages iis has said nothing has changed, then your network engineer might be the next person you go after.
A little more info: The second one was the one I used.  I would set up a www.mysite.com site and a www.mysite.com (redirects).  In addtion to ssl redirects where necessary, I'd do redirects from mysite.com to www.mysite.com.

Also, if you are using a firewall/load balancer to do the redirect, it's possible that it is still working.  What might of changed is your internal routing, dns, or proxying.  Last week your traffic might have been routed so it followed the same route that external traffic did, which means that it would hit the same redirect.  You now might be going to the iis server directly, thus bypassing the firewall's redirect.
phermiAuthor Commented:
d_levitt: Yes, and I tried that approach. The problem is that ALL pages are re-directd to HTPPS and we have one public page that uses CAPTCHA and it seems to be a proble displayng the CAPTCHA elements on HTTPS, which means that upon LOGOUT, we will reverse back to HTTP.

So, not to start a witches' hunt here, I am ordering the addition of code to fix this so that production and development environment work correctly .... The code looks like ths (for others in the future):


function forceSSLSubmit() {
    var strAction = document.forms[0].action.toString();

    if (strAction.toLowerCase().indexOf("http:") == 0) {
        strAction = "https" + strAction.substring(4);
        document.forms[0].action = strAction;


string url = Context.Request.Url.AbsoluteUri;
if (url.IndexOf("https") == 0)
url = url.Replace("https", "http");

HttpContext.Current.Response.Redirect(url, true);
ah, well if the ssl redirect is conditional, it is unlikely (but not impossible) that it was anywhere other than in code.  I appologize, I missed the "when the user logged in".

As far as your code goes, I would either recommend redirecting on the server side (although you seemed to indicate this is not possible because of your captcha control), or simply changing your form action or link to an absolute url (including the https).  Your javascript code may fail or be bypassed, plus the form url could be a relative link and not have "http:" in it in the first place.

Also, be sure that your logout redirect is after any logic that needs to occur.  A redirect to a non-ssl page will start a new session, which would probably cause your log out logic to fail.

Last, you could also have a secure.domain.com to redirect to.  This would give you better control of "forcing" ssl on all pages.  Although even sites like amazon don't redirect if the user manually changes the https to http so I'm not sure how much you need to worry about protecting users from themselves.

phermiAuthor Commented:
b_levitt: Thanks again. A far as we understand, JS can only fail if JS is not enabled in the browser. This is a system requirement for us as we used AJAK intensively. We are in fact changing the form action with that code, or so do we believe.

Logout: no problems, we are doing exactly that.

The redirect via another site is what I implemented as a workaround, but some "experts" state that this will mess up the search engines ratings.

Who knows?

For now, I am moving ahead with the code shown above, unless you bring me a compelling reason not to.

Thanks again.
Sounds good on all accounts other than the "search engine ratings" ...

I beleive you said the secure portion of this is protected by a captcha control so I'm not exactly sure how your "experts" think any spider is getting by that to index the site to begin with, let alone ranking it.  Even if it did, intrasite linking is NOT going to raise your ratings (links = votes and google isn't so stupid to let you vote for yourself).  Last, google is not going to see that javascript, so I would think that it would be better to have a link vs no link at all.

Sorry, don't mean to rant.  But SEO seems to be falling into the hands of marketing dolts that have captured a few technical buzzwords and then slap a name like "link juice" on a glass of cool-aid and sell it as something new.
phermiAuthor Commented:
No No .. I am confusing you.

Re-directing ALL traffic to HTTPS causes an issue in a PUBLIC page that uses CAPTCHA. That page is used to request DEMOs of the System and we do not want in any way to affect that part. Obviously, we can't afford non-SSL logins, so we put the redirect in place being the lesser of two evils.

Now, the "experts" advised us against using re-direct because it may have a negative impact on ratings. Whether that is true or not, I do not know ... but the problem is fixed now ...

Have a great one
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now