The actual maximum buffer size in SSL is actually closer to 18K; 16K is the maximum plaintext record length, headers and (universally unimplemented) compression allows the record size to grow a bit more.
The sockets layer in MatrixSSL is designed for a small memory footprint. The default buffer size begins at 1K and grows automatically to handle larger record sizes. You could reduce the record size at any time, as long as you aren't currently parsing a record. Also, the incoming and outgoing buffers are independent, so it's entirely possible that only one would grow. Typically the peer of the connection will attempt to send data at the maximum buffer size to reduce the number of application network writes being done (assuming you are not in control of the peer). In addition, there's about 25 bytes of overhead per record that is minimized by using full 16KB SSL records. Other than that, there's no real drawback to sending data in smaller chunks (especially with Nagle enabled). For example in an RPC type connection with a lot of little packets, the largest record is usually the handshake message containing the certificate, which could be 4-16KB, depending on the cert size or the number of certs in the chain. After the handshake is complete, it's entirely possible that no record will be larger than a few KB. Since an SSL connection is in handshake state for a very small percentage of its lifetime, the steady state memory usage can actually be quite low. MatrixSSL source code is downloadable from http://www.matrixssl.org under the GPL and also a commercial license for proprietary applications. - Steve PeerSec Networks MatrixSSL Team http://www.peersec.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Del Vecchio Sent: Thursday, September 22, 2005 12:22 PM To: openssl-users@openssl.org Subject: RE: Reducing SSL3 Buffer Requirements -----Original Message----- The cause is the maximum record size in the specifications, any compliant client or server might send a record of maximum size which would then reach the requirements stated. If the maximum record length is used an implementation can't do much about that because it has to check the entire record integrity before returning any data to the application. Doing anything else would be a security hole. There are some TLS extensions which allow the max record size to be specified at handshake time *but* these aren't widely supported. OpenSSL doesn't currently support TLS extensions though. Steve. -- I understand that when an implementation sends a maximum-length record, my implementation must have a contiguous buffer large enough to hold it. But since my application will rarely receive records of the maximum length, I am looking into doing some dynamic growth of the Rx buffer. I would like to start it small (2K or 4K), then grow it only if the other end sends me a larger record. On the transmit side, OpenSSL currently has the ability to send arbitrarily large messages, one 16K record at a time. Is there any harm in me deciding to send large messages one 4K record at a time? Thanks. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
