I hacked around with the Tx buffer size in the 0.9.8
source. I took these definitions from ssl\ssl3.h:
#define
SSL3_RT_MAX_PLAIN_LENGTH 16384#define SSL3_RT_MAX_COMPRESSED_LENGTH (1024+SSL3_RT_MAX_PLAIN_LENGTH)
#define SSL3_RT_MAX_ENCRYPTED_LENGTH (1024+SSL3_RT_MAX_COMPRESSED_LENGTH)
#define SSL3_RT_MAX_PACKET_SIZE (SSL3_RT_MAX_ENCRYPTED_LENGTH+SSL3_RT_HEADER_LENGTH)
And separated them into two sets; one for Tx and one for Rx. I
replaced all references in the code to my new Tx/Rx
versions.
Then I (conditionally) redefined
SSL3_RT_MAX_PLAIN_LENGTH for Tx to be 2048.
It works as expected. I'm wondering about the
"1024 +" values for compressed and encrypted length. A previous responder
said that compression is "universally unimplemented". And I'm wondering
what type of encryption would expand a 16384-byte chunk by 1024 bytes. Are
these values appropriate, or are these values appropriate + a large bit extra to
prevent buffer overruns?
And if I change my plain-length max to 2048, what would
be appropriate padding?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marton Anka
Sent: Thursday, September 22, 2005 4:08 PM
To: openssl-users@openssl.org
Subject: Re: Reducing SSL3 Buffer Requirements
On 9/22/05, Martin Del
Vecchio <[EMAIL PROTECTED]>
wrote:
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?
This should be perfectly fine. Implementing the "grow-on-demand" feature would be nice, but then I'd also like those buffers to shrink to their original size after a certain amount of time. This should definitely be doable, and I wouldn't mind sponsoring the development. Stephen?
-Marton Anka
