[openssl-users] Strange SSL_read behavior: 1/N-1

[Dave Thompson]

> From: openssl-users On Behalf Of Hooman Fazaeli
> Sent: Monday, December 08, 2014 09:36

> 1. The SSL_read in my http server app always reads the first byte of 
>   http request, instead of the whole. To read the rest, I should do 
>   further SSL_reads: <snip>
>   I have seen this pattern with firefox, IE and opera as client. 

This is/was the consensus mitigation for BEAST in 2011. 
Senders (browsers etc) break a record of N bytes into 
two SSL records, 1 byte then N-1; this makes the IV for 
the second record (e.g. session cookies) unpredictable.
Although SSL/TLS is defined as a stream service and an 
implementation could recombine these, OpenSSL doesn’t.

This mitigation is only needed for CBC ciphers in protocols 
below TLS1.1. I don't know if (all? some?) browsers only 
implement when needed, but you could try to make sure 
your server supports at least 1.1 (and OpenSSL 1.0.1* 
can support 1.2 as well), and supports and possibly prefers
RC4 (which is the other mitigation for IV, but now itself 
vulnerable to other attacks e.g. Paterson et al at RHUL).

But given that SSL/TLS is a stream service and any implementation 
*must* fragment a record over 16K and *may* choose to fragment 
a smaller record for any reason it likes, your receiver should be 
doing the read-until-complete or in some cases read-until-timeout 
loop anyway. Note TCP (and plaintext HTTP) has this same feature 
and HTTP/TCP does actually fragment in numerous real cases 
including at sizes of realistic HTTP requests. HTTP is carefully 
designed so that both requests and responses are delimited 
either by a distinct close or length header(s) precisely so that 
it works robustly and reliably over such stream channels.