> List: openssl-dev
> Subject: Re: SSL_connect and non-blocking reads (fwd)
> From: Geoff Thorpe <[EMAIL PROTECTED]>
> Date: 2000-04-05 2:22:58
> 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.
I'm a bit confused with what you are saying here. You are saying that
session caching doesn't apply to the client end, but then the client has
to supply the session it wants to resume with the server. How is the
client able to do this if it dies?
Also, on the server side, if I want to drop a connection to the client but
I don't want to have to free and create a new SSL is the follwoing logic
correct:
SSL_CTX *ctx=SSL_CTX_new(
SSL *ssl= SSL_new(ctx);
/*create socket*/
/*bind socket*/
/*listen socket*/
while (1)
{
accept(fd);
SSL_set_fd(ssl, fd);
SSL_accept(ssl);
/*Do some reads*/
/*Do some writes*/
close (fd);
SSL_shutdown(ssl);
}
SSL_CTX_free(ctx);
SSL_free(ssl);
I had a look at s_client and s_server but they heavily use BIO calls which
I want to avoid using if I can. The SSL* wrappers are much nicer to use.
Many thanks in advance,
--Douglas
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
