On 4/24/19 10: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.
Ok, thanks for that link. We need to file another bug to track the
underlying issue then as I don't see anything filed. It seems quite
likely that this could come up in a real scenario and telling a customer
to disable RSA-PSS is just not right in my opinion.
Can you please file a bug for that and link it to this test bug? I'm ok
with you pushing this test workaround fix for now since we need to get
this resolved soon. I also agree with Xuelei that it would be helpful to
add more comments in the test as to why the security property workaround
is needed.
Thanks,
Sean
Kind regards,
Martin.-
--
[1] -
https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html
