> So to use native windows async i/o, I need to do the I/O myself (using bio
> pairs). Then I assume there is an easy way to figure out the ciphers and
> things agreed upon during the ssl handshake? Is this stuff readily
> available in the SSL object? At the risk of sounding lazy, what
> API's do I need to use to determine this info? :)
Yes, you do the I/O yourself. And you can get any information you want once
the handshake is complete. There is example code in the 'openssl'
application source. For the very lazy:
SSL_is_init_finished
SSL_get_current_cipher
SSL_CIPHER_get_bits
SSL_get_version
SSL_CIPHER_get_name
SSL_CIPHER_get_version
SSL_get_peer_certificate
SSL_get_finished
SSL_get_peer_finsihed
And so on.
One tip about working with BIO pairs -- totally forget that input has
anything to do with output! Just think -- there are four things I need to
do:
1) If my application needs to send any unencrypted data, I need to get it
to OpenSSL
2) If OpenSSL comes up with any decrypted output, I need to get it to my
application
3) If OpenSSL wants to send any encrypted data, I have to give it to the
socket
4) If the socket received any encrypted data, I have to give it to OpenSSL
But do not assume any connection between these things. They're just four
different things you need to do. Do not ever, for example, assume that
OpenSSL will have decrypted data for you just because you sent it encrypted
data or that OpenSSL can't possibly have any encypted data to send because
you haven't sent it any plaintext. (Though, of course, it's rational to
check for decrypted data after you hand OpenSSL encypted data. However, this
is not the only time you should check. One simple technique is to always
check for any way to make forward progress before giving up.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
