"Titchener, Tom" <[EMAIL PROTECTED]>:
>> 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 [...] 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.
Sounds as if no-one would miss it if we just removed it? The diffs
from s_client.c to sc.c aren't so many, and if it doesn't even serve
as a good example for how things could be done, there's probably no
point in keeping it.
>> 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 ...
Well, it is; but it makes sense, since when you're doing non-blocking
I/O, you may have to call SSL_connect quite a lot of times in order to
finish the handshake. And SSL_new doesn't set handshake_func because
you don't have to decide whether you want a client or a server at that
time.
>> 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?
It's not a problem at all; it's just that when I read your program it
occured to me that this behaviour may not be obvious to someone who
reads it or s_client.c to get an idea how the library can be used.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
