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

[Kurt Roeckx via RT]

On Mon, Oct 12, 2015 at 06:54:46PM +0000, Matt Caswell via RT wrote:
> 
> 
> On 12/10/15 19:11, Kurt Roeckx via RT wrote:
> > On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote:
> >>
> >> Having done some more digging it seems the problem only occurs if you
> >> get the initial handshake, following by a second reneg handshake *and*
> >> interleaved app data all within the scope of a *single* SSL_read call.
> >> AFAICT if SSL_read returns between the first handshake and the second,
> >> you don't get the problem.
> >>
> >> That's starting to sound like quite an unlikely scenario and we're only
> >> hitting it now because of the slightly artificial nature of Hubert's
> >> test. I'm wondering whether "will not fix" is the right response to this
> >> second bug? Thoughts? Having said that it would be nice to have a
> >> reliable test for the interleaved-app data issue.
> > 
> > Are you saying this is 1 TLS record with 2 handshakes in it?
> > 
> > From what I understand, the authentication could change.  Doesn't
> > that mean we should make sure the client reads all data with
> > SSL_read() before we tell it authentication changes and that we
> > might have to delay processing some messages until that is done?
> >
> 
> No. I'm saying it is within the scope of one SSL_read. libssl will read
> 1 record at a time from the network, process it, then read the next one,
> and so on. It will continue until it returns back to the user code
> because it ran out of data to read (NBIO), or it has filled the buffer
> supplied by the user code. So there is not reason why it couldn't do
> multiple handshakes within a single SSL_read if the buffer is big enough
> (or not much app data is read between handshakes) and the data is coming
> in from the network fast enough to prevent an IO block (e.g. such as
> when we are running Hubert's test code on a single machine).

Maybe I should go and re-reads the RFCs again, or I'm missing
something, but I don't see how we could have 2 unprocessed
handshakes in the buffers.  I expect that we need to write
something before the 2nd can arrive.  But maybe it's something
related to NPN or something like that?


Kurt