Is your Web site FIPS compliant?

FIPS compliance can be the key to working smoothly with servers and clients both in and out of government service

I’ve been involved in a lot of FIPS-compliance Web site testing lately. I’m a crypto hobbyist, not a crypto expert, so I hesitate to write about it, but I’ll explain the basics as well as I understand them. Crypto experts, please write in if I messed up something important.

[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

FIPS stands for the Federal Information Processing Standard, essentially a series of standards and mandates for U.S. government agencies and supporting contractors. In many cases, if your product or service is not FIPS compliant/certified, the government can’t use it. The FIPS documents are so respected that many other countries mandate them as well or have incorporated the bulk of their guidance into international standards.

There are many FIPS mandates, but the public pronouncements most Web site administrators care about is FIPS 140, which approves various cryptographic ciphers for hashing, signature, key exchange, and encryption purposes. FIPS 140-1 was approved in January 1994 and included the 64-/56-bit Data Encryption Standard (DES), which has since been removed as supported cipher. FIPS 140-2 was released in May 2001 and includes all the current approved ciphers, including the ones listed below:

Symmetric ciphers
Skipjack/KEA (EES)

Asymmetric Key-Signature

SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512

(Taken from "Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules")

It surprises many people to learn that Triple-DES (3DES) is still FIPS compliant; it is and will be for many more years. FIPS 140-3, the latest version, is currently under review and should be approved in 2009. Windows XP (RTM to SP2) is FIPS 140-1 certified. Windows Server 2003 and later, Vista, and Windows Server 2008, are FIPS 140-2 certified. The original ciphers supported in Windows XP were grandfathered to FIPS 140-2. A few ciphers were added or updated in Windows XP SP3, so XP SP3 has to be recertified, even though the ciphers are the same ones approved in Vista and Windows Server 2008. You can read the current status of any FIPS-certified product by going to this Web site; just search on your vendor’s name.

Additionally, the National Security Agency is pushing a new cipher requirement standard known as Suite B. It calls for many FIPS 140-2 ciphers, but it adds a few of its own (such as Elliptical Curve Cryptography) and specifies minimum key sizes. Windows Vista and Windows Server 2008 and later support Suite B ciphers. I’m not sure what distributions of Linux and other operating systems support Suite B, but it can be inquired of each OS vendor.

Certified and compliant
There is a common confusion point between FIPS certified and FIPS compliant. Clients frequently tell me that their Web site or database application has to be FIPS certified, but what they really mean is that it needs to be FIPS compliant. FIPS certification is a laborious, long, and expensive process, where a crypto vendor submits its product to a FIPS certification lab to obtain a FIPS certification certificate. Most noncrypto vendors are expected to be FIPS compliant, which means they use and rely on other FIPS-certified products for their solution. But there is a big, costly difference between the two options.

Many security standards, including the new Federal Desktop Core Configuration requirement, insist that participating computers be FIPS compliant. For Windows, this means enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" group policy setting, which can be done in Windows XP and later. This enforces the use of FIPS-compliant ciphers, including to SSL/TLS-protected Web sites. FIPS compliancy is supported in most current BSD, Linux, Unix, Mac, and Solaris distributions, as well as the popular OpenSSL software component.

FIPS-enabled computers can only connect to Web sites with FIPS-compliant ciphers for SSL/TLS. Windows servers running IIS should also have the aforementioned FIPS group policy setting enabled, along with the appropriate digital certificates and ciphers. Unfortunately, anyone who has had to implement FIPS-compliant workstations knows that many popular Web sites are not FIPS compliant. In order for your Web server to be FIPS compliant, it needs to work with at least one cipher SSL/TLS mechanism that supports contiguous FIPS-compliant ciphers for signing, hashing, and encryption (such as RSA_3DES_SHA1). For instance, if your Web server only has ciphers involving DES, RC4, or MD5, it’s likely that it isn’t FIPS compliant.

SSLDigger, a free tool by Foundstone, is great at interrogating Web servers and revealing which ciphers the Web server does or doesn’t support. This is the tool to run if you’re in charge of making sure your Web site(s) are FIPS compliant or if you're troubleshooting an FIPS-compliant browser that's throwing a cipher error against a particular site. Unfortunately, it’s got a few bugs and doesn’t work through proxies.

Once SSLDigger has given you a list of the ciphers a Web server supports, you can compare it against the list of FIPS-accepted ciphers or against Microsoft’s FIPS-implemented ciphers.

If both the Web site and the client are FIPS compliant and you’re still having issues, a proxy device or firewall could be causing the problems. Often, intervening devices prematurely (on purpose) terminate the HTTPS connection and substitute their own noncompliant ciphers in place of the otherwise compliant end points. It will drive you crazy if you’re not expecting it as a troubleshooting point.

If Web sites fall under your control, make sure they are FIPS compliant, or soon tens of millions of customers will not be able to access them.

Whew, there you have it. FIPS servants, go forth and multiply!