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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev