FREAK VULNERABILITY: Disabling insecure export ciphers on Windows 2003 / 2008 / 2012 Servers

Major Update: March 10th, 2015

Microsoft has just released a patch to resolve the FREAK vulnerability on Microsoft Windows Servers and Workstations. Run Windows Update or your patch management system and make sure you install KB3046049 as soon as possible. They also provided a way via group policy to disable the ciphers for Vista+ systems.

Frequently Asked Questions

After installing the update, EXPORT ciphers are still enabled on Windows Server 2003; is my system protected?
Yes. While the EXPORT ciphers on Windows Server 2003 are still enabled after installing the 3046049 update, they are located further down in the default cipher priority order in Windows Server 2003. Windows client systems that have the 3046049 update installed will no longer downgrade the key length of an RSA key in a TLS connection to a Windows server…

Mitigating Factors

The following mitigating factors may be helpful in your situation:

  • A server needs to support RSA key exchange EXPORT ciphers for an attack to be successful; the ciphers are disabled in default configurations of Windows Vista/Server 2008 and later operating systems.


The following workarounds may be helpful in your situation:

Disable RSA key exchange ciphers using the Group Policy Object Editor (Windows Vista and later systems only)

You can disable the RSA key exchange ciphers in Windows Vista and later systems by modifying the SSL Cipher Suite order in the Group Policy Object Editor.

Note Installing this update (3046049) protects systems from the vulnerability discussed in this bulletin. Customers who have previously implemented this workaround will need to follow the steps for undoing the workaround if they want to use any of the ciphers that were previously disabled.

To disable the RSA key exchange ciphers you have to specify the ciphers that Windows should use by performing the following steps:

  1. At a command prompt, type gpedit.msc and press Enter to start the Group Policy Object Editor.
  2. Expand Computer Configuration, Administrative Templates, Network, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, double-click SSL Cipher Suite Order.
  4. In the SSL Cipher Suite Order window, click Enabled.
  5. In the Options: pane, double-click to highlight the entire contents of the SSL Cipher Suites field and then replace its contents with the following cipher list:
  7. Click OK
  8. Close the Group Policy Object Editor and then restart your system.

Impact of workaround. Windows will fail to connect to systems that do not support any of the ciphers listed in the workaround. To determine which ciphers are available for each cryptographic protocol refer to Cipher Suites in Schannel.
How to undo the workaround.

Follow these steps to disable the SSL Cipher Suite Order policy setting:

  1. At a command prompt, type gpedit.msc and press Enter to start the Group Policy Object Editor.
  2. Expand Computer Configuration, Administrative Templates, Network, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, double-click SSL Cipher Suite Order.
  4. In the SSL Cipher Suite Order window, click Disabled and then click OK.
  5. Close the Group Policy Object Editor and then restart your system.


Original Post


Vulnerability in a Nutshell

The FREAK vulnerability is made possible by two things — browsers being tricked into requesting a session via insecure ciphers, and the server being configured to allow insecure ciphers. Many browser developers are racing to find a way to have their browsers not behave this way. I can’t put it any better than ArsTechnica did:

The so-called FREAK attack—short for Factoring attack on RSA-EXPORT Keys—is possible when an end user with a vulnerable device—currently known to include Android smartphones, iPhones, and Macs running Apple’s OS X operating system—connects to a vulnerable HTTPS-protected website. Vulnerable sites are those configured to use a weak cipher that many had presumed had been retired long ago. At the time this post was being prepared, most Windows and Linux end-user devices were not believed to be affected.

Attackers who are in a position to monitor traffic passing between vulnerable end users and servers can inject malicious packets into the flow that will cause the two parties to use a weak 512-bit encryption key while negotiating encrypted Web sessions. Attackers can then collect some of the resulting exchange and use cloud-based computing from Amazon or other services to factor the website’s underlying private key. From that point on, attackers on a coffee-shop hotspot or other unsecured network can masquerade as the official website, a coup that allows them to read or even modify data as it passes between the site and the end user.


To put it another way

The bug allows attackers to monitor traffic between vulnerable users and servers and inject malicious code which causes them to use a weak encryption key while transmitting data. They can then listen in on the exchange, masquerade as the target website and intercept data to read or modify it.


Browser fixes aside, nothing is preventing an attacker from manually initiating a handshake via weak crypto. They don’t have to rely upon a browser for this: it could theoretically be initiated manually via other means. So then importance is placed on making sure servers don’t honor weak cipher requests.

To repeat: Servers assist in making the vulnerability possible, as they may honor requests for weak ciphers. The traffic can then be captured and cracked with relatively little resources – about 100 bucks and 7 hours on amazons cloud.

Testing for the Vulnerability

I used the following to see if one of our webservers was susceptible to the FREAK vulnerability. To do this test, I used an Macbook Pro with OpenSSL installed – you could just as easily test from one of the web-based testing tools ( or from a Linux machine.

I issued the following simple command, telling my machine to connect to my server and use an available EXPORT cipher:

openssl s_client -connect servernamehere:443 -cipher EXPORT

As you can see, the 2003 server I tested on was vulnerable. Note the cipher: EXP-RC4-MD5


A response from a server properly configured to not accept a request for EXPORT cipher is as follows:

hostname:~ luser$ openssl s_client -connect -cipher EXPORT


45288:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.10.1/src/ssl/s23_lib.c:185:

Note the bolded handshake failure – this is what we want to see.

Disabling the (un)Secure Ciphers

In the typical Microsoft fashion, different attributes of the operating system are managed and handled differently between versions. The following section will illustrate what you can do to prevent the server from presenting the unsecure export ciphers.

Note: Even though the ‘Enabled’ DWORD may be missing, the cipher is still allowed to be used as they are on by default. You can test this behaviour by performing the FREAK vulnerability test with OpenSSL and attempting to use the export cipher while the Server doesn’t have the Enabled DWORD — it will work.

Server 2003

For better or for worse (mostly worse), Server 2003 is alive and well in many companies. Yes, its end-of-life and not supported soon, but that doesn’t change the fact that it is still in widespread use.

Server 2003: Supported Protocols and Ciphers


  • Transport Layer Security (TLS) version 1.0
  • Secure Sockets Layer (SSL) version 3.0
  • Secure Sockets Layer (SSL) version 2.0


Bolded are the ciphers indicated in the FREAK Vulnerability

  • AES 128/128
  • AES 256/256
  • DES 56/56
  • RC2 128/128
  • RC2 40/128
  • RC4 128/128
  • RC4 40/128
  • RC4 56/128
  • Triple DES 168/168

Server 2003: To Mitigate FREAK Vulnerability

Simple, but you would be hard pressed to find a blog post or Microsoft article indicating as such.


  • Open regedit
  • Browse to HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128
    • Add the “Enabled” DWORD and set it to 0x0 — this disables the cipher immediately, no reboot required
  • Browse to HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128
    • Add the “Enabled” DWORD and set it to 0x0 — this disables the cipher immediately, no reboot required

Now, as I stated above, even though the Enabled DWORD was not there to begin with, the cipher was still allowed to be used — it is on by default and you confirmed this by doing testing. To turn it off, you must enter the Enabled DWORD and set it to 0x0.

After this, re-test and you will get the appropriate handshake failed output.

Server 2008


As with Server 2003, Server 2008 and Server 2008R2 are alive and well and in production out in the wild. A slight difference is between 2003 and 2008 is that RC4 is disabled in 2008, but not for everything. I quote Microsoft:

RC4 is not turned off by default for all applications. Applications that call in to SChannel directly will continue to use RC4 unless they opt in to the security options. Applications that use SChannel can block RC4 cipher suites for their connections by passing the SCH_USE_STRONG_CRYPTO flag to SChannel in the SCHANNEL_CRED structure. If compatibility must be maintained, applications that use SChannel can also implement a fallback that does not pass this flag.

So, to ensure the export cipher is not available for use, we need to disable it at the system level. Microsoft states its off by default, but to be absolutely sure you can add the registry entry, it won’t hurt.

Server 2008: Supported Protocols and Ciphers

[Will be added soon — try to find this info from Microsoft!]

Server 2008: To Mitigate FREAK Vulnerability

Follow the same procedures as server 2003, the difference is you might have to make the entire key including the DWORD — example:

Within HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\ the RC2 40/128 and RC4 40/128 keys might not be present. Make them, and enter the Enabled DWORD and set it to 0x0. 

Again, this is just to be safe, as the SCH_USE_STRONG_CRYPTO flag is application dependant. Thus, if an application doesn’t send that flag, it may be unsecure and accept the useless crypto.  If you want to be safe, just turn off the ciphers all together with the above registry keys.

Server 2012

Server 2012: Supported Protocols and Ciphers

[Will be added soon – try to find this info from Microsoft!]

Server 2012: To Mitigate FREAK Vulnerability

Follow the steps for Server 2008.



So, there you have it. Test your web servers, and disable the export ciphers if necessary. As an aside, all SSL versions have their vulnerabilities, as does TLS1. SSL, in fact, is no longer PCI-compliant — any version up to and including SSL 3.0. See the release notes by PCI here:

The National Institute of Standards and Technology (NIST) has identified the Secure Socket Layers (SSL) v3.0 protocol (a cryptographic protocol designed to provide secure communications over a computer network) as no longer being acceptable for protection of data due to inherent weaknesses within the protocol.”

So, with that in mind, you may also want to go further and disable any insecure cipher/protocols. If you follow the above steps, you will be preventing the FREAK attack, but there are other vulnerabilities that you need to watch out for as well.

Not on Windows?


If you aren’t running Windows Servers you are not immune to the FREAK vulnerability. You will also have to disable ciphers and protocols. The way you do this, much like Windows, can vary from flavor to flavor of Linux or Unix that you are running.

Mozilla came out with a good primer configuration editor, you can see it in action here: – this will give you a baseline of how to secure your Apache/Nginx/HAProxy servers. While this isn’t comprehensive, it is a far sight better than running the default installation and unsecure ciphers and protocols.

Other Resources


(Visited 26,705 times, 293 visits today)

1 Comment

Leave a Comment

Your email address will not be published. Required fields are marked *