2

I am currently using Internet Explorer 9 on Windows Server 2008. It seems that all https-requests to cdn.sstatic.net (SE's cookieless domain) fail. The corresponding http-request works fine for me. This is at least for the following urls (by going to the codegolf login page):

Inspecting the requests in IE9's developer console shows that the request was terminated before it even got to send the headers. My browser gives the dns-error page, which either means the hostname could not be resolved, or in case of https, that the protocol required is not enabled. As far as I am aware, DNS works exactly the same for http as it does for https, and since the http-link works fine, it is not an issue with DNS. In the settings SSL 3 and TLS 1.0 are enabled however, and the codegolf login page itself will load without an error page. I have logged in from this computer/network/operating system/browser and back then the page was working. That's also the only reason why I am able to post here.

I can't completely be sure that this isn't the company firewall acting up, but usually that blocks requests on both http and https. Besides that it normally gives me a message "This page is blocked, because it contains 'Humor'" or something along those lines. It could as well be a bug between IE9 and the setup of the cdn server. I am aware there are some similar questions like this one, but they either blame China, mixed content or temporary outage of the cdn server. Neither of them are the case here.

Improve this question
9
  • And when using another browser?
    – Arjan
    Apr 5, 2014 at 14:06
  • As for "That's also the only reason why I am able to post here" note that Meta is not using the CDN.
    – Arjan
    Apr 5, 2014 at 14:08
  • It's a company computer. I am not allowed to install any program, and therefore sadly can't use any other browser. I can't access cmd.exe either, and I don't really want to risk my job proxying my way around it somehow. And sorry, I assumed the login page here used cdn as well. I logged in on codegolf, SO, and meta before at my work, and because of that I stay logged in as long as the cookie is there. I am hoping for someone else that happens to have Windows Server 2008 and IE9 to test if they experience the same problem.
    – Sumurai8
    Apr 5, 2014 at 14:13
  • I wondered if IE9 was known to have trouble with the "Subject Alternative Name" in the certificate (though that should give a certificate error then), but that should be fine. Maybe the corporate firewall doesn't like that though. Is that something you could ask some system administrator? (And you're right about the DNS for HTTP and HTTPS being the same.)
    – Arjan
    Apr 5, 2014 at 14:19
  • I can think of 2 scenarios. 1. A firewall simply cuts the connection, or sends data back that does not complete the handshake, resulting in an aborted connection. 2. The client sends what it can handle, and the server responds with something the client can't actually handle, or responds with a failure handshake. If I could only enable TLS 1.1 and 1.2... Actually, that gives me an idea. I should be able to test what cipher suites I can use on the client and what cipher suites the server offers when I am at work again.
    – Sumurai8
    Apr 5, 2014 at 14:49
  • This is almost certainly an issue with your company firewall - is IE9 configured to use a proxy when other browsers are not?
    – Nick Craver
    Apr 10, 2014 at 4:00
  • @NickCraver There is no such thing as "other browsers" on this computer. IE9 is not configured to use a proxy, but since this computer is actually a session in the cloud, transfered to my screen through the magic of a thin client, there is probably a proxy behind that.
    – Sumurai8
    Apr 12, 2014 at 5:41
  • @Sumurai8 your traffic is not coming to our CDN without issue, it appears your session has a connection which blocks secure requests to certain domains or locations. Since CloudFlare has IPs issued from all over the world it's likely a block that's uninformed. If you can share more details we can ping the provider...but usually in these situations the nature of the client's (your) job does not allow disclosing such information, is that the case here?
    – Nick Craver
    Apr 12, 2014 at 11:14
  • I am indeed not in a position to give out such information. I cooked up an ugly, though effective piece of javascript to load all .js and all .css files from http. Not very secure, but it allows me to log in from my openid provider. Thanks for your help though.
    – Sumurai8
    Apr 12, 2014 at 12:38

1 Answer 1

Reset to default
2

The situation is probably caused by a firewall I have no control over. To fix the problem for myself, I log into SE on meta (here!), because they don't load the css and js from cdn, then go to the site I want to log in from and execute the following javascript from the developer console. It's not very pretty, and if you from a distant future and have the same problem, I encourage you to review the code before blindly executing it in your browser. You might need to agree to the mixed-content warning that appears.

It pulls all script-tags from the page and executes them in order, and loads them over http if they contain a "src" attribute. This will allow you to click the link to your openid provider and log in. If you really can't navigate without the appropriate css, you might want to look into this.

function loadStart() {
  var l = $('script').length;
  loadAll(0, l);
};

function loadAll(i, l) {
  if (i < l) {
    var a = $($('script').get(i));
    if (a.attr('src')) {
      var b = a.attr('src').replace(/(https?:)?\/\//, 'http://');
      console.log("Loading: " + b);
      $.getScript(b).success(function () {
        console.log("Success!");
        loadAll(i + 1, l);
      });
    } else {
      console.log("Loading inline script");
      eval(a.html());
      loadAll(i + 1, l);
    }
  }
};

loadStart();
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .