I have a similiar situation, however, I am not using threads. What I want is
to create a proxy that establish a connection with a server, store that
connection, when a client talks again to the proxy it pulls the session for
that client else (create a new session, save it) and pass it to the child. I
tried this but the second time I use the SSL connection the server closes
the connection. any help would be appreciated
----- Original Message -----
From: "Geoff Thorpe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 04, 2000 10:22 PM
Subject: Re: SSL_connect and non-blocking reads (fwd)
> Hi there,
>
> At 09:45 AM 4/5/00 +1000, you wrote:
> >1) I have a multithreaded client which connects to the server using
> >multiple sockets. How do I make the client verify the server certificate
> >only once, say on the initial SSL_connect, and not for subsequent
> >connects?
>
> well session caching (which someone else mentioned) doesn't really apply
at
> the client, because there's no meaningful interpretation of a "cache"
other
> than a single (SSL_SESSION*) pointer. If the client wants to resume a
prior
> session (which is what you want if you're trying to avoid repeated
> negotiations) then it must supply *the* session it wants to resume before
> starting the handshake, it cannot point to a "cache" and let the handshake
> procedure choose as it goes along. The server can turn the client's resume
> request down for any reason (though it typically won't unless it has
> forgotten about it or the session has expired), in which case a regular
> handshake will result that will negotiate a new session.
>
> What I'd do is the following;
>
> (i) store an SSL_SESSION* pointer (initially set to NULL) somewhere global
> to all your running clients (threads) and lock it for thread-safety.
>
> (ii) every time an SSL handshake completes, lock the (SSL_SESSION*) -
which
> I'll call "resume_session" for illustration - and do the following sort of
> thing before unlocking it;
> {
> SSL_SESSION *temp;
> temp = SSL_get1_session(ssl);
> if((temp != NULL) && (resume_session != NULL)) {
> SSL_SESSION_free(resume_session);
> resume_session = temp;
> }
> }
> (NB: Yes that is a "1" in the SSL_get1_session call ... it ensures the
> reference counting is incremented correctly so your session doesn't
> mysteriously disappear when the SSL closes down - possibly in another
> thread - leaving you no way of knowing except to try using it and have
your
> program crash).
>
> (iii) every time you're about to start a new SSL handshake, lock the
> "resume_session" and do the following with your new SSL structure before
> unlocking it;
> SSL_set_session(ssl, resume_session);
> It doesn't matter if resume_session is NULL because this will simply tell
> the "ssl" to do what it was already going to do - not ask to resume a
session.
>
> (iv) make sure that at the termination of your program you check the value
> of resume_session and if it is non-null, do a final SSL_SESSION_free() on
> it to prevent leaks.
>
> (v) read my "PS:" below once you're following all this ...
>
> >2) The SSL_read/SSL_write API doesn't seems to support non-blocking IO.
I
> >Is it sufficient to set the underlying file descriptor for non-blocking
IO
> >and just use SSL_set_fd to enable this? And if I change the properties of
> >the underlying file desc. can I just issue another SSL_set_fd to update
> >the SSL socket?
>
> I'm not too sure about this myself - I prefer not to use the BIOs that
> operate with the socket descriptors directly. Have you looked at
> apps/s_client.c (and associate files)? If you decide to do the networking
> yourself and pass data to and from OpenSSL in memory, you could use
> BIO-pairs (something Bodo mentioned recently, and is illustrated in the
> source for test/ssltest) or memory BIOs (BIO_s_mem() - something I prefer
> because it's obvious, simple, and more difficult to get wrong than most
> other approaches). I'm sure there's other ways to skin the cat too.
>
> Cheers,
> Geoff
>
> PS: You should be careful to avoid doing *any* OpenSSL operations other
> than the SSL_get1_session and/or SSL_set_session calls between the locking
> and unlocking of your mutex. The reason is that OpenSSL uses its own
global
> locks based on object types - and if one of your threads has your mutex
> locked while doing OpenSSL operations, and another thread is doing OpenSSL
> operations that involves its own locks and all sorts of callbacks or other
> program logic that relates to the first thread, then there's the potential
> for dead-locks (each thread requires the other thread to release a lock
> before it can continue). By keeping the locks *only* around those two
> calls, you will prevent any such program logic at your end creating these
> dilemmas - and they can occur more easily than you might think. :-)
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
