> 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 doesnt.
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.
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Dave Thompson
> Sent: Monday, December 08, 2014 20:02
> To: [hidden email] > Subject: Re: [openssl-users] Strange SSL_read behavior: 1/N-1
> 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.
Absolutely. This is one of the basic requirements of TCP. OpenSSL exposes it to callers because hiding it can leave an application blocked forever (if an incomplete record is never completed), and the application has to decide how to deal with that case.
There are variations on this pattern, such as the non-blocking-check-for-readability approach (often combined with multiplexing), but they all boil down to receiving until the record is complete or some other condition occurs (error or timeout or application decides to give up or whatever).
> 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.
Actually HTTP/1.1 has *five* mechanisms for delimiting messages:
- If the message cannot have a body, then it ends at the body delimiter (CRLF CRLF).
- The Content-length header.
- The Chunked transfer encoding, in which the end of the message is indicated by a zero-length chunk, possibly followed by trailers. This may now be the most common way HTTP messages with bodies are delimited, since it has useful advantages over Content-length.
- Closing the conversation. This is only allowed on the server side, because RFC 2616 incorrectly asserts that use by the client would prevent receiving a response. (In fact the client could perform a half-close, when the transport is TCP; RFC 2616 ignores this possibility.)
- Using a self-delimiting message encoding such as mime-multipart. I've never seen this used in the real world.
I mention only to emphasize Dave's point, which is that TCP, and other stream services, delegate determining record boundaries to the application protocol, and that is often quite a complicated process.
Technology Specialist, Micro Focus