On Fri, May 26, 2023 at 06:57:09PM +0200, Ilya Maximets wrote: > On 5/25/23 15:21, Simon Horman wrote: > > On Wed, May 17, 2023 at 06:51:04PM +0200, Ilya Maximets wrote: > >> OpenSSL 3.0 enabled alerts for unexpected EOF by default. It supposed > >> to alert the application whenever the connection terminated without > >> a proper close_notify. And that should allow applications to take > >> actions to protect themselves from potential TLS truncation attack. > >> This is how it looks like in the log: > >> > >> |stream_ssl|WARN|SSL_read: error:0A000126:SSL routines::unexpected eof > >> while reading > >> |jsonrpc|WARN|ssl:127.0.0.1:34288: receive error: Input/output error > >> |reconnect|WARN|ssl:127.0.0.1:34288: connection dropped (Input/output > >> error) > >> > >> The problem is that clients based on OVS libraries do not wait for > >> the proper termination if it didn't happen right away. It means that > >> chances to have alerts on the server side for every single disconnection > >> are very high. > >> > >> None of the high level protocols supported by OVS daemons can carry > >> state between re-connections, e.g., there are no session cookies or > >> anything like that. So, the TLS truncation attack is no applicable. > >> > >> Disable the alert to avoid unnecessary warnings in the log. > >> > >> Signed-off-by: Ilya Maximets <i.maxim...@ovn.org> > > > > Reviewed-by: Simon Horman <simon.hor...@corigine.com> > > Thanks for review! I applied this one patch for now. > Backported down to 2.17 since it's an issue with support for OpenSSL 3.0+. > > > Are there any plans to enhance the client-side behaviour? > > It's a bit unclear how to do. SSL_shutdown() may fail with either > WANT_READ or WANT_WRITE. On a nonblocking socket that means that > the application is expected to poll for the file descriptor to become > readable or writable. That means that we either block in the > stream_close(), which may take unpredictable amount of time, or we > need to fail the stream_close() with EAGAIN. At this point we will > have the same dilemma for a library that calls stream_close(). > Currently, we're just force-closing the socket instead.
Thanks, understood. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
