SSLEngine weird behavior in 11+21?

[Xuelei Fan]

On 7/12/2018 2:39 PM, Simone Bordet wrote:
> 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).
Yes, but normally, the server MUST respond with a close_notify.

> 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.
> 
I will think more about this proposal.

Thanks,
Xuelei