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

[tuna@xxxxxxxx]

Wed, 4 Nov 2009 14:26:58 -0500, Nick Mathewson <nickm@xxxxxxxxxxxxx>
wrote :

> Before we get too far into this ... are you sure this is really what
> you want?  With the scheme you describe below, there is no way to
> prevent man-in-the-middle attacks, there is no data authentication,
> you may be vulnerable to replay and truncation attacks, and you need
> to roll your own key negotiation (which is notoriously difficult).
> Using SSL/TLS means that all of these cryptography problems will get
> solved for you.  Trying to solve them yourself -- or leaving them
> unaddressed -- is (IMO) asking for trouble.
> 
> That aside, let's figure out how you would do this, if it were a good
> idea.
I now about these security issues ;)
The fact is: I wanted a generic I/O events handler: thanks to
libevent, made life far easier!
Next step would be to have a generic ciphering entry point on the I/O
buffers, and not only a SSL based authentification/ciphering method. 
So here is my point with such generic BIO bufferevent.

> > /*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 ....);
> 
> I don't think this would work; BIO_set_cipher only behaves correctly
> for a BIO created with the BIO_f_cipher() filtering method.  So you'd
> have to say something like
I am not fully aware of how OpenSSL works which explains these
unconsistancies, my mistake.

> > 	/*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, ...);
> 
> Ah!  No, we don't support that right now.  I wouldn't be opposed to
> adding patch that did it, if somebody writes a good well-tested one,
> but the code in bufferevent_openssl.c is written (for performance) to
> use an SSL rather than an arbitrary BIO.
> 
> It wouldn't be _too_ hard to implement a variant that took a BIO.  I
> spend 30 mintues hacking together an untested proof-of-concept
> version, and uploaded it to the tracker at
> https://sourceforge.net/tracker/?func=detail&aid=2892126&group_id=50884&atid=461324
> , but it needs more TLC before it's ready for prime-time.  Somebody
> (not me) should take the time to get it ready and cleaned up if they
> care.
It's far from being sure that I would have time/skills to do such
patch. If I really need the previously described method, let's see.

It might happen I will just drop-off my bufferevent-based code to get
back to the libevent standard usage. Implementing ssl, openpgp support
using gnutls on a side, symmetric ciphering with libcrypt (or openssl)
on another and last one: dtls with openssl. 

Anyway, thanks for your clarifications!

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