Hello Group,
The workaround of freeing s3->rbuf and s3->wbuf after the handshake is complete and after SSL_read, SSL_write, SSL_shutdown and so on returns success really seems to work. I have tested it running openssl as a SSL client and as a server. Taking a closer look at the code it looks like these buffers just act as a scratch buffers. With this change I could reduce the memory usage per SSL session significantly.
I just want to make sure that this does not cause any other problem. Any advice from OpenSSL Guru's is really appreciated.
Thanks you,
Prashant.
Prashant Kumar <[EMAIL PROTECTED]> wrote:
Prashant Kumar <[EMAIL PROTECTED]> wrote:
Hello Steve,Thank you for your help. I will look at section 3.2 of the RFC. As a workaround for this memory usage limitatioin, I free the "s3->rbuf" and "s3->wbuf" once the handshake is done. I allocate "s3->rbuf" and "s3->wbuf" during SSL_read, SSL_write, SSL_shutdown and so on. Once these calls return success (and not ssl_want_read and ssl_want_write), I free these buffers. My implementation uses memory BIOs. I see that with this workaround, to maintain SSL states, OpenSsl uses 7 to 12K per session.Do you see any problem with this approach ?Thank you for your help.Regards,Prashant.
JSec <[EMAIL PROTECTED]> wrote:Hi Prashant,
I don't know if you've taken a look at MatrixSSL - it's designed for
security on embedded devices, but it can work well for small per-session
memory usage scenarios as well. The internal memory usage is approximately
4KB per connection and 12KB during SSL/TLS handshake and certificate parsing
(depending on the size of a certificate).
SSL record data can be 16KB max, but the spec allows for expansion due to
headers, compression and padding so you'll see the actual maximum buffer
size in OpenSSL at 18698. MatrixSSL is based on encode/decode APIs that let
you handle the record memory more optimally. Typically you can keep the SSL
state (with a full record) at about 22KB per session, with a high water mark
slightly higher than 20KB * number_of_connections. This size is basically
guaranteed because you can define a single me mory block per connection, or a
single large block that holds all TLS sessions (this also helps with buffer
overflows and memory leaks). In practice, most records won't be a full 18K,
and most sessions won't be actively processing records, so your memory usage
will be less.
Within the TLS protocol itself, there are also extensions defined that allow
you to negotiate down to a smaller SSL record size, although there are
performance trade-offs to this solution. See section 3.2 of
http://www.faqs.org/rfcs/rfc3546.html
Steve
http://www.matrixssl.org Open Source Embedded SSL
Disclaimer: I work on the MatrixSSL team!
________________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Prashant Kumar
Sent: Tuesday, May 03, 2005 8:40 AM
To: openssl-dev@openssl.org
Subject: SSL per session memory usage
Hello All,
I was doing some scalin g testing to find out how much memory does OpenSsl
use per TLS session. I see that OpenSsl pre-allocates around 34821 bytes for
"rbuf" and 18698 bytes for "wbuf" in "ssl3_setup_buffers" to match with the
packet size defined in the RFC. Did anyone try modifying openssl to
allocate buffers on need basis from an pre-allocated pool and then release
it once the data is encrypted/decrypted.
I have around 0.7G of memory and I am trying to bring up 40,000 SIP/TLS
sessions. With the above allocation I won't go to far. Any help/idea is
appreciated.
Thank you all.
Regards,
Prashant.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
