I've heard it mentioned many times by colleagues and other information security professionals that it is a violation of Federal Information Processing Standards (FIPS) regulations for an internet-facing web server to accept cipher suites containing the MD5 or RC4 algorithms, during the server's SSL or TLS negotiation process.

I know that there are others which are also disallowed, but I haven't been able to find a citation anywhere in the authoritative literature that flat-out says "MD5, RC4, ... are not allowed". Note that the context of use is within a federal information system; hence, compliance with FIPS regulations is rather mandatory, and not simply advisory as it would be for a commercial organization.

In order to help my organization understand that there may be a regulatory compliance issue, I would like someone to point me to literature from NIST (or whichever other organization created/enforces FIPS) specifically blacklisting the use of MD5 and RC4 in the context of SSL connections to Federal information systems.

If it makes a difference, yes, the system may potentially need to handle personally identifiable information (PII), so any regulations contingent on that should be pointed out as well.

As some more info: I have been able to design a custom security tool that actually limits the advertised SSL cipher suites when it negotiates with the server. This allows me to test the server against a hypothetical client that does not accept more secure algorithms such as SHA1 for the message digest and RSA for the encryption. It goes without saying that, if there is a regulatory compliance issue, then it would easily override any concerns about compatibility with clients that don't support FIPS-compliant algorithms.


TLS is actually one of the rare instances where MD5 is, in fact, specifically stated as being allowed to be used for key agreement. Citation is in the FIPS 140-2 IG, D.8 (pg. 157, point (e)(1).

SSLv3 use of MD5 is disallowed due to a difference in how MD5 is used. See footnote 2 at the bottom of page 160 of the same IG:

The problem with SSL 3.0 is the key derivation process that applies to all SSL 3.0 cipher suites: half of the master key that is set up during the SSL key exchange depends entirely on the MD5 hash function. MD5 is not an approved algorithm, and its collision resistance property has been broken by Antoine Joux.

TLS also uses MD5 in the key derivation process, but in a different manner, so that all of the master key depends on both MD5 and SHA-1; nothing in TLS actually depends on MD5 for its security.

Therefore, TLS implementations can be validated under FIPS 140-2, while SSL 3.0 implementations cannot. TLS is version 3.1 of SSL, and most current servers and clients are capable of doing both SSL 3.0 and TLS.

Finally, I am fairly certain that RC4 is completely disallowed. On page 33 of the IG, RC4 is explicitly listed as a non-approved algorithm. No other caveats are made in the IG with respects to RC4 and I've not experienced any claims in my line of work that would indicate that it could be acceptable in any other circumstances.

  • What about RC4 as the stream cipher? And what about SSLv3? Sorry for the questions; your answer is already helpful as-is, but you seem to be on top of the issue... – allquixotic Jul 18 '12 at 20:15
  • The document you linked is very informative. I will be able to extract the info I need from it, thanks to your help, to make an educated argument to my superiors that we have a problem. Thank you!! – allquixotic Jul 18 '12 at 20:24
  • 1
    Though, it wasn't really Antoine Joux: that's a misattribution in itself. It was Wang Xiaoyun. Papers 1 2 – Evan Carroll Jul 20 '12 at 15:16
  • The IG has undergone substantial revision since this answer was written, the current IG (2014-01-17, page 32) says of MD5: May be allowed in an Approved mode of operation when used as part of an approved key transport scheme e.g. SSL v3.1) where no security is provided by the algorithm. So it's still hanging in there. – mr.spuratic Feb 5 '14 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.