Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

IE 11 update fails due to prerequisite updates (KB2729094)

IE 11 update requires the following prerequisite updates – link.

Even after installing those (most of which are already there) IE 11 install will complain and fail. The log files are in C:\Windows\IE_.main.log.

In my case I was getting the following error (seems to be the same for others too):

Thing is I already had this hotfix installed, so there was nothing more to do. Found this useful support post where someone suggested running the hotfix install and side-by-side launching the IE install. Might need to do it 2-3 times but that seems to make a difference. So I tried that and sure enough it helped.

That post is worth a read for some other tricks, especially if you are sequencing this via SCCM. I found this article from Symantec too which seems helpful. Some day when I am in charge of SCCM too I can try such stuff out! :)

After Windows Update KB 3061518 many websites stop working in IE

At work every time some of our IT staff would access the BES server web console, IE would fail. Not with a 404 Page not found error but with a web site cannot be found error (with helpful hints to check your Internet connection, DNS, etc). 

The web console worked fine on my machine. I could ping the server from all machines and telnet to port 443 (HTTPS port) from all machines. The IE security, SSL, and certificate related settings were the same across all machines (including mine). Firefox gave the same error on all the machines – something about cipher suites – this was odd, but at least consistent across all machines (and we use IE with the console usually so wasn’t sure if Firefox always gave this error or it was just a recent occurrence). 

Since it didn’t seem to be a browser specific setting, and the Firefox cipher error was odd, I felt it must be something at the machine level. Unlike Firefox (and Chrome) which use their own SSL suite IE uses the Windows Secure Channel provider so there must be something different between my install of Windows and the problematic users. I had a look at the Event Viewer when opening the site in IE and found the following error: 

image001Couldn’t find much hits for that error The internal error state is 808 but at least it was Schannel related like I suspected. 

Time to find out if there were any difference in the Windows updates between my machine and the users. The following command gives a list of Windows Updates and the installed date:

The result was something along these lines (these are updates that were installed in the last two weeks on the problematic machine but not on my machine):

Since the problem started recently it must be one of the updates installed on the 20th. Going through each of the KB articles I finally hit gold with the last one – KB 3061518. Here’s what the update does:

This security update resolves a vulnerability in Windows. The vulnerability could allow information disclosure when Secure Channel (Schannel) allows the use of a weak Diffie-Hellman ephemeral (DHE) key length of 512 bits in an encrypted Transport Layer Security (TLS) session. Allowing 512-bit DHE keys makes DHE key exchanges weak and vulnerable to various attacks. For an attack to be successful, a server has to support 512-bit DHE key lengths. Windows TLS servers send a default DHE key length of 1,024 bits. After you install this security update, the minimum allowed DHE key length on client computers is changed to 1,024 bits by default, instead of the previous minimum allowed key length of 512 bits.

The workaround is simple. Either fix TLS on the webserver so its key length is 1024 bits or make a registry change on client computers so a key length of 512 bits is acceptable. I tested the latter on the user machine and that got the web console working, thus confirming the problem. Save the following as a .reg file and double click:

Reading more about the update I learnt that it’s a response to the logjam vulnerability against the Diffie-Hellman Key Exchange. I had forgotten about the Diffie-Hellman Key Exchange but thankfully I had written a blog post about this just a few months ago so I can go back and refresh my memory. 

Basically the Diffie-Hellman is an algorithm that helps two parties derive a shared secret key in public, such that anyone snooping on the conversation between these two parties has no idea what the shared secret key is. This secret key can then be used to encrypt further communication between these parties (using symmetric encryption, which is way faster). A good thing about Diffie-Hellman is that you can have an ephemeral version too in which every time the two parties talk to each other they generate a new shared secret to encrypt that conversation. This ephemeral Diffie-Hellman version is generally considered pretty secure and recommended (because if someone does ever break the encryption of one conversation, they still have no way of knowing what was talked about in other conversations). The ephemeral version can also use elliptic curves to generate the shared secret, this has the advantage of also being computationally faster. 

Anyways, ephemeral Diffie-Hellman is still a secure algorithm but there’s an unexpected problem with it. You see, back in the old days the US had export restrictions on crypto, and so web servers had this mode wherein they could be asked to use export ciphers and they will intentionally weaken security. A while back this “feature” was in the news thanks to the FREAK attack. Now it’s in the limelight again thanks to the logjam attack (which is what Microsoft’s KB fix above aims to fix). Unlike FREAK, though, which was an implementation bug, logjam is just expected behavior – just that no one still remembered this is how the system is supposed to behave now!

Here’s what happens. As usual the two parties (client and web server) will talk to each other in the open and come up with a shared secret key using the (ephemeral) Diffie-Hellman Key Exchange. In practice this should be foolproof but what could happen is that if the web server supports these export ciphers mode I mentioned above, someone could come in between the client-server conversation and ask the server to switch to this export mode (all that’s required is that the client – or rather someone pretending to be the client – ask the server for export grade ciphers). When the server gets this request it will intentionally choose weak parameters from its end as part of the Diffie-Hellman Key Exchange (specifically it will choose a 512 bits key that will be used to generate the ephmeral key later). The server won’t tell the client it’s choosing weaker parameters because it thinks the client asked, so the client is none the wiser that someone is playing mischief in between. The client will use these weaker parameters with the result that now the third party can try and decrypt the conversation between the client-server because the key they agree upon is a weaker key. 

Note that this has nothing to do with the key size of the certificate. And it has nothing to do with Diffie-Hellman Key Exchange being weak. It is only about servers still supporting this export mode and so the possibility that someone could get a server to use weaker parameters during the Key Exchange. 

The fix is simple really. You, the client, don’t have much of a say on what the server does. But you can insist that if a server could choose a 512 bits key as part of the Key Exchange process then you will simply refuse to deal with said server. And that’s what the KB fix above does. Once installed, if Schannel (on the client) notices that the web server it is talking to allows for 512 bits Diffie-Hellman keys it will simply refuse to talk to that web server. Period! (Note the emphasis here: even if the server only allows for 512 bits, i.e. it is not actually offering a weaker Diffie-Hellman parameter but merely supports export ciphers, the client will stop talking to it!). 

On the server side, the fix is again simple. You have two options – (1) disable export ciphers (see this and this articles for how to on Windows servers) and/ or (2) use Elliptic Curve Diffie-Hellman Key Exchange algorithms (because they don’t have the problems of a regular Diffie-Hellman Key Exchange). Do either of these and you are safe. (In our case I’ll have to get our admins looking after this BES console to implement one of these fixes on the server side). 

And that’s it! After a long time I had something fun to do. A simple problem of a website not opening turned out to be an interesting exercise in troubleshooting and offered some learning afterwards. :) Before I conclude here’s two links that are worth reading for more info on logjam:  CloudFlare postwebsite of the team who discovered logjam, with their recommendations for various web servers.

Cheers.

Update: This post by Matthew Green is a must read on logjam. Key takeaways (in case you weren’t already aware):

  • Logjam only applies to the non-Elliptic Curve variants of DHE. Regular DHE depends on the difficulty of solving the Discrete Logarithm problem. ECDHE depends on difficulty of solving Elliptic Curves.
  • Discrete Logarithm is still difficult to solve, but for small values of its parameters (e.g. 512 bits) it is relatively easier. 
  • Things are also made easier by the fact that most web servers use a common set of prime numbers. So attackers can precompute a table of prime numbers and use these to degrade the connection so it uses one of these weaker set of prime numbers (whose attack tables are already with them) and use these to quickly decrypt. 
  • Read the rest of that post for lots more interesting details. Thanks to Bruce Schneier’s blog for pointing to the post. 

Also, remember: this is about the key exchange. Not about server identity. The server can use an RSA certificate to verify its identity but use Diffie-Hellman for key exchange (and that is the preferred scenario in fact as Diffie-Hellman is better). Here’s RFC 4492 which lists five different key exchange algorithms. Moral of the story is, use Diffie-Hellman as usual but either disable the export grade stuff (so there’s no chance of using weaker parameters) or switch to the better Elliptic Curve Diffie-Hellman. This has nothing to do with the RSA or DSA certificates that the server might otherwise use

Trying out Windows 10 Technical Preview & IE 11

I finally got around to installing Windows 10 Technical Preview in one of my VMs. I had downloaded it about a month ago and even attended an MVA session last month that talked about the new features. Unlike past versions Windows 10 is very much enterprise geared and that’s one reason I want to be in the know-how about it; in my view, Windows 10 is what most enterprises will upgrade to from Windows 7. Not that I hate Windows 8; in fact, unlike most people I love Windows 8 and its start menu, but I know from an end user point of view Windows 10 is the logical upgrade in terms of the UI. It retains the traditional start menu but combines it with the metro UI and apps.

Anyways, it’s been a good experience so far. After installing I upgraded to the latest Preview Build and also registered for the Insider Program. The version of Internet Explorer 11 on Windows 10 seems to be different from Windows 8.1. Both are called version 11 but the former seems faster and I am quite enjoying it actually. (Never thought I’d say I am enjoying IE, ever!) The MVA session too talked a lot about IE in Windows 10 (click this link for a “High MP4” download of the IE section).

The new IE seems to be big on interoperability and defaults to something called “Edge” mode (which was introduced in IE 8 but considered experimental so far). In the past IE had various document modes. IE 8 & IE 9 were versions where Microsoft rewrote most of the browser to support modern standards (the so called “modern web”) so they had to introduce “document modes” to support the older websites. Websites could ask to be shown in the “Edge” mode, which tells IE that the website is designed with modern standards and IE can behave accordingly; or the websites could asked to be shown in “legacy” modes, which tells IE the website is designed for one of the older version of IE and it will behave accordingly. However – if a website doesn’t specify which mode it wanted to be in, IE assumes it should be in “legacy” mode. This is reason why many websites appear broken in IE. The website may support modern standards, but because it doesn’t specify a mode IE assumes its legacy.

With IE 11 Microsoft is defaulting to “Edge” mode, which means that it will ignore whatever a website tells it and display it assuming its built for modern standards. Further, “Edge” mode is the final mode from Microsoft – unlike previous versions there’s no “IE 10” mode, “IE 9” mode, and so on. Just “Edge” mode, which is the latest and greatest always. To take care of Enterprises – which could contain websites where the document mode needs to be honored, IE 11 introduces an “Enterprise” mode. When in “Enterprise” mode IE 11 behaves like IE 8 in Compatibility View. So when IE 11 is in “Enterprise” mode and it encounters a website asking to be displayed in a certain mode, it will honor that, and if the website does not specify a mode it will display it in IE 5 “Quirks” mode.

The neat thing here is that for all home users IE 11 on Windows 10 should start displaying the Internet as it’s meant to be. And in the Enterprise side of things IT pros still use their legacy websites by taking advantage of the “Enterprise” mode and Compatibility View list etc as usual! So you get the best of both worlds.

(Although no relation to Windows 10, I came across this blog post from the IEBlog that shows how Microsoft is updating IE 11 in Windows Phone 8.1 Update to support more websites out of the box. Ironic, in a way, how Microsoft is now having to tweak its behavior and User Agent strings to make more websites display correctly in it. I remember a long time ago when it was the “other” browsers such as Mozilla and Opera that had to implement such tricks).

That’s all for now!

Recreating Windows profiles; Internet Explorer passwords

I had to recreate a user’s Windows profile the other day and made the novice mistake of removing the profile from his computer by just deleting the folder from c:\Users. Not a good idea coz that leaves all the registry stuff behind. The correct way to remove his profile would have been to go via the System properties, User Profiles, and then delete the profile. If it complains about the folder not being removed, then remove the folder.

What happened in my case since the registry stuff was still leftover is that Windows wouldn’t create a new profile folder because it thought the profile folder had an error. It kept logging the user in with a temporary profile and complained so: “You have been logged on with Temporary profile”.

Worse, I always thought HKEY_USERS was where all the registry stuff was stored so that’s where I kept looking to try and delete the registry bits manually. Finally I realized it’s under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList – doh! HKEY_USERS only has the registry hives for actively loaded profiles – not necessarily the one logged in interactively, but also user accounts running in the background or that have recently run (via “run as” etc).

So I went to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, found the profile (which now had a .bak suffixed to it), deleted it (because I want him to start afresh), and that got things working again.

After recreating the profile the user told me he wanted his Internet Explorer saved passwords. These are stored under HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 but I hadn’t saved his HKCU hive before deleting the profile. Not a problem – I had a backup of the profile folder, so I:

  1. Copied the NTUSER.DAT file from there to my computer (NTUSER.DAT is basically the HKCU hive for his account),
  2. Loaded it into my registry as a temporary hive,
  3. Exported ...\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 from this temporary location to a .reg file,
  4. Opened this file in notepad and renamed the root to HKEY_CURRENT_USER.

I then sent the .reg file to the user and once he opened it the passwords were imported into his registry.

Here’s the command I ran from an elevated command prompt to load the ntuser.dat file to a temporary location HKLM\TempHive:

Using the above temporary location, I had to rename HKLM\TempHive to HKEY_CURRENT_USER once I exported the key and opened in notepad.