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

[Hubert Kario via RT]

On Wednesday 30 September 2015 09:37:37 Albe Laurenz wrote:
> 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.

I'd interpret it as not talking about the client's ability to send data 
but rather about latency observed by application layer. In other words 
about such situation:

<snip>
      ClientKeyExchange
      [ChangeCipherSpec]
      Finished
      Application Data[1]          -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data[2]          <------->     Application Data

and how the data [1] will be received by other side's application later 
than if it wasn't sent during a handshake
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150930/ba179ec5/attachment-0001.sig>