Re: [Libevent-users] bufferevent with openssl server

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Wed, Feb 2, 2011 at 4:41 PM, Wayne Shao <wshao99@xxxxxxxxx> wrote:
> corrections:
> If I comment out the call bufferevent_openssl_filter_new(), then the client
> can finish handshake, but the server read/write callback not working.
> The code as above (i.e., with the bufferevent_openssl_filter_new() call)
> enters an infinite loop (from the USE_DEBUG build).

Oh, I think see what you're doing wrong!  You're using both
bufferevent_openssl_socket_new() and bufferevent_openssl_filter_new()
on the same socket -- that's not necessary.

bufferevent_openssl_socket_new() wraps SSL around an FD without an
underlying bufferevent.  You can use it when you need to speak SSL on
an underlying fd.  Data is written directly to the fd with SSL_read
and SSL_write.

bufferevent_openssl_filter_new() wraps SSL around another bufferevent.
 You can use it when you have some existing non-socket-based
bufferevent that you need to speak SSL over.  When you write data on
the *filtering* bufferevent, it sets it up so that SSL_read and
SSL_write .   The most common use of bufferevent_openssl_filter_new()
is to use SSL over an IOCP-based bufferevent.

If you wrap an fd in an openssl_socket bufferevent, and then wrap
_that_ bufferevent in an openssl_filter bufferevent, you aren't doing
SSL over the fd; you're doing SSL *inside* SSL over that fd.
Apparently that isn't supported well.

So in other words, there are two reasonable ways to set up SSL on an
fd.  The first way is

    bev = bufferevent_openssl_socket_new( ... fd ...);

And the second is

    bev1 = bufferevent_socket_new(... fd ...);
    bev2 = bufferevent_openssl_filter_new(... bev1 ...);


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