[Libevent-users] Re: Cleanly free-ing OpenSSL bufferevents

[Diwaker Gupta <diwaker@xxxxxxxxxxxxxx>]

On Wed, Mar 7, 2012 at 1:24 PM, Diwaker Gupta <diwaker@xxxxxxxxxxxxxx> wrote:
> From http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html:
>
> "Note that when BEV_OPT_CLOSE_ON_FREE is set on a SSL bufferevent, a
> clean shutdown will not be performed on the SSL connection. This has
> two problems: first, the connection will seem to have been "broken" by
> the other side, rather than having been closed cleanly: the other
> party will not be able to tell whether you closed the connection, or
> whether it was broken by an attacker or third party. Second, OpenSSL
> will treat the session as "bad", and removed from the session cache.
> This can cause significant performance degradation on SSL applications
> under load."
>
> Is this still the case? I'm unable to cleanly shutdown the SSL
> connection, regardless of whether I do the lazy shutdown as suggested
> or not. Worse yet, when I do try to do the lazy shutdown, I'm hitting
> segmentation faults. This is on OS X Lion with libevent 2.0.17. The
> backtrace looks similar to:

Update: the segfault was an error on my part. I no longer see crashes
but the other endpoint (which is Java) still sees an unclean shutdown:

javax.net.ssl.SSLException: Inbound closed before receiving peer's
close_notify: possible truncation attack?
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
~[na:1.6]
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1467)
~[na:1.6]
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1435)
~[na:1.6]


> 0   libssl.0.9.8.dylib                  0x00007fff99e4fea7 ssl3_send_alert + 103
> 1   libssl.0.9.8.dylib                  0x00007fff99e4eae8 ssl3_shutdown + 72
> 2   raptor_test                         0x000000010ee65edc disconnect() + 84
>
> Diwaker
> --
> http://maginatics.com



-- 
http://maginatics.com
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.