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