I added -DOPENSSL_NO_COMP in an effort to remove all
compression, and I get the following errors when compiling
ssl3_send_server_hello() in s3_srvr.c:
s3_srvr.c: In function
`ssl3_get_client_hello':
s3_srvr.c:936: warning: assignment from incompatible pointer type
s3_srvr.c: In function `ssl3_send_server_hello':
s3_srvr.c:1092: error: request for member `id' in something not a structure or union
s3_srvr.c:936: warning: assignment from incompatible pointer type
s3_srvr.c: In function `ssl3_send_server_hello':
s3_srvr.c:1092: error: request for member `id' in something not a structure or union
These have to do with the fact that
s->s3->tmp.new_compression is defined as a char * when OPENSSL_NO_COMP is
enabled.
I can fix these errors, but I'm concerned that the
ssl3_send_server_hello() is attempting to negotiate compression even
though
OPENSSL_NO_COMP was specified. In fact,
OPENSSL_NO_COMP doesn't appear in the s3_srvr.c file at all.
Is this flag up-to-date?
Thanks.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Del Vecchio
Sent: Friday, September 23, 2005 11:18 AM
To: [email protected]
Subject: RE: Reducing SSL3 Buffer Requirements
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: [email protected]
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
