Announcement

Collapse
No announcement yet.

IE page renders fail on some https pages, but not others

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • IE page renders fail on some https pages, but not others

    All my clients are Win7 x86, fully patched as of 25 Nov. This is customer support situation, where our Win7 clients cannot talk directly to the Internet, the customer controls a proxy gateway which we must use. When accessing https pages on the Net, the proxy requires a user authentication before it goes to the net, but once the credentials are verified, the user sees their desired page render (normally). After the Nov update cycle, some https sites only result in the classic, uninformative 'IE was unable to display the page.' We have verified the certs we use internally, the certs issued by the customer which are used by the proxy to make the secure connection with us, and we've verified that the I'net pages render just fine on non-proxy I'net-connected machines. One of the sites we're no longer able to hit from inside the 'protected environment' is https://google.co.uk. We admins have found that by playing with the Advanced IE Security options, we can get partial renders of the pages that fail for the users, but the https pages that render fine for the users, render fine for all of us. One of the failed pages is business-critical for our program.

    We've tried looking into certificate key lengths, encryption strength, certification paths, and have come up dry. Everything we check, checks out. We suspect the Nov CU for IE (KB3100773) is the culprit, but there's no info in Windows registry or on the Web that describes how to uninstall it, and we can't figure out what has changed between what we are enforcing under GP vs what has changed under this KB. I've been at this for almost 2 weeks now with nothing to show for it. We're now looking at unlocking every setting in GP for IE and starting GP all over again to see what works or what breaks. Any suggestions about how to tackle this would be appreciated.
    Last edited by RicklesP; 14th December 2015, 21:02. Reason: More info after Dec WSUS updates block
    *RicklesP*
    MSCA (2003/XP), Security+, CCNA

    ** Remember: credit where credit is due, and reputation points as appropriate **

  • #2
    We're still bogged down. We've mapped IE zone settings in our protected environment the same as on an internet-connected Win7 PC so that scripting/ActiveX/etc. settings are identical, and it's still not working. For the Internet zone, if we kill all TLS settings and use only SSL 2& 3, Google works fine but our business-critical site won't even partially render. If we turn on TLS 1.0 the business-critical https site partially renders but is problematic, and Google may or may not break at that point. If I turn off either SSL, Google breaks completely, and nothing works if only TLS 1.0, 1.1, 1.2 are turned on. We also copied the Trusted Sites zone settings across from the internet PC since our business-critical site is listed in that zone from Group Policy.

    If anyone knows of an in-depth troubleshooting guide for IE when a proxy is involved, I would love to know about it. The staff responsible for the proxy insist there's nothing on their side which could be the issue here, and identifying problems with TLS is not well-documented on the web. Please, anyone??!!

    UPDATE: we have identified Nov update KB3081320 as the culprit, now have to work out removal/remedy options for production system. Had to take a crash-course in Wireshark 2.0 to do it, but at least we know why. Once that's removed, all TLS web traffic returns to normal (on a test box, anyway). In case you're curious.
    Last edited by RicklesP; 15th December 2015, 23:36.
    *RicklesP*
    MSCA (2003/XP), Security+, CCNA

    ** Remember: credit where credit is due, and reputation points as appropriate **

    Comment


    • #3
      OK the final chapter: it has been resolved, but not necessarily how MS would approve. We finally tracked down that 3 different updates from the Nov cycle were the culprits, whether installed together or in any combination. Reading the MS articles on them shows that they are interrelated enough that MS warns you about the installation order, should you apply them manually, or only 1 at a time thru WSUS. The KB articles are: 3081320, 3101246, 3101746. We installed them in the same cycle, and that's when our SSL-thru-proxy broke, but only for some HTTPS sites and not others. Since the proxy config info is a closely guarded secret and I'm not important enough to be allowed into that particular circle, our only solution is to remove all 3 updates completely and disable them in WSUS to prevent future application. If any 1 is left installed, the failure issue persists. And they have to be removed in sequence. And the PC has to be rebooted after each removal. And Updates aren't easily uninstalled thru scripting like 3rd-party programs (no uninstall strings easily traced in the Registry). So I scripted Powershell to check for the presence of each update in sequence using the 'Get-Hotfix' cmd, and if found, run 'wusa /uninstall /kb:<refnumbr> /quiet /forcerestart'. That script calls for each of the 3 updates, and is run at PC startup by a Scheduled Task deployed thru GPP. The script file is also copied to a 'scripts' folder on each client by the same policy. So when everything is in place, and we shut the PCs down late evening and bring them back up in the wee hours, that startup kicks off the task which ends up restarting the PC 3 times, once for each KB removal. After the last restart, web browsing works as expected.

      We still suspect the issue is a combination of our more advanced settings from these updates vs the proxy config, but that's another hurdle. At least the users can once more access the business-critical site hosted outside the proxy environment. I described this fiasco in case anyone else ends up with something similar. Enjoy.
      *RicklesP*
      MSCA (2003/XP), Security+, CCNA

      ** Remember: credit where credit is due, and reputation points as appropriate **

      Comment

      Working...
      X