tor/changes/ticket40006

  o Major bugfix (TLS, buffer):
    - When attempting to read N bytes on a TLS connection, really try to read
      those N bytes. Before that, Tor would stop reading after the first TLS
      record which can be smaller than N bytes even though more data was waiting
      on the TLS connection socket. The remaining data would have been read at
      the next mainloop event. Fixes bug 40006; bugfix on 0.1.0.5-rc.
tls: Make buf_read_from_tls() read at most bytes The buf_read_from_tls() function was designed to read up to a certain number of bytes a TLS socket using read_to_chunk_tls() which boils down to SSL_read() (with OpenSSL, common case). However, at the end of the loop, the returned number of bytes from read_to_chunk_tls() was treated like the syscall read() for which if less bytes than the total asked are returned, it signals EOF. But, with SSL_read(), it returns up to a TLS record which can be less than what was asked. The assumption that it was EOF was wrong which made the while loop exiting before it was able to consume all requested bytes (at_most parameter). The general use case that Tor sees is that it will ask the network layer to give it at most 16KB (that is roughly 32 cells) but because of KIST scheduler, the highest possible TLS record we currently observe is 4096 bytes (4KB or 8 cells). Thus the loop would at best always return 8 cells even though much more could be on the TLS socket. See ticket #40006 for more details. Fixes #40006 Signed-off-by: David Goulet <dgoulet@torproject.org> 2020-06-19 16:35:50 +02:00			`o Major bugfix (TLS, buffer):`
			`- When attempting to read N bytes on a TLS connection, really try to read`
			`those N bytes. Before that, Tor would stop reading after the first TLS`
			`record which can be smaller than N bytes even though more data was waiting`
			`on the TLS connection socket. The remaining data would have been read at`
			`the next mainloop event. Fixes bug 40006; bugfix on 0.1.0.5-rc.`