On Wed, Mar 7, 2012 at 1:24 PM, Diwaker Gupta <diwa...@maginatics.com> 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 majord...@freehaven.net with
unsubscribe libevent-users in the body.
