Hi Sean, On 4/24/19 7:12 AM, Sean Mullan wrote: > > I am still concerned about the odd workaround for this issue. Can you > comment on my previous comment that I raised?: > > On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a > more subtle bug or configuration issue >> underlying this. It seems like this could come up in real scenarios. You >> should never disable a strong algorithm, even if it is unsupported, in >> order to establish a TLS session. It should be able to negotiate a >> session using a different algorithm. >>
The reason why we disable the algorithm in the test is related to [1]. What happens is that we need to have SunPKCS11, SUN and JSSE crypto providers enabled for a successful TLS communication in FIPS mode. The reason we need SUN -which looks as the odd one out there- are X.509 certificates. However, having SUN enabled (after JSSE experimental FIPS changes) means that we support "RSAPSS" for the TLS communication. When this algorithm is applied by SUN provider to a SunPKCS11-sensitive key (keys are sensitive in FIPS mode and cannot be converted), it fails. As I said in [1], we need a good solution beyond the workaround of disabling concrete algorithms. I'd be happy to update the test when this is fixed. Kind regards, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html
