On 11/11/2019 23:40, George Stanchev wrote:
> Currently, (in most cases) Tomcat creates an in-memory keystore and
> initializes kmf as follows:
> KeyManagementFactory.getInstance(algo).init(keystore, kspass). The in-memory
> keystore has the key, the certificate and the chain and nothing else. This
> works fine in most cases but we've ran into a situation where this is not
> sufficient. I am running TC with BC as JSSE provider in FIPS-approved only
> mode and in certain use cases we're running into issues with RSA key reuse.
> FIPS states that an RSA key should be used for encryption/decryption or for
> signature/verification but not for both. So when one browser (in our case it
> was FF) selects TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, BC's key manager marks
> and remembers the key usage, then another browser (Chrome) settles for
> TLS_RSA_WITH_AES_128_GCM_SHA256 BC throws an key-reuse exception since the
> latter suite uses RSA for key exchange and the former for authentication. The
> BC key manager has the ability to select a different key based on KeyUsage
> extension, so it is possible to have multiple RSA keys in memory that would
> be used according to their certificates KeyUsage policy. However TC feeds
> only one certificate to the KM.
>
> Here is a thread [1] that I ran into that shows someone else running into the
> issue and response from BC developer.
>
> To be fair, BCFIPS does have a -D override for the key usage override for RSA
> keys in approved-only mode but according to this thread [2], the property is
> there for completely different purpose and running it to get around the TC
> issue is not FIPS compliant.
>
> So having looked at the code in SSLUtilBase#getKeyManagers(), is it worth
> opening a BZ request to have some solution to this issue - perhaps if alias
> is omitted in configuration and the keystore is of transferrable type (not
> ms, hardware, etc) then transfer all entries to the KM and let it do the
> selection?
Absolutely.
If you can provide everything we'll need to reproduce this on a clean
9.0.x build (server.xml changes, sample keystores, links to libs we need
to download etc.) it should be possible to address this.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
