On Tue, Apr 27, 1999 at 11:18:20AM -0400, Tom Titchener wrote:
> Finding the #ifndef WINDOWS in apps/s_client.c prevented me from
> using the otherwise-oh-so-complete feature set of this application
> on my OS 'of choice'
Well, also in the "apps" directory there's a file sc.c that purports
to be a version of s_client.c that has been doctored for Windows.
Some time ago, I asked if anyone saw any value in integrating it into
s_client.c.
[...]
> /* Initialize the state of the connection so the first i/o operation
> * knows to do the SSL connect. Strictly speaking, this not necessary,
> * as this code goes ahead and calls SSL_connect() anyway (so I can
> * put the connect tracing stuff in one handy spot). But look closely
> * in ssl/s_client.c for a call to SSL_connect. You won't find one.
> */
> SSL_set_connect_state(con);
Sure it is not necessary? I have not looked at the implementations in
ssl/* again, but I'd guess that if you don't do this, you might run
into the same problems as a server that doesn't call
SSL_set_accept_state, namely, if there are short reads, an
uninitialised function pointer (handshake_func) might be used.
[...]
> if ((p=SSL_get_shared_ciphers(con,buf,BUFSIZ)) != NULL) {
> BIO_printf(ebio,"---\nCiphers common between both SSL endpoints:\n");
Now s_client.c has a comment that your program has not :-)
SSL_get_shared_ciphers cannot work for the client if SSL 3 or TLS
is used: The client sends a list of ciphers, and the server just picks
one.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
