On Mon, Sep 10, 2001 at 04:20:10PM -0700, Henry Yip wrote:
> Hi All,
>
> I have 2 questions.
>
> 1)
> I'm trying to do client authentication from a Server using
> PureTLS. On the server side, I call:
> socket.sendClose()
> socket.close()
> when I can't verify the client's host against the certificate chain.
>
> Now, Should SSL_connect() return an error on the client at this point?
Sorry if this kind of off-topic, but using the native openssl libraries
SSL_connect returns an error at this point IF the server's SSL is set
to verify the client AND the verify locations are set. If you don't
set it to this mode, I guess it will accept the connection and SSL_connect
will succeed.
In my apps using SSL, I usualy handle more than one client, so I set
these to the context, and then just create separate SSL connections from
it for every client. I use these functions (for the server):
SSL_CTX_load_verify_locations to set the file and/or the directory
containing the trusted certificates.
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT |
SSL_VERIFY_CLIENT_ONCE, my_verify_cb)
my_verify_cb can be NULL if you don't want extra diagnostics or don't need
to force some verify errors to be ignored. There is more info in the
manual pages.
Then you load the certificate and private key for the server into the ctx.
The server is ready to accept connections.
It is a good idea to verify the server from the client using the same
verify setting (except for SSL_VERIFY_CLIENT_ONCE).
> Seems like select() is not detecting the closed socket condition also.
IIRC, select detects a closed socket as a socket ready for reading (and
you get 0 bytes when you actualy read).
[...]
> 2)
> If I attempt to do a SSL_Connect() to a port that has a non SSL server
> listening, or
> do a write() and readv() (non ssl) to a port with a SSL server listening.
> Both scenarios
> just hangs there.
SSL_connect does SSL handshake which involves both reading and writing,
it is normal to block if the other side is not acting correctly.
The same with reading or writing to somebody who does SSL_accept.
>
> I just want to confirm this is expected behavior and what's the best way to
> recover from this condition? I believe the best way to handle this is
> by setting up a timer. Any better ideas?
Setting timeouts with openssl is always a good idea. I don't know what's
behind those functions, but I had problems with a server blocking on
SSL_accept while other connections wait (I put it in the main accept()
loop before the fork). The only solution for a single process app is to use
non-blocking sockets, but it gets too complicated when you want to SSL_read
and it sais you should select for writing ;)
Hope this helps a bit
--
Players win and winners play
Have a lucky day
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
