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

[Matt Caswell via RT]

On 12/10/15 20:40, Kurt Roeckx via RT wrote:
> 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?

You can't. That's not what I'm saying. They only need to be in the
buffer by the time you try to read the data. Or if you're using blocking
IO, it will just keep trying to read app data until its got some to
return, processing any handshake messages it encounters as it goes (and
processing means it may swap to writing handshake messages out).

Matt