After enabling FIPS on Windows 7, connection to XP MOde and XP Remote Desktop stops working

Question

In an effort to secure my Windows 7 Pro x64 workstationI turned on FIPS in the Local Security Policy editor.

Security Settings/Local Policies/Security Options/
System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing = Enabled

I can no longer access my XP Pro SP3 x32 laptop via Remote Desktop and my local XP Mode virtual machine no longer accepts the automatic login or the Integration Tools.

I turned on the feature in both XP environments, but it didn't help. Turning off the feature in my Windows 7 PC reenabled the features. I was able to connect both ways between my Windows 7 Pro x64 laptop and my workstation with FIPS enabled on both.

Did I miss a step?

Answer 1

Turning FIPS on doesn't help protect anything. It's only for people who absolutely must turn it on no matter how much it breaks and have no choice. If you have a choice, do not turn it on. FIPS is a regulatory compliance thing and complying with regulations you don't have to comply with is huge expense for zero payoff.

Believe it or not, even the people who pushed Microsoft into having FIPS support don't turn it on. They just need to mark a checkbox that says "FIPS compliant" on their purchasing forms. But they're not required to turn it on, and they don't, for the same reasons you shouldn't.

Nobody cares whether FIPS mode works, only that it actually be FIPS compliant. Again, there is no requirement that anything work in FIPS mode. So if it doesn't work, that's not considered an issue worth fixing. Turning FIPS mode on turns off anything that's not FIPS compliant.

Answer 2

This answer seems to be a bit harsh. Turning FIPS-140 compliance mode on does in fact provide some protections. It prevents the use of weaker crypto schema, which is protective.

This can be inferred, actually, from the comment above that "it drastically reduces the choices the system has" -- it removes crypto schemes that are no longer considered appropriate by the Federal Powers That Be. And as the answer noted, "Turning FIPS 140 mode on turns off anything that's not FIPS compliant". Stuff that isn't FIPS 140 compliant won't be known to work.

Turns out that is a good thing. In the first five years of the crypto module verification program, it was discovered that 25% of the submitted packages had errors in documentation, and 8% had errors in implementation. That is, if you were depending upon a commercial package already out there, there was about one chance in twelve that it was broken, and providing NO protection other than smoke.

But the tone of the message -- that enabling the FIPS 140 discipline breaks things -- is alas, correct. Crypto is hard. Programmers often don't have the discipline to do it right, particularly with legacy software. If one isn't in a federal environment where you must do it, most people don't do it.

But this is apparently changing. Enterprises are expecting disciplined security engineering from their coders. I'm hearing clients say "you know, there is this STIG that the feds use, shouldn't we do this?" Having standards (and FIPS is just "Federal Information Processing Standards") is a good thing, and supports interoperability and accuracy.

So if you enable FIPS 140 mode correctly, you have a good reason to expect that the other side should, if it is properly configured, be able to work in FIPS 140 mode as well. If not, file it as a bug with the system vendor!