Timothy Canfield <[EMAIL PROTECTED]>:
> I have noticed that much of the overhead of an openssl session is during
> the connection stage. Is it possible for me to use only one SSL_session
> for every connection that which I accept. This will make it easier to
> crack a session, right? Will it also make the connection overhead less?
Note that client and server have to agree on session reuse -- if a
client does not ask (by sending a previous session ID in the initial
hello message), the server cannot force it to continue an old session.
Also note that each session is specific to a single client (the
wording of your question sounds as if you may not be aware of this).
Without session reuse, each new connection needs at least on
public-key operation, which is quite expensive to do. You don't
really have to worry about weakening the encryption by allowing
session reuse: Even if it's weak cryptography so that brute-forcing
the session key is possible, the actual encryption keys used for each
connection in that session are unique to a single connection; they are
derived from per-connection randomness (sent in clear) and a
session-wide master secret, which the attacker does not know (512-bit
public key cryptography is a lot harder to crack than 40-bit symmetric
cryptography, so no-one will do the former).
> If this solution makes sense, how do I go about it? Do I create a new
> session with SSL_SESSION_new() and then use SSL_set_session() after
> calling SSL_accept. How do the fields of this session get filled? Will
> this actually save connection overhead?
Each SSL_CTX structure automatically has a session cache shared by all
its SSL server structures (i.e. every server generated by calling
SSL_new). You have to call SSL_CTX_set_session_id_context first if
you use client verification, otherwise session reuse will not be
accepted. If your program has just one context, any short non-empty
string is acceptable as argument to SSL_CTX_set_session_id -- see
s_server.c.
If your server uses fork(2), then you'll have to use an external
session cache. Study the sources of the SSL/TLS implementations for
Apache to see how this is done.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
