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
