All good points. I was not planning to go to production with that code - I was just happy to see something working. :) I was trying to figure out a way to call SSL_set_bio once per session with both read and write buffers, but I am stumped there since this call: m_bioMem = BIO_new_mem_buf(encryptedData, nEncDataSize)
needs to change based on the data that just came off the wire. Which naturally brings us to the BIO pairs issue. That is the path I started going down... chaining a cipher BIO with a memory BIO, and planning to write the encrypted data into one end of the chain and read the clear text out of the other end. (and vice-versa) However, I got stuck there, 'cuz to create a cipher BIO, I need to specify the cipher and key. e.g.: from Ex 4-8 in O'Reilly's OpenSSL book: BIO* cipher = BIO_new(BIO_f_cipher()); BIO_set_cipher(cipher, EVP_des-ese3_cbc(), key, NULL, 1); In my case, this was just negotiated between my server and the connecting client during the SSL_accept call. I believe the negotiated cipher and key are living in my SSL object, but I couldn't see how to extract those objects and pass them to the BIO_set_cipher call for each new session?? As for the renegotiation, of course you are absolutely correct that I am not handling those in my code snippets. But I am fully aware of those cases as I have been shipping a TLS-based SMTP server for several years. e.g. I've seen SSL_accept take several iterations of reads and writes. But the current server is select() based, and I am now converting it over to Async IO (IOCP) so now I'm having to re-work the TLS model. I did notice the O'Reilly reference to the ssltest.c sample. I haven't looked at that yet, but I will. :) Thanks for the renegotiation unit test idea, and thanks for the reply, n8 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ger Hobbelt Sent: Tuesday, March 17, 2009 5:38 PM To: [email protected] Cc: [email protected] Subject: Re: TLS, BIOs, SSL_read/write Please follow Victor's advise, because this call > SSL_set_bio(m_ssl, NULL, bioMem); and it's counterpart: SSL_set_bio(m_ssl, m_bioMem, NULL); are NOT how this sort of thing is done. This is EXTREMELY DANGEROUS (or should I say: fatal?) coding as you forcibly remove either read or write BIO facilities for an active SSL connection. This indicates that you assume you are in total control over when SSL will [need to] write or read (and /not/ the other way) at /all/ time. Which is a falsehood. Your system can be taken down easily by any client which triggers a renegotiation. And this is only one scenario, where read can cause a write and vice versa. BIO pairs have been created to provide for such bidirectional I/O and you should both read up on the SSL_read/SSL_write documentation (and heed the notes which are mentioned for nonblocking I/O: you will see their effects at all times as you are plugging in your own I/O mechanism at the backend (IOCP)). Also check out how BIO pairs et al are used for in-memory SSL sessions, such as shown in the ssltest application which comes OpenSSL. (There are more sample apps which use in-memory BIOs for performing SSL communications.) A quick test to check if you handle renegotiations at all in your IOCP backend flow is configuring your server to trigger a renegotiation by itself by calling BIO_set_ssl_renegotiate_bytes() with a trigger setting of, say, a few KBytes of received data - a small amount which will make it happen quickly and often so you can test how things go down. But be aware that surviving this does not guarantee you'll survive client-triggered renegotiation - which is not an uncommon thing, especially when transfer amounts rise into the multi-megabytes per connection. Remember: SSL is not just shoving your bytes across the line in encrypted form. It adds a *protocol* *layer* on top of sockets, which should be facilitated for the entire lifetime of each socket connection. <snip> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
