Why We’re Not Recommending “FIPS Mode” Anymore


In the latest review of the official Microsoft security baselines for all versions of Windows client and Windows Server, we decided to remove our earlier recommendation to enable “FIPS mode”, or more precisely, the security option called “System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.”  In our previous guidance we had recommended a setting of “Enabled”, primarily to align with US Federal government recommendations. In our updated guidance, the recommendation is “Not Defined”, meaning that we leave the decision to customers. Many people will correctly see this as a significant change, and it deserves explanation.

The United States Federal Information Processing Standard (FIPS) 140 standard defines cryptographic algorithms approved for use by US Federal government computer systems for the protection of sensitive data. An implementation of an approved cryptographic algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed National Institute of Standards and Technology (NIST) validation. A particular implementation of an algorithm that has not been submitted cannot be considered FIPS-compliant even if it produces identical data as a validated implementation of the same algorithm. Note that the requirement to use approved and validated algorithms applies only to the protection of sensitive data. Systems and applications are always free to use weak or non-validated cryptographic implementations for non-security purposes, such as in a hash table for indexing and lookup purposes.

What FIPS mode does

Enabling FIPS mode makes Windows and its subsystems use only FIPS-validated cryptographic algorithms. An example is Schannel, which is the system component that provides SSL and TLS to applications. When FIPS mode is enabled, Schannel disallows SSL 2.0 and 3.0, protocols that fall short of the FIPS standards. Applications such as web browsers that use Schannel then cannot connect to HTTPS web sites that don’t use at least TLS 1.0. (Note that the same results can be achieved without FIPS mode by configuring Schannel according to KB 245030 and this blog post.)

Enabling FIPS mode also causes the .NET Framework to disallow the use of non-validated algorithms. (More on this later, under “Why FIPS mode is particularly onerous.”)

A more complete listing of the effects of enabling FIPS mode can be found in KB 811833.

What FIPS mode does not do

Beyond the effects described above, FIPS mode is merely advisory to applications. Applications that do not check or choose to ignore the registry setting associated with FIPS mode and that are not dependent on the subsystems described earlier will continue to work exactly as they had with FIPS mode disabled. For example, a Win32 application – or third party disk encryption software – written in C++ that uses the very weak and non-FIPS-approved DES encryption algorithm exposed by the CryptoAPI will behave exactly the same whether FIPS mode is enabled.

Further, FIPS mode does not and cannot ensure that applications even use encryption at all when appropriate. There is nothing Windows can do to prevent an application from saving plaintext passwords or other sensitive data in unprotected files or registry values. The bottom line here is that just because a software product works when FIPS mode is enabled does not mean that it adheres to government standards.

Why FIPS mode is particularly onerous

Perhaps the biggest problems incurred by enabling FIPS mode involve applications that use the .NET Framework. If FIPS mode is enabled, the .NET Framework disallows the use of all non-validated cryptographic classes. The problem here is that the Framework offers multiple implementations of most algorithms, and not all of them have been submitted for validation, even though they are similar or identical to implementations that have been approved.

For example, the .NET Framework currently provides three implementations of the SHA256 hashing algorithm: SHA256Cng, SHA256CryptoServiceProvider, and SHA256Managed. The first two use “platform invoke” (a.k.a., “p/invoke”) to use Windows’ underlying implementations, which are FIPS-validated. By contrast, SHA256Managed, like all the other crypto classes ending with “Managed”, is implemented strictly in .NET managed code and doesn’t use the underlying platform implementations. Although it is an acceptably strong hashing algorithm for most uses, the Managed implementations have never been submitted to NIST for validation. And so if an application tries to use this class and FIPS mode is enabled, the Framework will raise an exception and not allow the class to be used; this exception will almost always cause the application to fail, if not terminate immediately.

Compounding the problem is that in most cases the Managed implementations of the various cryptographic algorithms have been available much longer than their Cng and CryptoServiceProvider counterparts, and on top of that, the Managed implementations tend to be significantly faster.

Another significant problem with FIPS mode is that until very recently there was no NIST-approved way to derive an encryption key from a password. That blocked use of the Bitlocker Drive Encryption feature that stored a computer’s 48-character recovery password to Active Directory. Using the relatively new standard for password-based key derivation functions, this is no longer a problem with Windows 8.1 and Windows Server 2012 R2, but it remains a problem for older versions of Windows.

Finally, the .NET Framework’s enforcement of FIPS mode cannot tell whether any particular use of a cryptographic class is not for security purposes and thus not in violation of standards.

Is Microsoft contradicting government regulations?

Government regulations may continue to mandate that FIPS mode be enabled on government computers running Windows. Our updated recommendations do not contradict or conflict with government guidance: we’re not telling customers to turn it off – our recommendation is that it’s each customer’s decision to make. Our updated guidance reflects our belief there is not a compelling reason for our customers that are not subject to government regulations to enable FIPS mode.

 

References:

FIPS 140 Evaluation
http://technet.microsoft.com/en-us/library/cc750357.aspx

"System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting effects in Windows XP and in later versions of Windows
http://support.microsoft.com/kb/811833

Comments (21)

  1. Theo Hardendood at Metis IT says:

    We had issues with VMWare SRM (Site Recovery Manager) and Exchange 2013 FastSearch. Everything worked fine after disabling FIPS mode.

  2. Michael Schoenbach says:

    A very nice article, indeed! It’s great to see all this information gathered together in one place, and the update is very timely for us and much appreciated.

    I also wanted to mention that I found the insight provided by Roger and Greg into actual usage to be very informative as well. We had wondered, given the problems we’ve experienced, if others were actually using the setting.

    For example, just yesterday we resolved a connectivity problem that we eventually traced to the FIPS setting imposed by USGCB. Although, to be fair, in this case the FIPS setting itself worked perfectly: it prevented an insecure SSL/TLS connection with an external
    website.

    While we’re on the topic of FDCC/USGCB, does anyone know if NIST’s published GPO settings will be updated? I haven’t been able to find information on their maintenance plans.

  3. Anonymous says:

    This suggestion may not be applicable to your situation, but when our organization deployed the United States Government Configuration Baseline (USGCB) to our user workstations we created one organizational unit (OU) for USGCB and a child OU that disabled
    FIPS mode.

    We then slowly moved workstations into the parent USGCB OU in small batches. If there was an issue with a workstation then we could quickly move the workstation into the child OU and use gpupdate /force to apply the new policy.

    If we could no longer reproduce the issue then we had determined that FIPS mode was the culprit, and the other USGCB settings would remain applied to the workstation. It wasn’t just a deployment tactic; we still use that child OU for a subset of our workstations.

    I don’t know of any method to identify incompatible software ahead of time, but this approach worked well for us.

  4. Anonymous says:

    Microsoft is pleased to announce the beta release of security baseline settings for Windows 8.1, Windows

  5. Roger A. Grimes says:

    Great article, Aaron. Nice update and research. With that said, when I was working with the US gov't, and I surveyed 20 different entities, 19 of the 20 didn't enable FIPS mode, even though it was supposedly required by FDCCUSGCB, as it broke too many things. It has always bothered me that FIPS was considered "a requirement" or standard when so many of those that supposedly had a legal requirement didn't.

  6. Greg Kessler says:

    Great article, and I completely concur. During our server security policy rollout, FIPS setting was eventually associated with several elusive errors in core business applications. This one recommended setting delayed us for months and nearly derailed our security policy rollout due to compatibility concerns.

    We tried to work around the impacted servers but as the list piled up we eventually decided to drop the setting entirely. As soon as it was dropped from the policy things went much more smoothly and deployment was completed within weeks, after nearly a year of delays.

  7. fubar says:

    This is silly. I love how they word it so slightly saying that its the customers choice to enable it, but Microsoft will never go on record saying "Don't use it!!!" The TLDR is, FIPS is backdoored by the federal government so you probably shouldn't use it, but are free to if you like. Thanks MS.

    [Aaron Margosis]  Note to self:  next time I see Satya, remember to tell him that if this "software" thing doesn't work out, maybe we should sell tin foil hats.  Seems like there's always a market.

  8. Tade says:

    Great Article…Totally concur. Once on a job and FIPS was enabled for a server bulk of our jobs were resident on…
    This stopped a whole days work from proceeding until it was reverted…
    I solely believe that business owners using windows client or server not compelled by subjection to government regulations do not have to enable FIPS.

  9. Jason says:

    While I realize that this setting does more than disallow SSL 2.0 and 3.0 I am curious if the announcements of the vulnerabilities (POODLE, FREAK, etc.) in those versions (TLS as well) is possibly changing the stance Microsoft is taking with this setting? Does Microsoft hear from their customers and counterparts a trend of this setting being enabled?

    I realize that this doesn't prevent application from using weaker methods and that it can still have adverse affects on .NET apps still using non-validated cryptographic classes. But would have to believe efforts in these two areas has started and will continue to change to use methods and classes that would be FIPS compliant.

    Thanks for any feedback.

    Curious and contemplating enabling…

    [Aaron Margosis] There are other ways to disable SSL 2 and 3 without enabling FIPS mode and dealing with all its side effects.

  10. Jason says:

    I forgot to add that I did know of other methods to disable SSL 2 and 3.

    Our organization (state government) by nature of the data we work with has to adhere to federal regulations and this item comes up on our reviews as not enabled (two that I have been involved with). At some point I believe we are going to need to take the step and start dedicating time and effort toward enabling the setting. The difficulty we face is there is no easy way (at least none that I am aware of ) to determine where there are non-FIPS compliant algorithms or FIPs compliant algorithms in use. On top of that when I have asked development staff what algorithms they use, if any, I get a blank stare or asked what I am even talking about. It would be nice to then take the stance that they are not doing any sort of cryptographic algorithm in their development but the moment we do that is when something goes wrong.

    Thanks for the quick response.

    [Aaron Margosis] I understand. It's particularly difficult with C++ code where FIPS mode often doesn't even cause a change in program behavior. And I harbor no illusions that this blog post or any other intelligent and rational explanations will convince auditors not to jump up and down when they see FIPS mode not enabled.

  11. EKummel says:

    Good explanation, but unfortunately, it's federal law in the USA that *ALL* computer systems in a production environment that is deployed for government use *MUST* be FIPS 140 compliant. This means Hardware, BIOS, OS, applications, network and data must all be configured to use FIPS. No exceptions! *NONE*! Look at what happened to OPM by violating this law!

    [Aaron Margosis] As the blog post explains, "FIPS mode" does not ensure compliance, and disabling "FIPS mode" does not mean "non-compliant."  And simply complying with FIPS crypto standards certainly does not prevent what happened to OPM!

  12. Ben says:

    How does one enable the ciphers individually if fips enabled is not an option?

  13. alt-92 says:

    @ Ben, see the 'What FIPS mode does' section and the links mentioned.

  14. John says:

    Playing a little devil’s advocate here but…

    I see a disturbing issue with many of these posts. It looks like quite a few people are disabling FIPS because it breaks something, and turning it off fixes their application. Kind of like making all users administrators fixes everything…

    It does not sound like most admins are actually verifying that the cryptography used by their applications is one of the “just as good but not certified” algorithms after Disabling FIPS. For the .NET issue, whose fault is it that the Managed implementations
    have never been submitted to NIST for validation anyway… Microsoft.

    And as far as ignoring the FIPS registry settings isn’t that the same for many windows security policy settings anyway. The way policies work most settings are voluntary especially if the developer does not care about getting their software Windows Certified
    and/or imports their own DLL libraries. I don’t think anyone has ever expected that Microsoft can control every insure application but if Microsoft is concerned about users confusing the scope of FIPS mode how about, just changing the setting name from “FIPS
    Mode” to “Disable Windows provided non FIPS certified algorithms”

    It’s not an easy issue but this entire post presents as kind of a Microsoft cop-out for a really difficult situation with out a solution. Rather than passing the buck wouldn’t it be better for Microsoft to provide better tools to its high security users. Why
    not make the tools for us to easily log what OS provided security algorithm are being used and by what applications. That gives us something concrete to go back to our application developers with and also an easily definable and testable goal for software
    publishers to reach.

  15. Dennis says:

    My main challenge is that we have a mandate to use FIPS compliance, but when we do even Microsoft components seem to work poorly. Example, Windows 2012 RDP is VERY slow when FIPS is enabled. Turn FIPS off and it magically works better. Finding any info about how to resolve this has been nothing short of painful.

    [Aaron Margosis] Dennis, can you please contact us through the "Email Blog Author" link under Options? Thanks.

  16. John says:

    The statement "Note that the requirement to use approved and validated algorithms applies only to the protection of sensitive data." is incorrect. Example a site-site VPN through the internet is encrypted for confidentiality/integrity, not necessarily
    because it is sensitive. Any encryption used by the Federal Govt is mandated to use FIPS validated encryption.

  17. Stef71 says:

    Good explanation, but EKummel23 from previous post is Right, FIPS mode MUST !!! be Enable on all machine (server and Desktop) to meet the FIPS201 and /or HSPD12 compliance

  18. Darren Wigfield says:

    It seems to me like this is a cop-out by Microsoft. If they're confident that the faster .Net-Managed encryption modules would also qualify as FIPS compliant, then they should just submit them to NIST for approval. Once they're approved, FIPS mode could
    be turned on, and the applications that use these modules would still work just fine.

    NIST provides a path for secure encryption modules to be approved. If MS doesn't want to take that path, they're the ones hanging the users, admins, and developers out to dry.

  19. Alan says:

    It is not just government computers that require FIPS-validated encryption. NIST Special Publication 800-171 now applies to all Defense contractor information systems that house any government data (including seemingly innocuous data like emails from the
    government contracting office) or any data that requires safeguarding such as contractor proprietary. This requirement creates a huge increase in the number of companies affected.

  20. Roc Myers says:

    Just finished an annoying wi-fi connectivity debug. The latest updates of Windows 10 and a new Marvell Avastar Net Adapter driver must use FIPS to connect with FIOS Quantum.

    [Aaron Margosis] Wow. That is unusual.