SSLEngine weird behavior in 11+21?

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


On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan < at> 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.


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