Hi, Nick Mathewson wrote: [...]
At this point, I don't recall whether I started adding that feature and didn't finish, or started removing it and didn't finish. :/
I see :)
The SSL clean-shutdown protocol exists so that you can tell the difference between the other side closing the connection correctly, and an attacker forcing the connection to close. For some protocols (like ones that use a close to indicate the end of a data object) this can matter, since otherwise you have no way to tell whether the other side meant to stop sending you data, or whether it got cut off. If you've got one of those protocols, treating a broken connection the same way as a closed connection is a big security hole. You might as well downgrade to SSL2. ;) On the other hand, there should be _some_ way of detecting and reporting a dirty shutdown more detectable. Instead of having an allow_dirty_shutdown flag, maybe there should be a got_dirty_shutdown flag that the user can check when getting an SSL error. (There doesn't seem to be a particular OpenSSL error that gets set in this case, so I don't expect that calling bufferevent_get_openssl_error would do any good.)
Okay, understood. My problem is, that for some clients the TCP connection is closed without the SSL-close protocol being performed beforehand. This is not really an error in my use case, but I can't differentiate between this dirty shutdown and a regular error - both events are reported as "BEV_EVENT_ERROR" to my app. My application-level callback is not triggered from "conn_closed()" as Jardel wrote, but from "be_openssl_eventcb" (my SSL bufferevent is wrapped around a regular bufferevent). To report a dirty shutdown, I suggest passing an event of "BEV_EVENT_ERROR|BEV_EVENT_EOF" to the application (instead of the "BEV_EVENT_ERROR" as is now), so the dirty shutdown can be detected and handled differentely to the clean shutdown (which is "BEV_EVENT_EOF" only). Any objections or should I prepare a patch for this? Best regards, Joachim *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
