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 <[email protected]>
> 
> Reviewed-by: Simon Horman <[email protected]>

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.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to