Custom User Control and FIPS Encryption Issues

Question

I have created several custom user controls that I added to the Redering templates of some forms in a custom solution for WSS 3. Most of these templates have codebehind and they all are correctly deployed to the CONTROLTEMPLATES folder on the 12 hive. The forms worked fine until the security folks said we had to enable FIPS. Once this was done, Sharepoint went nuts until I changed the machineKey setting in the web.config file to use the 3des algorithm as I had found on many sites. This fixed most of the issues except for my custom forms .ascx pages as everyone of them still give a FIPS error and they do not work. I have found the code that I can place in the machine.config file that turns off the check, but I would like to figure out what is going on with this. I have ensured that debug is set to false in the web.config file as well. It is only my user controls that are causing the issue, but I do not know why. So it would be nice if there was a list of known .Net assembles that were not FIPS compliant or some way for me to determine what library is calling the offending code. Any ideas, thoughts, insights are welcome!

Update: I wanted to point out that my controls are not used to do any encryption and I am not trying to call anything like that. Just drawing some webcontrols.

Answer 1

Microsoft does not support FIPS with SharePoint 2010.

"SharePoint Server 2010 uses several Windows encryption algorithms for computing hash values that do not comply with Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules. These algorithms are not used for security purposes; they are used for internal processing. For example, SharePoint Server 2010 uses MD5 to create hash values that are used as unique identifiers.

Because SharePoint Server 2010 uses these algorithms, it does not support the Windows security policy setting that requires FIPS compliant algorithms for encryption and hashing."

2010 link for above quote http://technet.microsoft.com/en-us/library/cc263215.aspx

2007 article stating the same thing http://support.microsoft.com/kb/2000371

I've used it on 2007 farms for public facing web sites (static content), but not internally. For sure it will break workflows (even after making the web and machine config changes) as you cant change the encryption module that WWF uses, which is why it is a no go for intranet/extranets.

I've always documented this in my security assessments as non-compatible, and mitigated thru defense in depth. SSL 2.0 secure client connections, authenticate off box via ISA/TMG/UAG or other, HTTPS termination and inspection, etc. I've never had an issue as long as I could show the IA folks we understand the threat and have taken steps to protect against it. Of course if you can do HTTPS termination, you may be able to get away with enabling FIPS on the reverse proxy and serve the content that way, although I must admit i have not tried that.

Answer 2

Basically we did use the information provided by Microsoft as linked by Mr Shelby above to mitigate removing the requirement to enforce FIPS. I presented the information to our Computer Security department manager and we were able to get approval to remove this as a requirement. I am not sure if this would be considered a work around or not, but this was what we had to do. I was never able to get my code to work as long as FIPS was enabled.