>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.
Yes. With one minor change (add pktmp = X509_get_pubkey(peer); after line
774), it compiles and you can substitute it for s_client.c and get a windows
version that interacts with the terminal. With more minor changes, you
could
supply a passphrase on the command line so you could script a server that
asked
for client certs by piping HTTP commands into it through stdin (otherwise,
the prompt breaks stdin). With more minor changes you could put HTTP
options on
the command-line and save yourself the effort of putting everything into a
file. With more minor changes you could buffer stdin instead of reading and
writing a character at a time (see lines 629 and ff., e.g. cbuf[0] =
_getch();
etc.), which rather compromises any performance evaluation you might be
trying
to make. And you could try to fix the problem where you get an infinite
number
of "read from 00A898E0 [00B755E8] (5 bytes => -1 (0xFFFFFFFF))" messages
when
you turn debugging on to do a packet trace. Or you could just clone the
good
s_client.c bits and go with a programming model more suited to an OS with
idiomatic (shall we say) i/o subsystems... :) Hey, it's not s_client.c and
it's pals, that *I* feel dissatisfied with, here!
>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.
OK. Can't say as I can tell, either, from a ten minute look over
s3_clnt.c:ssl3_connect(). I still find this sequence of commands
where you essentially say a) prepare the handle to do a <connect|accept>,
b) do a <connect|accept> to be a little torturous ...
> 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.
And the problem would be... what? That the client doesn't print out a
message when there's nothing there to print out? The client I submitted
can also do v2. I guess it wouldn't have been a bad idea to put a comment
to the effect that the return value from get shared ciphers will always be
NULL for an ssl v3 or TLS client...
TT
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
