On Wed, Mar 18, 2009 at 7:40 PM, Nate Leon <n8l...@gmail.com> wrote: > 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.
Not exactly. you can write to the BIO_mem source/sink to fill it, and BIO_read from it to pull data from it. (IIRC, BIO_s_mem can auto-adjust the internal buffer size, but it might be that only happens when you instantiate one using BIO_new(BIO_s_mem()) -- I am not sufficiently awake to pull that info out of my high hat right now, though I've been using this quite recently. :-( ) Anyway, I'd say BIO_pair would be the nicest way to go (as it can handle bidir traffic, so you only need one at the backend). > 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); non non non... this BIO_f_cipher() BIO filter is only for when you do your own protocols; the idea here is (and sorry for sounding overly vague right now) to put a BIO_pair in place of the usual BIO_s_socket source/sink. Recall that OpenSSL offers BIO *chains*, so you should keep the regular chain intact (SSL_read/SSL_write at topside; traverse BIO chain down to source/sink to insert BIO_pair as a source+sink). The SSL layer should do its own cipher BIO adding and all; all you should replace is the source/sink BIOs. Sorry I can't draw a clear picture right now; too much SQL for me today: brain has shut down. And another side note that wasn't mentioned last time (didn't want to dump all the caveats in one go) but be aware that SSL BIO's (and (SSL *) sessions!) are 'threadsafe' in the sense that OpenSSL *assumes* a (SSL *) or /any/ BIO remains inside a single thread from the moment it becomes 'active', i.e. is set up / is going to do some work. I don't know how you're going to do the IOCP implementation, but be very much aware that that model does NOT tie a socket to a single thread, so there's bound to be some really wicked thread-related issues as the (SSL *) and the BIOs will cross thread boundaries on and off while active - due to the way IOCP work. Unless you do perform some very fancy footwork. ;-) (I seem to recall the documentation mentions this as SSL* and BIOs being 'thread-AWARE' rather than 'threadsafe'. Too tired to go find chapter and verse, though.) > 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?? Like I said: don't use BIO_f_cipher() -- that's for when you want to apply BIO chains to custom (encrypted) data; SSL does it all for you within the SSL*: topside you have plaintext I/O for the application using SSL_read/SSL_write(), backside (i.e. at source/sink 'bottom') you have the SSL protocol exchange mixed with encrypted data and everything as it travels the wire: thus the BIOs linked to the SSL* session using SSL_set_bio() will carry the raw network traffic. All those two BIOs (usually the same BIO used twice) need to do it transfer this raw data. That's where the BIO_pair comes in (head is clearing up a bit; this is stream-of-conscious written, so please bear with me): you get yourself a BIO_pair and stuff one BIO into SSL_set_bio(.., here, here) and the other BIO of the pair is yours to use for feeding / fetching raw network data as obtained / transmitted through the IOCP code. (This is, IIRC, what ssltest et al showcase as well; you may want to grep through the apps/ and demos/ dirs on the lookout for further BIO_pair and SSL_set_bio samples as ssltest definitely isn't the only one in there doing this.) On the application side, you still have SSL_write/SSL_read, like before (and here I had that thread-crossing warning thought I mentioned above). This is where the SSL* fetches/delivers the plaintext data. > now converting it over to Async IO (IOCP) so now I'm having to re-work > the TLS model. I'm thinking about it; there's some very interesting issues I hadn't thought of before. IOCP thread usage vs. SSL/BIO assumptions being the major one. > Thanks for the renegotiation unit test idea, and thanks for the reply, You're welcome! -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
