FIPS Compliant Mode

We recently (version 6.1.2) introduced 3 new connection properties for FIPS mode: fips, trustStoreType, fipsProvider. The implementation assumes fipsProvider contains trustStoreType when calling Keystore.getInstance(trustStoreType,fipsProvider). However, not all providers that contain FIPS-complaint algorithms also provide keystores, such as IBMJCEFIPS. See this page. In this case, users have to use non-FIPS IBMJCE provider (IBMJCE) to store the keys, which means they also have to set fipsProvider=IBMJCE. This can be confusing, because IBMJCE is not the actual FIPS provider, but it is the provider that contains keystore.

Below are a few possible solutions to solve the issue and we would really appreciate any feedback from the community.

1. Keep the current implementation and update the documentation describing the differences. This way we would not be introducing breaking changes, but the connection property fipsProvider could still be confusing to users because of the naming.
2. Rename the connection property fipsProvider to trustStoreProvider. This would break the existing FIPS applications, but the name of the property would be less confusing.
3. Remove the connection property fipsProvider. If provider is not specified, Keystore.getInstance(trustStoreType) traverses the list of registered providers and creates a new instance of matching Keystore. So, instead of creating a new Keystore from the specified provider, the driver would create it from the most preferred (the one that comes first in security providers list) provider. This would obviously be a breaking change too, but also would let us avoid any possible confusions.

I am also posting links to the related PRs below.

https://github.com/Microsoft/mssql-jdbc/pull/97 https://github.com/Microsoft/mssql-jdbc/pull/135 https://github.com/Microsoft/mssql-jdbc/pull/325 https://github.com/Microsoft/mssql-jdbc/pull/433

We would appreciate opinions on the proposed solutions. Please feel free to let us know if you have other suggestions 👍

[nsidhaye]

Thanks @ulvii for discussion.

FIPSProvider attribute introduced especially for keystore usage. For getting keystore instance we can pass appropriate FIPSprovider thinking of useful in custom runtime configurations for FIPS.

ks = KeyStore.getInstance(trustStoreType, fipsProvider);

@ulvii showed me that even with runtime FIPS configuration one will get appropraite keystore instance without passing fipsprovider. Keystore will pick up appropriate provider.

I am comfortable with option 3.

[sehrope]

+1 to either option 2 or 3 though leaning more toward 2 as the extensibility would be useful to other users wishing to avoid editing java.security.

I’m usually on the side of maintaining backwards compatibility but think cleaning up the confusing property names now is good idea. I don’t see any external comments on the original PR that added that feature so hard to gauge who external to Microsoft would be impacted by the change. I can’t imagine it would be particularly widespread. Presumably anybody using features as recent as that would be tracking breaking changes to the driver and know it’s coming. Plus they’re app would break at connect time…

Somewhat related, it’d be nice if the choice of keystore itself could be externalized as a connection property. Part of the purpose of PR #74 for adding a custom TrustManager is to supply a custom keystore on a per-connection basis without mucking with JVM-wide settings. That allows for per-connection certificate pinning without maintaining a static shared keystore. Plus the keystore doesn’t have to be persisted which is a big +1 in a container/stateless deployment environment.