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

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Dave Thompson
> Sent: Monday, December 08, 2014 20:02
> To: openssl-users at openssl.org
> 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.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com