-----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Friday, December 04, 2020 10:58 AM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
George, On 12/3/20 21:59, George Stanchev wrote: > Java's FIPS mode is "expirmental" feature that was removed in later > Java versions. It was never certified (AFAIK). I've always found conflicting information about whether or not Java's crypto module was FIPS-certified or not. Sun/Oracle have documentation which suggests that, at least under some configurations, it IS certified, but there is precious little information about it. I suspect you can pay Oracle to give you the magic that makes it certified. I've never cared enough about it to actually try to find it out. I find FIPS to be a useless requirement that doesn't add any security beyond what usual best-practices would give you. But I don't do work in intelligence or military applications, so I'm allowed to thumb my nose at such things. GS: IBM's JCE is FIPS-certified but not Oracle's. Also, we should make a distinction between "certified" and "compliant". Certification is obtained by a long and laborious process by NIST. Compliancy is mainly self reporting. Look here https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8217911 for Oracle removing the "compliant" mode in Java 13. If you read through the task, you will see it states "Legacy applications might have used the experimental mode...". Me and you can have our opinions about FIPS, but the reality is that if you want to sell to government entities (and even some commercial entities) you really need FIPS support in your product. With the pluggability of Java's crypto interface, I seriously doubt Oracle is going to certify a JCE module in the future, esp. with free 3rd party solutions such as BCFIPS. > To me the only two viable options are via APR+OpenSSL 1.0.1/FIPS and BCFIPS. NIO+JSSE/OpenSSL ought to be okay, theoretically. The "AprLifecycleListener" is a misnomer; it really should be the "TcnativeLivecycleListener". You can use it to configure OpenSSL into FIPS mode and still use NIO+OpenSSL as your connector. GS: You are right, I might have misspoken by saying "APR". What I really meant is you need to have OpenSSL as in tcnative. The problem I faced back in the days was that the prebuilt binaries come with regular, non-FIPS OpenSSL and despite my long efforts I was never able to build it successfully and fully on Windows x64. I found it non-trivial and the toolsets to be very specific, and even after following all instructions from several wikis and web pages I kept running into issues resulting in overall failure. Also, keep in mind that OpenSSL 1.0.1 is EOLed and the FIPS module is only available for that version line. OpenSSL still produces security fixes to paid support subscribers (we are) but they are not available for the general public. OpenSSL 3.0 will have a refreshed re-certified FIPS module but it is not due until later next year, so for now general public is left hanging with the last public version of 1.0.1+FIPS. > We have implemented the later and have ran into issues with RSA keys. > First the C# BCPROV doesn't support 4096 bit RSA keys What? It's like the most popular configuration in the world right now. I know you can read more about it here: https://github.com/bcgit/bc-java/issues/616 > (I know weird, but our config app is C# and we use BCFIPS/C# there) > but that's OK, you can use Windows CNG or CAPI but of course you have > to put the whole Windows in FIPS which is not prarctical all the time. > > > > But second, and most important BCFIPS implements stricter FIPS > requirement that an RSA key cannot be used for both encipherment and > signature and BCFIPS really tracks the usage. That's appropriate, actually. What's the problem, there? GS: See my next comment with a link to technical explanation > This, combined with the fact that Tomcat (8.5.someting about an year > ago) doesn't really support multiple keys for SSL that can be > dynamically selected really leaves you with only DSA key. I'm curious what version that is, because Tomcat will definitely select the appropriate certificate from a set of RSA/DSA/ECDSA-based certs. GS: http://mail-archives.apache.org/mod_mbox/tomcat-users/201911.mbox/%3caa01aac6-fa82-a100-3d37-26b3521cb...@apache.org%3E GS: I never had a time to formalize the patch, to submit a BZ and attach it, which is a shame. I should perhaps do this.... > Now, BC does support a system property to disable this FIPS > requirement but now you are not FIPS compliant, strictly speaking. Well... FIPS is all about strictness. You can certainly use the OpenSSL FIPS module without entering FIPS mode, but, well, then you aren't actually using the FIPS module, then, are you. " Man: We have the most sophisticated door-locks money can buy! Woman: Who has access to the keys? Man: It's super secure! Nobody has access to the the keys because we never engage the locks! " GS: As I said, "compliancy" is really about self-reporting. You could do whatever you want and say you're FIPS compliant but then, once you sell to the US government, you sign bunch of forms that make you liable. Nobody is requesting you open your source but things can and will surface and then you lose business, you lose credibility and perhaps can be held liable...That's why you should proceed with caution as I described in my later email... > Which, as FIPS-compliancy goes, might or might not be a problem as it > is really a self-reporting. Also, no way to get PKCS12 keystores in > FIPS mode so you're stuck with BCKFS or PEMs. I didn't realize tat PKCS12 doesn't work in FIPS mode. Why not? GS: "Algorithms redtape hell" though there is nothing explicitly prohibiting pkcs12. The main issue is in generation of MAC - the hash that is used to check the password integrity of the file. The hash is computed using a hash algorithm from the list of allowed hash algorithms, and the key that is used to encrypt the hash is derived from the password. The function to derive the key is unique to the standard and described in Appendix B of the PKCS12 spec . This function is not FIPS compliant and cannot be in approved mode. The workaround could be to use a different password based key derivation function - PBKDF2. However, there is nothing in the PKCS12 spec that allows to encode another algorithm OID in MacData. In essence, you cannot use any other algorithm other than the one defined in spec which is not FIPS compliant. Another workaround could be to omit the MAC altogether when generating a file, however this results in libraries that try to parse such files (Windows, BC). Supported only for OpenSS (to my knowledge) but...you get the idea... George
