RFR: 8061798: Add support for TLS_FALLBACK_SCSV

[Florian Weimer]

On 02/03/2015 03:18 PM, Xuelei Fan wrote:
> On 1/29/2015 5:59 PM, Florian Weimer wrote:
>> On 01/29/2015 04:39 AM, Xuelei Fan wrote:
>>> 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?
>>
>> The RFC is basically set in stone because code implementing it has
>> already been shipped.  I don't like the specification, and I don't like
>> how it happened.  But practically speaking, it's a done deal, even if
>> the IETF end up not publishing the RFC (which is extremely unlikely
>> because an RFC is the only way to get the SCSV code point reservation).
>>
> We may still have a few months to address this feature of JDK 9. I think
> it might not be bad to wait for more progress of this RFC proposal, in
> case the spec gets updates unexpectedly.

I don't think this will happen because both NSS and OpenSSL implement
already with specific semantics, and the changes have been backported
all over the place.  The Internet draft might still die and never be
promoted to an RFC, though.

My worry here is that PCI DSS compliance will eventually require
TLS_FALLBACK_SCSV support (in the sense that you have to write up an
excuse for an exception) once Microsoft ISS implements it.  If that
happens, we are in a bit of pain, considering the release schedules we
have with OpenJDK.

>>> 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.
>>
>> We absolutely have to prevent that application developers set this SCSV
>> by accident.  Developers feel tempted to set TLS_FALLBACK_SCSV to
>> increase security, but this is very wrong.  Things will appear to work
>> just fine right now, but if the server side ever upgrades to TLS 1.3,
>> the handshake will fail to work (I called this a “time bomb” in the IETF
>> TLS WG discussion, because that's what it is).  Questions on the OpenSSL
>> mailing list (and misleading advice in response) show that this is a
>> real problem.
>>
>> My hope is that with a new API, the risk that developers enable this
>> accidentally is reduced.  It makes it also more transparent to code reviews.
>>
> It depends.  In other side, as would decrease the transparent for system
> administrators.

I'm sorry, the key point I'm trying to bring across here is that this is
*not* a configuration issue.  System administrators must not configure
TLS_FALLBACK_SCSV.  The *only* valid use for TLS_FALLBACK_SCSV is in
this code sequence:

  1. Code makes a TLS connection with all supported protocols,
     without sending TLS_FALLBACK_SCSV.

  2. Code catches a handshake-related exception.

  3. Code retries the handshake, this time with a subset of the
     supported protocols, and sets TLS_FALLBACK_SCSV.

If the system administrator has a way to configure TLS_FALLBACK_SCSV,
this code sequence breaks because the first step *must not* send
TLS_FALLBACK_SCSV for forward compatibility with TLS 1.3.

Or, more relevant to typical Java clients, code which doesn't do step 2
and 3 must not send TLS_FALLBACK_SCSV, ever.  This is an absolute fringe
feature, and the only use case we might ever encounter could be
self-testing of the server-side support.

Past experience with the OpenSSL implementation suggests that developers
are eternally tempted to get this wrong.  That's why I don't want to
turn it into a cipher suite, so that it's more likely that developers
read the Javadoc warning before activating this.

>>> 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).
>>
>> I plan to backport only the server part, the client part is mostly there
>> for testing purposes.
>>
> I would suggest to keep the JSSE APIs simple and small.  If an public
> API is required to turn on/off TLS_FALLBACK_SCSV, using cipher suite is
> an easy-to-use approach.

I'm worried that it's too error-prone and will result in broken Java
clients because developers pick up incorrect advice somewhere that they
have to set TLS_FALLBACK_SCSV (for example, there already posts on the
web which confuse it with TLS_EMPTY_RENEGOTIATION_INFO_SCSV).

-- 
Florian Weimer / Red Hat Product Security