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!

PowerShell – Help

Last year I had the opportunity to self-educate myself on Microsoft PowerShell. Having had just too little experience with it I thought it was about time to dig in and at least learn the basics. So I bought a book and got started. In the next couple of blog posts I will share my experiences and notes that I took over the month’s that I had my first try at learning PowerShell. Although the language can be very complex, it all starts out with having the basic skills to understand the language. After that it’s getting the experience that counts. Today I’ll start with a very important topic. Getting help…

Tip! Always start the PowerShell command-prompt or the Integrated Scripting Environment (ISE) elevated. Throughout the blog post I’ll use the ISE as much as possible. It has far better and more modern way of working.

First things first

The beauty of having PowerShell is that is a modern language integrated with not just local resources but also online repositories. The help functionality is no different. Although Windows ships with an up to date help file for PowerShell, things can change very quickly. So it’s always A good idea to update the local help files every now and again. Here’s a few tips on how to do it.

Update local help files
Use the following Cmdlet to update the help content.

Update-Help

Download help content
Suppose not all your systems are Internet connected, use save-help to store help files locally.

Save-help -path <path>

Offline-Update
Use the -SourcePath on the target system to update the help files

Update-Help -SourcePath <path>

Tip! man & help are wrappers for get-Help cmdlet

After the help files are updated it’s time to make use of them. In a command-line environment it’s really not that hard. First you need to figure out what command you need help on. That can easily be done be done with Get-Command. Suppose we want to do something with Windows Services. We could use something like this:

Get-Command *service*

The output will look something like this:

get-cmd

Tip! Use the following to list only the Functions and CmdLets

Get-Command *service* | Where {$_.CommandType -eq "Cmdlet" -or $_.CommandType -eq "Function"} | select Name

Or use the “Commands” Window in the ISE. That will bring up a list of only the Cmdlets (PowerShell Commands) and functions that you can use. Getting help from the ISE is also very easy. Just click on the little blue icon with the question mark to get the help overview.

ise-help

To get the same output as available in the ISE and more on the command-line, use these parameters after the get-help Cmdlet. Let’s use the Get-Service CmdLet as an example.

Quick help

Get-Help Get-Service

Detailed Help (without parameter details)

Get-Help Get-Service -Detailed

Full information (I always use this)

Get-Help Get-Service -Full

Examples

Get-Help Get-Service -Examples

Up-to-date online information

Get-Help Get-Service -Online

That’s all for this post on the PowerShell help system.

Reference


Get-Help
https://technet.microsoft.com/en-us/library/ee176848.aspx

Update-Help
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/update-help

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

Enable Schannel logging

To enable logging for Secure Channel logging (Schannel), use the following guide.

Add the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging (REG_DWORD)

Set one of the following values:

0x0000 Do not log
0x0001 Log error messages
0x0002 Log warnings
0x0004 Log informational and success events

When troubleshooting I like to set it to 0x0007 (0x0001 + 0x0002 + 0x0004). Reboot your machine to start the logging process.

The data will end up in the “System” eventlog with the source name of “Schannel”. You would want to keep an eye out for event id 36880, indicating a succesful event. It would look something like:

A SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.2
CipherSuite: 0xc028
Exchange strength: 256

To translate the CipherSuite use the following site:
http://www.thesprawl.org/research/tls-and-ssl-cipher-suites/

In the example above this would translate to: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Reference


TLS/SSL Settings

https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx

TLS/SSL Security Considerations

https://technet.microsoft.com/en-us/library/dn786446(v=ws.11).aspx

Cipher Suites in TLS/SSL (Schannel SSP)

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

Prioritizing Schannel Cipher Suites

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

How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll

https://support.microsoft.com/en-gb/kb/245030

Update to add new cipher suites to Internet Explorer and Microsoft Edge in Windows

https://support.microsoft.com/en-gb/kb/3161639

IIS Crypto

https://www.nartac.com/Products/IISCrypto/

Custom RDP Certificate on Windows Server 2012 R2

Ever since Windows 2012 the Remote Desktop host tool has been removed from the system, making it more difficult to set a custom certificate. When you’re in a domain context it’s more likely that you will use GPO’s and domain related tools to configure your system, but in my work environment I deal with stand-alone systems, making it a bit harder to manage. During one of my security scans with our vulnerability tool it started complaining about self-signed certificates. Simply removing the certificates from the local computer store and using WMI to update the system is fairly easy, but after doing the same trick twice, it gets annoying so I decided to write a PowerShell script to handle the task of setting the correct certificate.

My script has a couple of parameters that you can use:

Set-RDPCertificate.ps1 -Hash <string> [-Delete] [-Terminalname <string>] [<CommonParameters>]
Set-RDPCertificate.ps1 -listCerts [<CommonParameters>]
Set-RDPCertificate.ps1 -ListCurrent [<CommonParameters>]

  • Hash: This is the default input parameter, expects a 40 character string value
  • Delete: Delete the current certificate from the local store after setting the provided hash value.
  • Terminalname: If you changed the default RDP-TCP connection name you can enter it here, not providing the parameter will result in using the default name.
  • Listcert: Lists the certificates in the personal store of the local computer.
  • ListCurrent: Lists all certificates in the personal store of the local computer.

Download the script from here. Version 1.1.

5 Steps to get started with Azure DSC

In our never ending quest to improve our production environment we are currently looking into the possibilities that Microsoft Azure can offer us. One of offerings that has our interest is state enforcement management with Windows PowerShell, also known as “Desired State Configuration”. I was already deeply impressed with the capabilities that are offered when running DSC on a local box, via PowerShell remoting or using the pull method on-premise. Only thing that was a bit challenging is deploying the configuration in a world wide, loosely connected, non domain environment, Microsoft Azure to the rescue.

Basically PowerShell DSC is a state enforcement platform, much like Group Polies are. With the increased usage of the cloud it’s become clear that group polices via Active Directory are not the way forward anymore, especially for non-domain type systems. We need a way to do remote state enforcement whenever we need it, on demand without the requirement to make use of a self-hosted on premise environment. Introducing Microsoft Azure Desired State Configuration. Follow the steps below to make your first DSC Configuration document, Create an Automation Account, Assign the Document and configure a server to use DSC.

On this page:

  1. Creating the Automation Account
  2. Import the Configuration
  3. On-boarding the target
  4. Apply the meta-data configuration file
  5. Assign the configuration
  6. Downloads
  7. Reference

Creating the Automation Account

Azure DSC makes use of an automation account. Follow these steps to first create that account.

  1. Login to the Azure portal at https://portal.azure.com
  2. Select “More Services
  3. Type “Automation”, click “Automation Accounts
  4. Click “Add” next to the large plus sign
  5. Add the appropriate data in the ‘Add Automation Account” page. Click “Create

automationaccount

Wait a few moments for the account to be created

Import the Configuration

Once the Automation Account has been created we can start to configure desired state. Click on your just created automation account. The blade for configuring the account will open. Click on the “DSC configurations”, located in the “Configuration Management” section. The DSC Configuration node is the store where your configuration documents are saved. These documents dictate the state of your machine. Click the “Add a configuration” on the top of the page. In the “Configuration file” click the folder icon and browse to your configuration file. In my case I’ve created a document that tells the system to install the default Web Server (IIS) role and remove SMBv1, but you can basically configure your entire system this way. Click “OK” to return to the previous blade.

Give it a second to import the file.

What we need to do next  is tell Azure to convert the configuration document to a .mof file that it can deploy. To accomplish that just click the configuration that you just imported. The blade that opens allows you to convert the ps1 script to a .mof file. Click on the “Compile” button on the top of the page. Read the message and click “Yes”.

ConfigurationFile

Close the blade after the compile action successfully completes .

On-boarding the target

Now that the main configuration is done we need to on-board the server that we want to target with DSC. Microsoft made that a really simple task with providing an on-boarding script. This script is available at:

https://docs.microsoft.com/en-us/azure/automation/automation-dsc-onboarding

Just in case that location ever changes, you can easily locate the url again by browsing to your “Automation Account” blade, clicking “DSC Nodes” in “Configuration Management” and click on “Add on-prem VM”. Browse to the “Generating DSC metaconfigurations” section and copy the script content.

The only basic things that needs to be changed in the script are the “RegistrationUrl”, “RegistrationKey” and the “Computername” value. Just for fun we’ll also change the state enforcement policy by setting the “ConfigurationMode”. You first need to get the values for “RegistrationUrl” and the “RegistrationKey”. These are located in the “Automation Account” blade, “Account Settings” select “Keys”. You can use either the primary or the secondary key.

Once updated the code in the script would look something like this:

ComputerName = @('localhost');
RegistrationUrl = 'https://we-agentservice-prod-1.azure-automation.net/accounts/5eb0794a-a035-406e-8181-ece99172d6fa';
RegistrationKey = 'qLVkKkhBe4+RfVEkuIl2TicZSvzUEj+1jPXvdd0SkDM662zwolUcyVx2KzvSoUsSHZpK7FvlzkF4WuxZh4G8CA==';
ConfigurationMode = 'ApplyAndAutoCorrect';

In the example above I apply the configuration to the localhost instead of an individual hostname. That’s just the situation I’m in. Your situation could be very different. Once the script is ready, it needs to be executed to generate the meta-data configuration .mof file.

Apply the meta-data configuration file

Applying the configuration meta-data file can be done multiple ways, by using PowerShell remoting or just apply it locally on the box. In this demo I’ll use the latter.
Copy the “DscMetaConfigs” folder to the local box. Open an elevated PowerShell ISE or PowerShell Command console and use the following command to configure the system.

Set-DscLocalConfigurationManager -Path .\DscMetaConfigs

In case you want to check the configuration that’s been applied, use:

Get-DscLocalConfigurationManager

Assign the configuration

Last step we need to take is assigning the appropriate DSC configuration to the server. Obviously we need to do this in Azure. Select your “Automation Account” and click on the “DSC Nodes” under “Configuration management”. The Server that we used the on-boarding script on should be listed here. Click the Server name, next click the “Assign node configuration” icon at the top of the screen. On the “Assign Node Configuration” blade that opens, click the generated configuration document (If you used my script it will show “MyFirstConfiguration.MyServerRole”). Click “OK”.

And that’s really all there is to it. After waiting for about 15 minutes the configuration will be applied on the selected server.

dsc-node

Tip! Just in case you don’t want to wait, use the cmdlet:

Update-DscConfiguration -Wait –Verbose

To force the consistency check on the target server.

Downloads


MyServerRole PowerShell Script

OnBoardComputerInAzureDSC

Reference


Windows PowerShell Desired State Configuration Overview

https://msdn.microsoft.com/en-us/powershell/dsc/overview

Azure Automation DSC Overview

https://docs.microsoft.com/en-us/azure/automation/automation-dsc-overview

Getting Started with PowerShell Desired State Configuration (DSC)

https://mva.microsoft.com/en-US/training-courses/getting-started-with-powershell-desired-state-configuration-dsc-8672?l=ZwHuclG1_2504984382

Hybrid IT Management Part 3: Automation

https://mva.microsoft.com/en-US/training-courses/hybrid-it-management-part-3-automation-16631?l=MQrdRCHrC_4406218965

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.

 

Windows Update Error 0x80072ee2

For a while now I’ve been getting timeouts when using Windows updates through our proxy servers. Everything else seems to be working just fine, no complaints on browsing the web, it just seems that whenever I’m using Windows update through the proxy it takes a few times before it’s successful. Up until now it wasn’t really a problem because we use internal WSUS servers, however testing the Microsoft Operation Manager Suite and pointing Windows update to the Internet for getting the patches made it clear that connectivity issues were getting in the way of progress. Every time we scheduled an update run, it’s would time out on the proxy with error 0x80072ee2, direct connection went fine on all occasions. To make a long story short it turns out that the underlying mechanism of Windows Updates depends on the Background Intelligent Transfer Service (BITS), which in turn uses a different mechanism to connect to the internet (WINHTTP).

Normally it will use your Internet Explorer proxy to connect to the Internet, yet this seems to be having a few issues where Windows Update is unable to connect. What helped me in fixing the problem is telling WINHTTP to always use a dedicated proxy instead of relying of the automatic detection of a proxy or use the settings from Internet Explorer. Simply use good old netsh or use the powershell cmdlet:

Set-BitsTransfer

to accomplish this task.

List the current proxy
netsh winhttp show proxy

Set a proxy server
netsh winhttp set proxy <FQDN:Port> 

Reset the proxy for winhttp
netsh winhttp reset proxy

Reference


Can’t download updates from Windows Update from behind a firewall or proxy server

https://support.microsoft.com/en-us/help/3084568/can-t-download-updates-from-windows-update-from-behind-a-firewall-or-proxy-server

How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site

https://support.microsoft.com/en-us/help/900935/how-the-windows-update-client-determines-which-proxy-server-to-use-to-connect-to-the-windows-update-web-site

Windows Update Error List

https://support.microsoft.com/en-us/help/938205/windows-update-error-code-list

Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)

https://technet.microsoft.com/en-us/library/cc731131(v=ws.10).aspx

Set-BitsTransfer

https://technet.microsoft.com/en-us/library/dd819421.aspx

Best Practices When Using BITS

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

Windows Activation

At times I need a semi isolated Lab environment that will last for an extended period of time. Using Windows as an operating system I could fall back on using the evaluation version of the OS but wouldn’t it be cool if I could be using our corporate activation services for that? Luckily there’s a very easy way to get your machines activated, even when you run a lab environment. As most of you know Windows activation is accomplished by using the KMS service. It’s a service that uses anonymous RPC at port 1688. Being anonymous by nature is something we can take advantage of. To start using the corporate server you should do an inventory first. On your corporate network use the NSLookup utility to query for KMS entries.

nslookup -type=srv _vlmcs._tcp

If your environment contains KMS servers it will list something like this:

vlmcs._tcp.corp.contoso.com SRV service location
priority=0
weight=0
port=1688
svr hostname=kms01.corp.contoso.com
ms01.corp.contoso.com internet address = 192.168.10.100

Now you have the name and IP address of your corporate kms server, go to your lab setup and create a DNS service record in the _tcp. zone.

  1. Open the DNS management on your DNS server.
  2. Expand the DNS Zone.
  3. Right-click on the “_tcp” folder and select “Other” -> “New Records“.
  4. Select Service Location (SRV) as the new record type.

Fill in the following information for the new DNS record:

Service: _VLMCS
Protocol: _tcp
Port: 1688
Priority: 10
Host offering the service: kms01.corp.contos.com (or the IP address)

Go to your client or server and at an elevated command prompt type:

slmgr /ato

this will activate your machine. Use:

slmgr /dlv

to see the activation status.