Re: [Burp-users] Large file problems?

[Brendon H. <br...@qu...>]

Hi all,

I spent a few hours today digging into the communication problem that's 
preventing my local backup resuming properly (and possibly related issues). I 
added a bunch of debug logging (see attached), ran backups, and made some 
observations of the logs produced. Here are the ones that seem most 
significant:

* At some point while transmitting the next file, the server just stops 
reading. Its final call to SSL_read() returns -1, with error 2 
(SSL_ERROR_WANT_READ), and after that the server does not try SSL_read() again 
until after the client disconnects.

* The client sends considerably more packets of data which the server doesn't 
read. The client does eventually stop sending, however.

* During this sending process, the client never calls SSL_read(), even though 
the server is sending it small packets (responses?). I wonder if this might be 
an important point.

* Reading is handled by the async_io(), which seems to check for the presence 
of data using FD_ISSET(). For the server, a loop in backup_phase2_server_all() 
causes execution to enter async_io() via some other functions. For all loop 
iterations after the server's SSL_read() failure, the FD_ISSET() condition is 
not met, preventing further SSL_read() calls.

* I added a call to SSL_want() after FS_ISSET() condition failures. For only 
the first iteration after the SSL_read() failure, SSL_want() returns 3 
(SSL_READING). This seems inconsistent with the FD_ISSET() response.

* For all following iterations, SSL_want() returns 1 (SSL_NOTHING). This seems 
inconsistent with the fact that the server still hasn't called SSL_read() 
(data should be still present in the buffer, no?) and the fact that the client 
does send more data.

Now, I've never encountered this kind of construction for a read loop before - 
I'm more familiar with loops that just call SSL_read() (or read()) and let the 
return value indicate whether data was or wasn't available. That makes me 
wonder if some behaviour of OpenSSL (or something further upstream) has 
changed in such a way that this construction no longer works reliably. The 
fact that FS_ISSET() seems to be contradicting SSL_want(), at least initially, 
feels consistent with that.

No idea what could be done about it though. And I'm also not sure what to 
examine further.

Best,
Brendon