Hi Martin,
Would you mind add some comments about the purpose of it? BTW, the file
name, TestTLS12, is not as straightforward as to catch the purpose of
the test. What do you think if using FipsModeTLS12?
Xuelei
On 4/24/2019 7:38 AM, Martin Balao wrote:
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
