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]
