Re: [Libevent-users] libevent-2.0 and openssl filter

[tuna@xxxxxxxx]

Hi, 

Wed, 4 Nov 2009 11:07:10 -0500, Nick Mathewson <nickm@xxxxxxxxxxxxx>
wrote:
> Right now the bufferevent_openssl module has a BIO implementation that
> can direct IO through a bufferevent.  The BIO itself isn't isn't
> exposed as part of the public interface right now; should it be?
> 
> 
> If all you want is an SSL-encrypted connection, and you're using
> bufferevents, I'd suggest the bufferevent_openssl logic in svn trunk.
> It presents the same interface as a regular socket bufferevent, but it
> does uses openssl to do SSL (either over a socket directly, or over
> another bufferevent).
> 
I quickly (so I might be wrong) went through your bufferevent_openssl
module. Seems nice but for SSL underlying protocol only, right? 
I guess it would indeed require much work to expose BIO so we could set
the BIO we want. But here is what I had in mind, for instance this
pseudo-code:

/*We assum fd is a socket fd, base is an already set up struct
event_base etc...*/
struct bufferevent *bev;
if (do_we_want_ciphering())
{
	/*We initiate the BIO we want*/
	BIO *bio = BIO_new(BIO_s_socket());

	EVP_CIPHER = /*we set up our cipher, with its required
	parameters ...*/

	BIO_set_cipher(/*the cipher we want*/)
	BIO_set_fd(bio, fd ....);

	/*Here we "inject" our BIO into a bufferevent so we will
	almost never deal again with BIO API itself. I.e.: while
	getting/setting buffer content from bufferevent, it will be
	decrypted/encrypted automtically.*/

	bev = bufferevent_BIO_new(base, bio, ...);

} 
else
{
	/*"classic" code, bev is initiated as we usually do*/
}

/*rest, callbacks and so on*/

I don't know how much work it would require. Maybe quite much
actually, mainly due to error handling, fd types or so etc...

What's your opinion about such method?

TB
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.