[openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Albe Laurenz via RT]

Matt Caswell wrote:
> On 28/09/15 12:35, Albe Laurenz via RT wrote:
>> Matt Caswell wrote:
>>> However, I have some concerns with the wording of the RFC. It seems to
>>> place no limits whatsoever on when it is valid to receive app data in
>>> the handshake. By the wording in the RFC it would be valid for app data
>>> to be received *after* the ChangeCipherSpec has been received but
>>> *before* the Finished has been processed. This seems dangerous to me
>>> because it is not until the Finished is processed that we verify the
>>> handshake data MAC - and yet we could already have acted upon app data
>>> received. I assume the intent was to allow the interleaved app data only
>>> up until the point that the CCS is received. I have attached a patch for
>>> 1.0.2 that implements that logic.

>> The RFC writes:
>>
>>    Note: If a rehandshake occurs while data is flowing on a connection,
>>    the communicating parties may continue to send data using the old
>>    CipherSpec.  However, once the ChangeCipherSpec has been sent, the
>>    new CipherSpec MUST be used.  The first side to send the
>>    ChangeCipherSpec does not know that the other side has finished
>>    computing the new keying material (e.g., if it has to perform a
>>    time-consuming public key operation).  Thus, a small window of time,
>>    during which the recipient must buffer the data, MAY exist.  In
>>    practice, with modern machines this interval is likely to be fairly
>>    short.
>>
>> Could that be interpreted to mean that the recepient should buffer
>> all incoming Application Data messages that are sent between
>> ChangeCipherSpec and Finished?

> Thanks. I had missed that wording. I think this means that as soon as
> the first party sends a CCS, they must not send any app data until they
> have received a CCS back (they must buffer it until the CCS is seen). So
> the second party should never expect to see app data between CCS and
> Finished. It doesn't tell you anything about what the first party can
> expect though, i.e. is the second party allowed to send app data between
> the CCS and Finished?

Interesting how we can read this so differently.
If anything, that confirms that the wording of the RFC is suboptimal.

It is probably both convenient and sensible to follow the following
sentence of the RFC, as you have done:

      A Finished message is always sent immediately after a change
      cipher spec message to verify that the key exchange and
      authentication processes were successful.

This may well be interpreted as "no Application Data records may
be sent between CCS and Finished".

Yours,
Laurenz Albe