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

[Matt Caswell via RT]

On 13/10/15 11:55, Hubert Kario via RT wrote:
>>> The value of "in_read_app_data" not being true when it is supposed
>>> to
>>> appears to be running into a slightly different bug. It's also
>>> present in 1.0.2 but you have to switch off version negotiation. So
>>> running s_server like this in 1.0.2 and rerunning Hubert's test
>>> will hit it:
>>>
>>> openssl s_server -www -tls1_2
>>>
>>> The 1.0.2 version negotiation is hiding the issue. In master version
>>> neg has been completely rewritten and simplified - but in doing so
>>> no longer hides the problem. :-(
>>
>> 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.
> 
> It's completely valid and not at all unlikely to have two record layer 
> records inside single TCP packet...

Oh, yes. That is common. I think what is less common is to have two
handshakes back-to-back with the first app data received being
interleaved in the second handshake.

In any case the new patch deals with this scenario anyway.

Matt