RE: Problem using Broadcom uBSec engine in 0.9.8
That solves the problem! I was missing the second LOAD command, to the OpenSSL stub, telling it where to find the Broadcom library. Thanks! -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 8:54 PM To: openssl-dev@openssl.org Cc: Martin Del Vecchio Subject: Re: Problem using Broadcom uBSec engine in 0.9.8 Hi Martin, Comments inline. On October 28, 2005 09:54 am, Martin Del Vecchio wrote: Yes, there are two different libubsec.so libraries: 1) The one built in OpenSSL with ./config shared; this is the stub library that contains bind_engine, etc. 2) The one provided by the Broadcom SDK; this is the actual library that contains ubsec_bits_to_bytes, etc. If I put 1) in the right place (/usr/local/ssl/lib/engines), then ENGINE_by_id (ubsec) succeeds. If I remove it from that directory, then ENGINE_by_id (ubsec) fails. So I put 1) in the right place. Then I load the dynamic engine: Engine = ENGINE_by_id (dynamic); and give it the following commands: Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, ubsec, 0); Return = ENGINE_ctrl_cmd_string (Engine, LOAD, NULL, 0); These three steps are essentially what 'ENGINE_by_id(ubsec)' does. The result is that 'Engine' is now the ubsec engine and no longer the (or rather a copy of the) dynamic engine. Both succeed; it find the library in in /usr/local/ssl/lib/engines/, which is the OpenSSL stub. But when I run: Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); It fails, because it can't find the ubsec_bits_to_bytes symbol. Yup, ENGINE_set_default() will try to initialise the engine - if it isn't already initialised - before setting it as a default implementation. Loading the broadcom library is delayed until the initialisation step to ensure you can always get a structural reference to an engine, whether or not you have the corresponding hardware, drivers, [etc]. Eg. it's what allows you see the ctrl-commands available for engines even if you can't initialise them as yet; 'apps/openssl engine -' So it smells like it wants the Broadcom library in the LOAD command, so I change that to: Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, /usr/lib/libubsec.so, 0); Which is where the Broadcom library is. Now the LOAD command fails, because it can't find the bind_engine symbol. So now it's looking for the OpenSSL stub library there! So then I renamed the Broadcom library to /usr/lib/bc.libubsec.so, and said: Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, /usr/lib/bc.libubsec.so, 0); And I got the same error. Did you do this as a replacement for the earlier SO_PATH step (ie. prior to the LOAD)? Until you run the LOAD command, 'Engine' is the dynamic engine. Once you've called LOAD, 'Engine' is the loaded ubsec engine. At this point, the SO_PATH ctrl-command is the one implemented by the ubsec engine and not that of the dynamic engine, ie. it refers to the broadcom library and not the engine library, but that's only *after* the LOAD. I think this is probably what you're missing - let me know if I've misunderstood. So, you probably want; #ifdef DO_IT_THE_LONG_WAY /* SO_PATH points the dynamic engine to the ubsec engine */ Engine = ENGINE_by_id (dynamic); Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, ubsec, 0); /* LOAD changes 'Engine' to be a ubsec engine handle */ Return = ENGINE_ctrl_cmd_string (Engine, LOAD, NULL, 0); #else /* This achieves the same thing as above, if the library has the * appropriate file-name and path. */ Engine = ENGINE_by_id (ubsec); #endif /* SO_PATH points the ubsec engine to the broadcom library */ Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, bc.libubsec.so, 0); /* This implicitly initialises the engine */ Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Problem using Broadcom uBSec engine in 0.9.8
Yes, there are two different libubsec.so libraries: 1) The one built in OpenSSL with ./config shared; this is the stub library that contains bind_engine, etc. 2) The one provided by the Broadcom SDK; this is the actual library that contains ubsec_bits_to_bytes, etc. If I put 1) in the right place (/usr/local/ssl/lib/engines), then ENGINE_by_id (ubsec) succeeds. If I remove it from that directory, then ENGINE_by_id (ubsec) fails. So I put 1) in the right place. Then I load the dynamic engine: Engine = ENGINE_by_id (dynamic); and give it the following commands: Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, ubsec, 0); Return = ENGINE_ctrl_cmd_string (Engine, LOAD, NULL, 0); Both succeed; it find the library in in /usr/local/ssl/lib/engines/, which is the OpenSSL stub. But when I run: Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); It fails, because it can't find the ubsec_bits_to_bytes symbol. So it smells like it wants the Broadcom library in the LOAD command, so I change that to: Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, /usr/lib/libubsec.so, 0); Which is where the Broadcom library is. Now the LOAD command fails, because it can't find the bind_engine symbol. So now it's looking for the OpenSSL stub library there! So then I renamed the Broadcom library to /usr/lib/bc.libubsec.so, and said: Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, /usr/lib/bc.libubsec.so, 0); And I got the same error. So how do I get around this problem of the OpenSSL stub and the Broadcom library having the same name? Where should I place each in order for them both to be loaded? Thanks again. -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] Sent: Thursday, October 27, 2005 10:10 PM To: openssl-dev@openssl.org Cc: Martin Del Vecchio Subject: Re: Problem using Broadcom uBSec engine in 0.9.8 On October 27, 2005 02:47 pm, Martin Del Vecchio wrote: I get an error similar to what I was seeing before; it can't find the symbol 'ubsec_bytes_to_bits': error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could not bind to the requested symbol name (dso_dlfcn.c:261) - symname(ubsec_bytes_to_bits): /usr/local/ssl/lib/engines/libubsec.so: undefined symbol: ubsec_bytes_to_bits OK, you need to know that the ubsec engine itself is a stub that uses a broadcom-provided library to do the actual ubsec operations, the engine merely slides functionality into openssl that is based on the the broadcom SDK. I think what's happening is that you've got the engine library loading *itself* rather than the broadcom support library. The error you see is just the first symbol that the ubsec engine tries to bind to - and of course none of the expected symbols exist because it's not the broadcom library, it's the engine library. I don't have broadcom hardware nor their SDK, libraries/drivers, etc, so you may need to dig around to get to the bottom of this. But first off, figure out which library is which :-) If the broadcom-provided lib is called libubsec.so, that'd be an unfortunate name-conflict but it shouldn't be catastrophic, because openssl doesn't look for engine libraries in arbitrary locations (doing so would have unquantifiable security consequences) but in an openssl-specific location. The ubsec engine, on the other hand, should pick up the broadcom library using standard library locations - and this is either missing or in a directory that isn't getting searched (LD_LIBRARY_PATH might help here) - it seems you've fixed this problem by moving/copying the engine library somewhere visible instead so that it loads itself instead of the broadcom lib. Hope that helps, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Problem using Broadcom uBSec engine in 0.9.8
You say it should fall back to automatically searching the default path to load the engine shared lib (libubsec.so). I guess this isn't happening. I found the uBSec shared library in /usr/lib/engines/libubsec.so. I added the following code to my test program to load it via the dynamic engine: Engine = ENGINE_by_id (dynamic); Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, /usr/lib/engines/libubsec.so, 0); Return = ENGINE_ctrl_cmd_string (Engine, LOAD, NULL, 0); All of those functions return success. Then I call: Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); And I get an error. The dump of errors says: error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library (dso_dlfcn.c:162) - filename(/home/armckinn/svn/os/tmp/usr/lib/engines/libubsec.so): /home/armckinn/svn/os/tmp/usr/lib/engines/libubsec.so: cannot open shared object file: No such file or directory error:25070067:DSO support routines:DSO_load:could not load the shared library (dso_lib.c:244) error:260B6084:engine routines:DYNAMIC_LOAD:dso not found (eng_dyn.c:450) error:2606A074:engine routines:ENGINE_by_id:no such engine (eng_list.c:411) - id=ubsec error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could not bind to the requested symbol name (dso_dlfcn.c:261) - symname(ubsec_bytes_to_bits): /usr/lib/engines/libubsec.so: undefined symbol: ubsec_bytes_to_bits error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name (dso_lib.c:294) error:80069067:ubsec engine:UBSEC_INIT:dso failure (e_ubsec.c:427) error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed (eng_table.c:161) -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 9:25 PM To: openssl-dev@openssl.org Cc: Martin Del Vecchio Subject: Re: Problem using Broadcom uBSec engine in 0.9.8 On October 25, 2005 11:06 am, Martin Del Vecchio wrote: I'm still looking for help with this problem. The uBSec support works in 0.9.7g with static linking. The uBSec support works in 0.9.7g with shared libraries. The uBSec support works in 0.9.8 with static linking. The uBSec support fails in 0.9.8 with shared libraries. [snip] Here is the command line I use to build the test program: gcc -o test test.c -I include ./libssl.a ./libcrypto.a -ldl It feels like this is such a major bug that it can't possibly be real, and I must be doing something wrong. The problem is that if you do a shared build, the engines are built as shared-libraries too - that is, this is now the case but wasn't under 0.9.7. Your code is calling ENGINE_load_ubsec() which doesn't exist in libcrypto, because when you call ENGINE_by_id(ubsec) it should fall back to automatically searching the default path to load the engine shared lib (libubsec.so). Let me know if this isn't the case, but from an initial glance that seems to be what you're hitting. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Problem using Broadcom uBSec engine in 0.9.8
Update: I noticed it was looking in the wrong path (/home/armckinn/... etc). I rebuilt the library without setting the --prefix in the ./config command. It then was looking for the shared library in /usr/local/ssl/lib/engines/libubsec.so. That directory didn't exist, so I created it and copied /usr/lib/engines/*.so there. Now the engine is found by this line of code: Engine = ENGINE_by_id (ubsec); But when I call this function: Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); I get an error similar to what I was seeing before; it can't find the symbol 'ubsec_bytes_to_bits': error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could not bind to the requested symbol name (dso_dlfcn.c:261) - symname(ubsec_bytes_to_bits): /usr/local/ssl/lib/engines/libubsec.so: undefined symbol: ubsec_bytes_to_bits error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name (dso_lib.c:294) error:80069067:ubsec engine:UBSEC_INIT:dso failure (e_ubsec.c:427) error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed (eng_table.c:161) When I look in the library for that symbol, I get: # nm /usr/local/ssl/lib/engines/libubsec.so | grep bytes 4904 b p_UBSEC_ubsec_bits_to_bytes 48fc b p_UBSEC_ubsec_bytes_to_bits -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Del Vecchio Sent: Thursday, October 27, 2005 2:34 PM To: Geoff Thorpe; openssl-dev@openssl.org Subject: RE: Problem using Broadcom uBSec engine in 0.9.8 You say it should fall back to automatically searching the default path to load the engine shared lib (libubsec.so). I guess this isn't happening. I found the uBSec shared library in /usr/lib/engines/libubsec.so. I added the following code to my test program to load it via the dynamic engine: Engine = ENGINE_by_id (dynamic); Return = ENGINE_ctrl_cmd_string (Engine, SO_PATH, /usr/lib/engines/libubsec.so, 0); Return = ENGINE_ctrl_cmd_string (Engine, LOAD, NULL, 0); All of those functions return success. Then I call: Return = ENGINE_set_default (Engine, ENGINE_METHOD_ALL); And I get an error. The dump of errors says: error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library (dso_dlfcn.c:162) - filename(/home/armckinn/svn/os/tmp/usr/lib/engines/libubsec.so): /home/armckinn/svn/os/tmp/usr/lib/engines/libubsec.so: cannot open shared object file: No such file or directory error:25070067:DSO support routines:DSO_load:could not load the shared library (dso_lib.c:244) error:260B6084:engine routines:DYNAMIC_LOAD:dso not found (eng_dyn.c:450) error:2606A074:engine routines:ENGINE_by_id:no such engine (eng_list.c:411) - id=ubsec error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could not bind to the requested symbol name (dso_dlfcn.c:261) - symname(ubsec_bytes_to_bits): /usr/lib/engines/libubsec.so: undefined symbol: ubsec_bytes_to_bits error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name (dso_lib.c:294) error:80069067:ubsec engine:UBSEC_INIT:dso failure (e_ubsec.c:427) error:260B806D:engine routines:ENGINE_TABLE_REGISTER:init failed (eng_table.c:161) -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 9:25 PM To: openssl-dev@openssl.org Cc: Martin Del Vecchio Subject: Re: Problem using Broadcom uBSec engine in 0.9.8 On October 25, 2005 11:06 am, Martin Del Vecchio wrote: I'm still looking for help with this problem. The uBSec support works in 0.9.7g with static linking. The uBSec support works in 0.9.7g with shared libraries. The uBSec support works in 0.9.8 with static linking. The uBSec support fails in 0.9.8 with shared libraries. [snip] Here is the command line I use to build the test program: gcc -o test test.c -I include ./libssl.a ./libcrypto.a -ldl It feels like this is such a major bug that it can't possibly be real, and I must be doing something wrong. The problem is that if you do a shared build, the engines are built as shared-libraries too - that is, this is now the case but wasn't under 0.9.7. Your code is calling ENGINE_load_ubsec() which doesn't exist in libcrypto, because when you call ENGINE_by_id(ubsec) it should fall back to automatically searching the default path to load the engine shared lib (libubsec.so). Let me know if this isn't the case, but from an initial glance that seems to be what you're hitting. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ Self-interest and materialistic desire are parts of who we are, but not all. To base a social and economic system on these traits is dangerously fundamentalist. -- Joel Bakan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager
RE: Problem using Broadcom uBSec engine in 0.9.8
I'm still looking for help with this problem.
The uBSec support works in 0.9.7g with static linking.
The uBSec support works in 0.9.7g with shared libraries.
The uBSec support works in 0.9.8 with static linking.
The uBSec support fails in 0.9.8 with shared libraries.
Here's a matrix:
Version | ./config (static) | ./config shared |
0.9.7.g | Works | Works |
0.9.8| Works | Fails! |
Here is the command line I use to build the test program:
gcc -o test test.c -I include ./libssl.a ./libcrypto.a -ldl
It feels like this is such a major bug that it can't possibly be real,
and I must be doing something wrong.
Can somebody help me?
Thanks.
-Original Message-
From: Martin Del Vecchio
Sent: Thursday, October 20, 2005 10:42 AM
To: 'openssl-dev@openssl.org'
Subject: Problem using Broadcom uBSec engine in 0.9.8
I am using OpenSSL on Linux in a shared library environment (./config
shared).
I am trying to load support for the Broadcom uBSec engine. Here is a
test program:
int main (int argc, char *argv[])
{ ENGINE *Engine;
SSL_library_init();
SSL_load_error_strings();
OpenSSL_add_all_algorithms();
ENGINE_load_ubsec();
// See if we can find the ubsec engine
Engine = ENGINE_by_id (ubsec);
if (Engine)
printf (ENGINE_by_id() found uBSec at %p.\n, Engine);
else
printf (ENGINE_by_id() did not find UBSec.\n);
return (0);
}
I compile and link this file (test.c) with OpenSSL 0.9.7g:
gcc -o test test.c -I include ./libssl.so ./libcrypto.so
I run it, and it reports that it finds the uBSec engine.
I try this with OpenSSL 0.9.8 and I get a link error:
/tmp/ccuqAevP.o(.text+0x12c): In function `main':
: undefined reference to `ENGINE_load_ubsec'
collect2: ld returned 1 exit status
This symbol is in e_ubsec.c, but when I include the corresponding .o
file, I get the same error. That's because the symbol is not defined in
e_ubsec.o, because it is inside a conditional:
#ifdef OPENSSL_NO_DYNAMIC_ENGINE
This symbol is not defined, because I chose the shared-library
configuration.
How can I use the built-in uBSec engine in a shared-library environment?
Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Problem using Broadcom uBSec engine in 0.9.8
I am using OpenSSL on Linux in a shared library environment (./config
shared).
I am trying to load support for the Broadcom uBSec engine. Here is a
test program:
int main (int argc, char *argv[])
{ ENGINE *Engine;
SSL_library_init();
SSL_load_error_strings();
OpenSSL_add_all_algorithms();
ENGINE_load_ubsec();
// See if we can find the ubsec engine
Engine = ENGINE_by_id (ubsec);
if (Engine)
printf (ENGINE_by_id() found uBSec at %p.\n, Engine);
else
printf (ENGINE_by_id() did not find UBSec.\n);
return (0);
}
I compile and link this file (test.c) with OpenSSL 0.9.7g:
gcc -o test test.c -I include ./libssl.so ./libcrypto.so
I run it, and it reports that it finds the uBSec engine.
I try this with OpenSSL 0.9.8 and I get a link error:
/tmp/ccuqAevP.o(.text+0x12c): In function `main':
: undefined reference to `ENGINE_load_ubsec'
collect2: ld returned 1 exit status
This symbol is in e_ubsec.c, but when I include the corresponding .o
file, I get the
same error. That's because the symbol is not defined in e_ubsec.o,
because it is
inside a conditional:
#ifdef OPENSSL_NO_DYNAMIC_ENGINE
This symbol is not defined, because I chose the shared-library
configuration.
How can I use the built-in uBSec engine in a shared-library environment?
Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Padding in SSL3_RT_MAX_ENCRYPTED_LENGTH excessive?
Title: Padding in SSL3_RT_MAX_ENCRYPTED_LENGTH excessive? In ssl\ssl3.h, SSL3_RT_MAX_ENCRYPTED_LENGTH is defined as: #define SSL3_RT_MAX_ENCRYPTED_LENGTH (1024+SSL3_RT_MAX_COMPRESSED_LENGTH) I assume that this padding is there to handle the padding performed by various encryption algorithms. The pad value (1024 bytes) seems excessive to me. What is the worst-case scenario for expansion during encryption for a 16,384-byte record? For a 4,096-byte record? I assume that it depends on the algorithms selected, but are there any calculations that can be done to determine a correct value here? Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL per session memory usage
Title: Re: SSL per session memory usage Prashant Kumar wrote: Hello Goetz, Thank you for your input. I tested re-negotiation and it works fine with this change \ since while doing re-negotiate the OpenSsl returns SSL_ERROR_WANT_READ or \ SSL_ERROR_WANT_WRITE in which case I will not free the buffer until the handshake is \ done. Regards, Prashant. Prashant, did you ever submit your patches? I am attacking the same problem, and I would like to adopt your strategy. Thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Adding -DOPENSSL_NO_COMP gets compile errors in s3_srvr.c
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 types3_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 VecchioSent: Friday, September 23, 2005 11:18 AMTo: openssl-users@openssl.orgSubject: RE: Reducing SSL3 Buffer Requirements I hacked around with the Tx buffer size inthe 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) Andseparatedthem 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 AnkaSent: Thursday, September 22, 2005 4:08 PMTo: openssl-users@openssl.orgSubject: 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 sendarbitrarily large messages,one 16K record at a time.Is there any harm in me deciding to sendlarge messages one 4K recordat 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
