FIPS Compliant Mode

[ulvii]

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.

#97
#135
#325
#433

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

[nsidhaye]

@ulvi : In case of non fips provider why somebody need to pass fipsprovider attribute?

As a database driver we should not focus only on one FIPS provider. Now in case of IBM it is special case. One should not pass FIPS Provider in case of IBM FIPS implementation as IBM FIPS implementation strictly took values from JRE.

While other FIPS provider can give liberty to choose runtime FIPS configuration before opening SSL connection.

[ulvii]

Hi @nsidhaye ,

Please see my comment on #433. Thank you.

[ajlam]

@sehrope and @ErikBergfurInfor - Do either of you have any additional thoughts/suggestions to share?

[ErikBergfurInfor]

I would go with option 2, since it cleans stuff up and we are not currently using the property.
We are using java.security to set up our FIPS environment but I believe it's still good to have options to tell the driver specifically what provider to use and not rely solely on the java.security being set up correctly.

[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.

[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.

[ajlam]

@ErikBergfurInfor, @sehrope, @nsidhaye thanks for your input.

@sehrope, re: #74, apologies for the delay in this. We're investigating and will circle back. If possible, I may need to ask you to rebase the PR against the dev branch.

[ulvii]

Hi @ErikBergfurInfor, @sehrope , @nsidhaye ,

Thank you so much for the input. We decided to remove the connection property fipsProvider. I have attached the jar file that contains the changes to this issue. It would be great if you could test it as well and let us know if your applications work as expected.

mssql-jdbc-fips-removed.zip

[ErikBergfurInfor]

We don't use the fipsProvider property, so we should be fine. We currently don't have the bandwidth to do a full scale test with a snapshot release

[ulvii]

#460 has been merged. Thanks to everyone for the feedback :)