FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as record version in ClientHello

[Christian Schaefer]

* Sean Mullan
> Are you referring to the "FIPS 140 Compliant Mode for SunJSSE"? Note that this was documented as an "experimental" feature and has since been removed from the JDK [1]
Yes, I was referring to the "FIPS 140 Compliant Mode for SunJSSE". Sorry, for not being precise enough. Thanks for pointing out that this mode of SunJSSE was experimental - I didn't know.

> Can you give more info as to why SSLv3.0 is being used since it has well documented security weaknesses and should really no longer be used anymore?
We're not using SSLv3.0. The only place where this version appears is in the record version of one single client.

> "Only TLS 1.0 and later can be used. SSL 2.0 and SSL 3.0 are not available. Any attempt to enable SSL 2.0 or 3.0 will fail with an exception."
Yes. But TLS 1.2 seems to allow the client to specify SSLv3.0 as record version (not protocol version). I did not fully understand the reason behind this but it is how I understood the paragraph from rfc5246 that I referenced in my first email.

* Florian Weimer
> I think the SSLv3.0-compatible client hello is not in itself inherently unsafe, at
> least as long as the client is not willing to actually negotiate SSLv3.0. 
Right, this is exactly how I understand it. In our scenario both, client and server are negotiating TLS 1.2 as the *only* protocol. Both, client and server don't support SSLv3.
We only noticed that there was one client which stopped working after we switched the server into "FIPS mode".

I first thought the client behavior is wrong, however, according to Appendix E.  Backward Compatibility - E.1.  Compatibility with TLS 1.0/1.1 and SSL 3.0 (which I referenced in my previous email) this seems to be not true. It is the server that rejects the client although it should not.

* Xuelei Fan
> Personally, I don't think it is a priority to fix in JDK unless there is a requirement in practice.
Yes. We only had this issue with one client and it seems like we can change the client. So practically this is solved for us even w/o a fix. I hope there are not more clients which negotiate TLS 1.2 but set the record version to SSLv3.0. Personally, if you haven't heard this problem before I don't think it is a bigger issue.

Thanks for your help.

Christian


> -----Original Message-----
> From: Florian Weimer <fw at deneb.enyo.de>
> Sent: Monday, October 14, 2019 7:44 PM
> To: Sean Mullan <sean.mullan at oracle.com>
> Cc: Christian Schaefer <christian.schaefer at microfocus.com>; security-
> dev at openjdk.java.net
> Subject: Re: FIPS 140.2 enabled TLS server rejects clients sending SSLv3 as
> record version in ClientHello
> 
> * Sean Mullan:
> 
> > Can you give more info as to why SSLv3.0 is being used since it has
> > well documented security weaknesses and should really no longer be used
> anymore?
> 
> I think the SSLv3.0-compatible client hello is not in itself inherently unsafe, at
> least as long as the client is not willing to actually negotiate SSLv3.0.  In the
> past, there were load balancers which could handle SSLv3.0-compatible
> hellos, but not much else.  The actual backend server would negotiate
> something more recent off the legacy hello.  I have no idea whether these
> workarounds are still needed in practice.
> 
> However, I remember that past OpenJDK versions more or less defaulted to
> sending such client hellos.  If these clients are in principle able to negotiate
> TLS 1.0 (or maybe even something newer), accepting that in FIPS mode as
> well would be nice.