> 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.
