RFR: 8061798: Add support for TLS_FALLBACK_SCSV

[Xuelei Fan]

Hi Florian,

Thanks for contribute this patch to OpenJDK.

The draft of TLS_FALLBACK_SCSV is moving pretty fast.  Would you mind
wait for the integration until it becomes an official RFC in order to
mitigate the potential compatibility impact?

I looked back the approach we used to support
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (RFC 5746).
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is treated as a cipher suite.
Application can configure to enabled or disable this special cipher
suite as normal:
    SSLSocket.setEnabledCipherSuites(String[] suites)
    SSSEngine.setEnabledCipherSuites(String[] suites)

What do you think if we use TLS_FALLBACK_SCSV as a cipher suite? If the
enabled cipher suite list contains this cipher suites, client would send
this cipher suite in ClientHello request.

If it is OK, may not need to define new public APIs any more.  As make
it possible if this implementation is needed to backport to previous
releases (In general, no APIs changes are allowed in JDK update releases).

Thanks,
Xuelei

On 1/26/2015 6:04 PM, Florian Weimer wrote:
> I have rebased the TLS_FALLBACK_SCSV implementation I submitted in
> October 2014 to the current jdk9-dev tree:
> 
>   <http://cr.openjdk.java.net/~fweimer/8061798/webrev.00/>
> 
> The test uses an expired X.509 certificate (which was already part of
> the test suite), but this is harmless.
> 
> TLS_FALLBACK_SCSV is a bit of a wart, but it seems necessary for feature
> parity with other TLS server implementations.
>