George,
On 12/4/20 14:22, George Stanchev wrote:
-----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".
Yes, thanks for pointing that out.
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.
Sadly, yes.
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.
Is BC actually certified? It seems unlikely to me that a group of
volunteers from Australia are going to bother to go through that
module-certification process.
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.
Oh. You're on Windows. You're right, that will suck. The binaries
packaged by ASF are definitely not going to be FIPS-certified. You'll
have to build your own and then dynamically-link it to tcnative during
the build.
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.
Yes, the build process for OpenSSL is horrible. I have no idea why they
decided to use Perl as their build system. On Windows? I have only tried
to build the OpenSSL binary, not the FIPS-compliant module. Having done
it on Linux (where it's "easy") I can say I'm glad I'm not responsible
for doing it on Windows.
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.
:(
This is why we can't have nice things.
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
See... this is why I say that FIPS is sometimes bad: they specifically
disallow large keys. And that's ... more secure? *Sigh*
(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....
Oh... so it's YOUR fault! :)
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...
Of course. I work in healthcare in the US and sometimes people ask us
about FIPS. I give them my opinion and then tell them "we always try to
do better than FIPS" referencing the industry-wide deprecation of
certain cryptographic algorithms, etc. which FIPS says you *must*
support (and no high-bit RSA keys ffs!). There are no regulations which
require us to operate in FIPS mode, so I always tell them that we can
provide FIPS compliance if they are willing to pay a huge sum for us to
guarantee it. I haven't ever had client take me up on that offer.
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.
Of course not. Do they know that credit card numbers still have a
check-digit which uses the Luhn algorithm? I'll bet *that's* not
approved for use in FIPS and yet, here we are processing credit card
transactions billions of times per day.
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.
And something which is ironically FIPS-compliant is to use a PEM file
with no protection whatsoever.
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...
It's too bad this stuff can't get updated more frequently. :/
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
