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?


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.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to