SSLEngine weird behavior in 11+21?

Simone Bordet simone.bordet at gmail.com
Thu Jul 12 21:39:52 UTC 2018


Hi,

On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
> In TLS 1.3 closure, receiving of the close_notify is not required:
>    "... Both parties need not wait to receive a
>     "close_notify" alert before closing their read side of the
>     connection, though doing so would introduce the possibility of
>     truncation."
>
> TLS 1.2 also has similar specification:
>     "It is not required for the initiator
>     of the close to wait for the responding close_notify alert before
>     closing the read side of the connection."
>
> My reading the spec, the peer MUST send the close_notify, but it is not
> required to close the connection.
>
> If the socket cannot be closed until close_notify get received, the
> local may never have a chance to close the socket unless the peer
> agrees.  It does not sound like to me.  The compatibility impact could
> be serious as previous application work in a duplex-close manner.
> 1. start and establish a TLS connection.
> 2. client call close(), and the server will response with a close_notify
> in TLS 1.2. the TLS connection can be closed gracefully.
>
> While for TLS 1.3, #2 does not work if the client calling of close()
> closes the writing side only, and leave the reading side open.
>
> I see the benefits of half-close.  I'm open to hear a better solution to
> take the benefit of half-close and avoid the compatibility issue.

Even in TLS 1.2 you cannot be sure that the server will send the
close_notify (e.g. bad server).
The half close problem is present in TCP, WebSocket, etc. and it's
typically solved with (idle) timeouts.

Client sends the close_notify, then reads, hoping to see the
close_notify from the server; if it does not see it, it closes the raw
socket after a timeout.
The timeout could account for receiving data (i.e. it is reset if
application data arrives), or not.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz


More information about the security-dev mailing list