RFR: 8328608: Multiple NewSessionTicket support for TLS

[Daniel Jeliński]

On Fri, 14 Jun 2024 22:48:59 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> On the contrary, you are in control of this error. The client OS resets the connection whenever the client closes the socket without reading all available data from the buffers. When the reset is delivered to the server, any data that was not received yet is lost.
>> 
>> The best approach depends on the type of traffic on the connection. If the client is expected to receive data, we can send the NewSessionTicket message as before. If we don't know if the client is expected to receive data, we should delay sending the NewSessionTicket messages until the server actually writes data over the connection.
>> 
>> Sending the NewSessionTicket messages in a thread only adds variability to the mix... without a thread, the messages were guaranteed to be sent before user data. Now the messages can be sent any time before, in the middle, or after user data.
>> 
>> OpenSSL added a function to configure the number of tickets sent automatically after the finished message, and a function to request sending a ticket with the next application data. We should probably do the same.
>> 
>> https://www.openssl.org/docs/manmaster/man3/SSL_new_session_ticket.html
>> 
>> Regarding the failing test, there are 2 options to fix it:
>> - configure the server to send zero tickets, or
>> - receive at least one byte of data on the client side before closing the socket.
>
> Maybe the comment could use some rewording, but I tried to not write whole bug report in a code comment.
> 
> When this was first prototyped as non-threaded, the SocketException occurred because multiple NSTs were sent after the Finished.  The client sent a few messages and closed the connection immediately.  The server, sending the NSTs, runs into the WIndows SocketException when it tries to read the data sent by the client.  Failing to receive the any data or the close_notify.  The variability of the thread allowed the OS to handle the reset correctly and allow the TLS server to receive the close_notify and the data that was sent.
> 
> Waiting for application data to cross the wire may not work for clients that connect and immediately start multiple sessions via resumption to transfer data.  It will not have any tickets to resume from.  Additionally delaying the NST may not mean this problem will go away if the client closes during the NST creation.

I experimented with the code a little, and I didn't observe any failures after inlining the thread code. On the other hand, when I moved the `hc.handshakeOutput.flush();` line inside the loop that sends NewSessionTicket messages, I immediately got a test failure. I forgot that the SSLSocket actually tries to "deplete" the socket before closing it, pretty sure that's the reason why the test didn't fail.

Are you sure the thread is still necessary?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1643086406