Internet Explorer Hardening Mysteries

Today I had a very interesting problem with system hardening and a new application that we are going to use. This application moved from a form based management interface to a web based one. Under normal circumstances this doesn’t provide a huge challenge because management of these type of apps is done over the network from a client based machine. However, since we have a solution that’s sometimes only reachable on the box itself I have to make sure that the local instance of Internet Explorer actually still works after I apply system hardening polices. And that’s where it’s gets confusing. In the explanation below I’ll use a simple page hosted on IIS, accessed locally through Internet Explorer on Windows Server 2012 R2.

On this page:

  1. The Basics
  2. Default Setup
  3. Some Magic
  4. Site to Zone Assignment List
  5. Computer Configuration
  6. Security Zones
  7. The Effects of User Account Control
  8. The Enterprise Solution
  9. Summary
  10. References

The Basics

Before we start there are a few basics that we need to discuss. Internet Explorer has something called security zone assignment. This means that every site that you open in the browser is assessed and placed into one of these zones. Each zone holds a different security configuration, so you can interact differently with sites you trust, are under your control, run in your data centers or are hosted on the Internet. Opening the Internet Properties, Security page actually reveals 4 of the 5 zones. There’s one hidden one (zone 0) which is applicable to the local computer (system) only.

  1. Local Intranet
  2. Trusted Sites
  3. Internet
  4. Restricted sites

These are actually the internal number Internet explorer assigns to the zones. We’ll be using them later.

Next I want to focus on a security feature called “IE Enhanced Security Configuration” that was introduced some time ago, but is almost exclusively disabled on all systems that I’ve seen, which is really unfortunate. Let’s be clear on one thing though. Having a browser installed on a server class device is under almost any circumstance a no-go. Just don’t do it. Your networking people have most likely setup all kind of network devices keeping your network secure and browsing from a server isn’t really helping. Getting all kind of nastiness directly into your server segment is considered bad practice. Having said that, our setup unfortunately can’t work in a different way. We have to deal with a browser on the box, hence we harden Internet Explorer and “IE Enhanced Security Configuration” is part of that. Basically it raises the security settings of the security zones we discussed above and some stuff more. If you want to know the details, type this in the Internet Explorer address bar:

res://iesetup.dll/IESechelp.htm#effects

Last thing that I want to address is the addition of “Enhanced Protected mode” of Internet Explorer. This extra layer of security was introduced in Windows 8. Its intent was to further enhance the capabilities of the original implementation of protected mode. It does so by enabling a sandboxing technology, Microsoft named AppContainers. The concept of using AppContainers goes back to the release of Windows Vista where the concept of integrity levels was introduced. Those levels separate abilities of processes running on different levels on the operating system.

More information can be found here:
https://msdn.microsoft.com/en-us/library/bb625962.aspx

Default Setup

Having a web application on your box and connecting to it using localhost simply works out of the box. That’s because the security settings in the security zones are configured in such a way that it’s an allowed operation. As I mentioned in the beginning, all sites are evaluated and placed in the appropriate zone. When you connect to localhost, the site is evaluated, placed in the “Intranet Zone” and those security settings are then used. From a UI point of view, just open the “Internet Options” – “Security“. Select the “Local Intranet“, click “Sites“, those sites listed will automatically be placed in the “Local Intranet” zone, sounds logically, right!

Now on Server 2012 R2, from a registry point of view, it gets a little bit more complicated. Per default security zone information is stored in the context of the current user, but depending if you have “IE Enhanced Security Configuration” enabled (or not) it’s stored in a different place. The UI however does a good job on storing them in the appropriate place.

IE Enhanced Security Configuration turned on (default)

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains

IE Enhanced Security Configuration turned off

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains

Some Magic

If you turn off “IE Enhanced Security Configuration“, the EscDomains default registry keys are completely cleared. Just take a look in the registry key or in the security tab. However, connecting to the localhost still works, even bringing up the properties of the webpage shows it being in the local intranet zone. Even though the localhost is not specifically mentioned anywhere the setting “Include all local (intranet sites not listed in other zones” is at play here. Anything not mentioned elsewhere and complies as being “local intranet” is placed in this zone. That’s why this still works. Restoring IE Enhanced Security Configuration will restore the default keys.

Site to Zone Assignment List

When you’re in a network managing a lot of machines you want to have a centralized way of managing devices. Usually that implies using group policies. Managing zone assignment for Internet Explorer is easy and at the same time very difficult because of the differences that you can encounter. Take the “Site to Zone Assignment List” policy as an example. This policy allows you to configure sites to fall into a certain zone. However this does not work when you have “IE Enhanced Security Configuration” enabled. And as far as I could find there’s no policy available to manage sites with a GPO when having “IE Enhanced Security Configuration” enabled, besides using group policy preferences. But that’s simply adding registry entries. This is a bit of a mess if you ask me as one would expect to have policies available for managing this.

Computer Configuration

As we have a requirement from the Internet Explorer STIG (Security Technical Implementation Guide) to use only computer based polices for Internet Explorer, this is actually the point where things start getting a bit more confusing. The policy I’m talking about is located here:

Computer Configuration – Administrative Templates – Windows Components – Internet Explorer – Security Zones: Use only machine settings

The idea behind this setting is that regardless if your user account falls into the scope of management for applying this policy, it’s simply always there. To be honest it isn’t even such a bad idea, it’s just that the execution is very different than using it on an user level. Let me explain.

If you set the above policy to enable, the text states. “If you enable this policy, changes that the user makes to a security zone will apply to all users of the computer”.

Right, so in my experience this simple is not true. Let’s give it a try. Enable the policy and open IE, go to “Internet Options“, “Security“, “Trusted sites“. Now add a website, for example bitsofwater.com to the trusted or intranet websites. Close the dialog and open the web site, next open the properties of the web site. Notice that it’s still in the “Internet” security zone! Hence the settings you make in the UI are not set in the registry and are not in effect. Funny part of the whole situation is that the keys actually end up in the correct registry place, or at least the place you would expect them to be.

001

Assuming the default setup of Windows with no additional policies, a notification popped up while opening the page. It informs you that the page is blocked, but does provide a means to add the web site. Let’s try the “Add” button and see what happens. Open up the properties of the web site and behold! The site is now placed in the appropriate zone! If you’re just a little bit like me you would what to know what magic is at play here. My choice of tools is again Process Monitor. There we see that the keys end up in a totally different place. In the “HKLM\Software\Wow6432Node” registry location.

002

So this means that a 32 bit process is actually writing the keys instead of an expected 64 bits process. Adding the architecture column in Process Monitor actually shows this little gotcha.

Now for some real confusion. Yes it’s getting worse. Open IE again, “Internet Options“, “Security“, “Trusted Sites“. Is the page listed? Nope, it’s not! So we can safely conclude that the UI does not play nice when the computer only policy is enabled. It’s registry only and the settings should be in the ‘Wow6432Node” registry key section.

Note! In this case it doesn’t matter if you turn of “IE Enhanced Security Configuration” the effect is still the same.

Note! Per default the Wow6432Node EscDomains registry is empty and is not populated. Turning “IE Enhanced Security Configuration” off and on again creates the keys. That sure causes a lot of confusion.

Security Zones

After I finally figured out what a mess the above actually was it got me wondering if this actually got a further effect on the zone configuration itself. Let’s try a little something. Per default the “Local Intranet” zone doesn’t have protected mode enabled. To get a little more advanced here, the setting in the zones registry configuration has the name “2500”, the value indicates its configuration state. More info can be found here:

https://support.microsoft.com/en-us/help/182569/internet-explorer-security-zones-registry-entries-for-advanced-users

Let’s start with the default. Set the policy “Security Zones: Use only machine settings” to off, applying the user policies again. A quick look at the current users hive shows that enabling protected mode for the “local Intranet” zone provides a value of 0 for the name 2500. So protected mode is on. A value of 3 turns it off.

Enable the “Security Zones: Use only machine settings” again, and see the effects. Opening the UI and selecting the “Security” – “Local Intranet” zone sets the “Enable Protected mode” to on. Looking in the registry again, the value ends up in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1\2500

So that seems to be doing alright.

Note! After further testing it seems that the key needs to be set in both the local machine and the Wow6432Node key to be effective. This should read, don’t mess around with registry keys when you have a policy available. Just think of the above as nice to know information.

The Effects of User Account Control

In the beginning of this post I mentioned that IE protected mode is built on integrity levels, which are a part of User Account Control. As most of you will start testing with the build in local Administrator account (or the domain administrator for that matter) the outcome will be very different. Per default the local administrator account is exempt from UAC and its effects. This directly implicates that protected mode for the local administrator is not in effect even when it’s set to enable. The full effect of having protected mode becomes visible when the policy “User Account Control: Use Admin Approval Mode for the built-in Administrator account” is set to enabled (a system reboot is required). After that the full implementation of protected mode is in effect. This has a direct effect of being unable to connect to the local host. As Applications that have protected mode enabled are prohibited from making a loopback connection. Solving it can be done by using the registry entry 2500 to the value of 3 (Set them in both the machine and Wow6432Node registry locations), use the UI when available but preferably use the “Turn on protected mode” policy for the Intranet zone.

There is another way, officially just for developers, but it works. Use the CheckNetIsolation.exe tool. Example:

CheckNetIsolation.exe LoopbackExempt –a –n=windows_ie_ac_122

More info can be found here:
https://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

The Enterprise Solution

After a few days of testing we’ve found a more effective solution which I would like to share here.

The following is actually the “Site to Zone Assignment List” policy but split up into http and https. This is applicable when “IE Enhanced Security Configuration” is enabled.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\localhost]
"http"=dword:00000001
"https"=dword:00000001

Adding the following code will populate the registry in all the required places. The trick here is that the settings above have to be set also. Anything listed here is then effectively applied on the system.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\localhost]
"http"=dword:00000001
"https"=dword:00000001

In our very special case we need to have access from the box itself to the localhost. As of Windows Server 2012 this is prohibited by “Enhanced protected mode” because it uses AppContainers. So we have decided that protected mode is turned off for the Intranet Zone when we need to connect to the localhost.

Computer Configuration – Administrative Templates – Windows Components – Internet Explorer – Internet Control Panel – Security Page – Intranet Zone – Turn on Protected Mode

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"2500"=dword:00000001

Just to make your life a bit easier I’ve created a GPO template that can be deployed in your infrastructure. Download it here: templates.

Save the files to the PolicyDefinitions folder and open the group policy editor. You will see an additional policy named “Enable Internet Explorer localhost Connectivity” in “Computer ConfigurationAdministrative TemplatesHardeningInternet Explorer“. Set it to “Enabled” to allow localhost connectivity.

Summary

My observations and recommendations.

  • Don’t always trust the UI, it only partially reflects the reality, especially with the computer only configuration.
  • Always set UAC to on, even for the local administrator account.
  • Populate the EscDomain in Wow6432Node using a policy or automate it.
  • Manual population of the keys occurs when you turn ‘IE Enhanced Security Configuration” off and back on again (suspect a bug).
  • Use the “Turn on protected mode” policy for the Intranet zone when you want to connect to the localhost and have “enhanced protected mode” enabled. Set it to disable the protected mode.
  • Windows Server 2016 has the same “bug”.
  • The above is not an issue on Windows Server 2008 R2.

Hopefully this helps you to understand how IE actually handles certain security aspects.

References


Understanding and Working in Protected Mode Internet Explorer
https://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx

How the Integrity Mechanism Is Implemented in Windows Vista
https://msdn.microsoft.com/en-us/library/bb625962.aspx

A Peek into IE’s Enhanced Protected Mode Sandbox
https://securityintelligence.com/internet-explorer-ie-10-enhanced-protected-mode-epm-sandbox-research/

Enhanced Protected Mode add-on compatibility
https://support.microsoft.com/en-au/help/2864914/enhanced-protected-mode-add-on-compatibility

Internet Explorer security zones registry entries for advanced users
https://support.microsoft.com/en-us/help/182569/internet-explorer-security-zones-registry-entries-for-advanced-users

How to enable loopback and troubleshoot network isolation (Windows Runtime apps)
https://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

3DES/FIPS 140-2/RDP Hotfix

In the past I’ve written a blog about the issues my company encountered when we disabled 3DES on our Windows 2008 R2 systems. Since we are obligated to also use FIPS 140-2 for compliance reasons the combination of disabling 3DES, and having FIPS140-2 enabled would break remote desktop functionality. Basically it came down to RDP using hardcoded 3DES when FIPS140-2 was also enabled. Needless to say RDP would stop functioning when you disable the one thing it could use. When the sweet32 vulnerability came along we had to make a choice, do we want to be secure or do we want to be able to remotely connect? Unfortunately since disabling 3DES is a system wide setting it’s not possible to differentiate between protocols. Leaving us stuck in between a rock and a hard place. Last option was to file a case with Microsoft.

It took us several conversations with Microsoft support, providing evidence and creating a business case for the Windows product group to determine the potential impact. One of the challenges we faced was that Windows 2008 R2 has been out of mainstream support for a couple of years now. So any change on this level would require the product group to agree upon a design change, which is very rare in these kind of situations. After a few month’s they agreed and we eventually got a preview fix that worked like a charm!

As of today I’m glad to be able to announce that a permanent fix has been released. As it’s a platform fix, bound to the operating system it will be included in the Microsoft update cycle of next month. My Microsoft representative has promised that an individual KB will be released soon describing the specific issue and solution. I’ll update this post when it becomes available.

A current hotfix is already included in the preview for September 2017, which you can get here:
https://support.microsoft.com/en-us/help/4038803/windows-7-update-kb4038803

Or get it from the catalog:
http://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB4038803

On a personal note, I would like to extend my gratitude to Microsoft support for the excellent push they did towards the product group convincing them on the necessity for this fix and working with me throughout this endeavor. My first experience being a customer instead of a Microsoft employee was a very pleasant experience!

0x800b010e – The revocation process could not continue – the certificate(s) could not be checked

I my line of work, every now and then I run into these unique situations. A few weeks ago we needed to do an application upgrade on a few of our systems. Once we started we got the following message:

0x800b010e – The revocation process could not continue – the certificate(s) could not be checked.

Okay, now what? Turns out that the combination of .Net or system hardening with a non-Internet connected system can trigger this error message. What happens is that the systems notices that the software is digitally signed. Because of its policies it tries to check the validity of the certificate and its revocation status. Since our systems are hardened its expected behavior. The software was digitally singed by Microsoft (signing is a good thing btw!), so it tried to reach the public Microsoft servers. Since it wasn’t allowed to go out and fetch the crl it failed. Luckily it’s a simple matter of switching a registry key to turn the revocation check on or off again. Since I can’t remember registry keys (and I seem to forget these kind of little tricks) I’ve written a PowerShell script to enable or disable the offline installation capabilities. Just in case you want to check the value on your system, use the setreg.exe tool from the SDK. In case you’re curious about the registry entry look at:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State (REG_DWORD)

The default value of state is 23c00 (Hex).

My script can be used with the following parameters:

Set-OfflineInstallationMode.ps1 [-On] [-Off] [-Force]

  • On: Enables the offline installation of signed binary files.
  • Off: Reset the system to the previous (or default) value.
  • Force: Ignore the previous setting and execute anyway.

You can download the script here. Version 1.0

Reference


Set Registry Tool (Setreg.exe)

https://msdn.microsoft.com/en-us/library/7zaf80x7(v=vs.80).aspx

SetReg

https://msdn.microsoft.com/en-us/library/windows/desktop/aa387700(v=vs.85).aspx

Challenges with Disabling 3Des

With the discovery of the sweet32 vulnerability (more at sweet32.info) in 3Des and 64-bit block ciphers in general, we had to see if it was possible to disable 3Des on our devices. You could be thinking, why have it enabled in the first place? Well, on Windows systems it’s enabled by default if you don’t take necessary steps and 3Des/168 is still a valid cipher in FIPS 140-2, which we must be compliant with. Disabling 3Des however is easy enough, handling the troubles afterwards is not. To disable 3Des add the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168\Enabled (DWORD) = 0

This disabled the following cipher suites:

SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Source: https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols-in-schannel.dll

During our tests on Windows Server 2008 R2 and Windows Server 2012 R2, the outcome was very different. Since we also disabled TLS 1.0 at the same time we ran into a few issues on 2008 R2. Just mind the following:

  • Make sure that you install KB308079, to add support for TLS 1.1 and 1.2 for RDP. HTTP already supports TLS 1.1 & 1.2
    https://support.microsoft.com/en-us/kb/3080079
  • Explicitly enable TLS 1.1 and TLS 1.2 in the registry of Windows Server 2008 R2 otherwise stuff will break. In our case, we couldn’t bind a certificate to a web site.
  • If you disable 3Des and have FIPS 140-2 enabled this will break RDP on Windows 2008 R2. We currently have a support case with Microsoft to see if this can be fixed (more info when it becomes available *).

* June 2017 – A hotfix for Windows Server 2008 R2 will be made available that fixes this specific issue.

*July 2017 – After intensive testing of a private hotfix no negative side effects could be found. A hotfix is scheduled to be released at the end of September 2017.

These are the major challenges we ran into. On Server 2012 R2, these issues didn’t occur. Just because I wanted to know what was going on under the hood I spend a day creating different scenario’s and monitoring results to see which ciphers would be used. I’ve listed the results below. Hopefully someone can make use of this information.

Scenarios

The following scenarios consists out of testing a Windows 7 client making a RDP or HTTP connection to a Windows 2008 R2 or Windows 2012 R2 server. Unless otherwise stated, the Windows client and server are patched with all security updates available. No additional updates have been installed. I would recommend against this setup in production, yet I know many organizations are reluctant to install additional updates in their environment. The conclusion of these tests shows that changes to the OS would have been covered if you install recommended updates as well. Security features, such as TLS, FIPS and 3DES are disabled on the server, not on the client.

Windows 7 & Windows Server 2008 R2

Protocol: Remote Desktop Protocol

  • Default (No changes to the Operating System): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 2008 R2: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 2008 R2: No connection
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: No connection
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.2

Observation: As you can clearly see in the results above, Windows 2008 R2 with FIPS 140-2 always connects with TLS_RSA_WITH_3DES_EDE_CBC_SHA/TLS1.0 even if you have disabled TLS 1.0. Disabling 3DES kills the RDP connection entirely.

Protocol: HTTP

  • Default (No changes to the Operating System): LS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 2008 R2: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 2008 R2: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on both: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: HTTP does a far better job in selecting the correct ciphers, with or without FIPS140-2 enabled it selects the highest suite available. However, without any adjustments it prefers TLS 1.0 over 1.2 even when kb3080079 is installed. Please be aware that on Server 2008 R2 TLS1.1 & 1.2 are explicitly enabled in the registry.

Windows 7 & Windows Server 2012 R2

Protocol: Remote Desktop Protocol

  • Default (No changes to the Operating System): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/TLS1.0
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: When connecting to Windows Server 2012 R2 over RDP, the protocol still seems to have mind of it’s own. Disabling TLS1.0 on the server side seems to be ignored until you have installed kb3080079 on the Windows 7 box. After installing that update TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2 is the preferred cipher regardless of FIPS140-2 compliancy.

Protocol: HTTP

  • Default (No changes to the Operating System):
    FIPS 140-2 Enabled: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled): TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Enabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 Disabled (FIPS 140-2 Disabled) & kb3080079 Installed on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Enabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2
  • TLS 1.0 / 3DES Both Disabled (FIPS 140-2 Disabled) & kb3080079 on Windows 7: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/TLS1.2

Observation: HTTP again is very consistent in selecting it’s cipher suite. Selecting FIPS140-2 compliancy has no negative or positive effect on the selection.