Hello Chris
> What is the "Tomcat Native Client"? I am using the Tomcat Native software (maybe "client" was wrong) available here to build the OpenSSLImplementation: https://tomcat.apache.org/download-native.cgi#2.0.8 I then link to this library using LD_LIBRARY_PATH in the Tomcat's setenv.sh script. > Careful: both the client and the server are always allowed to be powered-off before they respond to any network stimulus. This is what timeouts are for. TLS cannot place any more requirements on the network peers than TCP has already done. I understand that client may terminate the connection after sending its close_notify (and indeed this is what curl does by default) but part of the TLSv1.2 standard is that both sides should send a close_notify (and indeed, the exchange of close_notify's is what you see when Tomcat is using NIO + OpenSSLImplementation and running a curl command) "Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. 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." https://www.rfc-editor.org/rfc/rfc5246#section-7.2.1 > How do you trigger this behavior? Just any request like "curl I have been using the manager app, something like curl --cacert </path/to/ca file> --url 'https://<tomcat host>:<tomcat https connector port>/manager/text/list' --user robot:robotpw but any request to the ROOT/manager/other hosted would do. I have been breaking down the behavior based on protocol=NIO/NIO2/APR and the sslImplementationName JSSE/OpenSSL NIO/NIO2+JSSE = good NIO/NIO2+OpenSSL = bad APR+OpenSSL = good I have TCP dumps for each of these configurations saved and could upload them as well as the configuration of the connectors. Sent with Proton Mail secure email. On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz <ch...@christopherschultz.net> wrote: > Isaac, > > On 8/25/24 13:27, Isaac Klickstein wrote: > > > Hello Tomcat Users > > > > Tomcat Version: 10.1.28 > > OpenSSL version: 3.0.14 > > Tomcat Native Client: 2.0.8 > > > What is the "Tomcat Native Client"? > > > I have configured an HTTPS connector with the > > org.apache.coyote.http11.Http11NioProtocol protocol and the > > org.apache.tomcat.util.net.openssl.OpenSSLImplementation > > sslImplementationName using TLSv1.2 > > > > When I tcpdump any request to this connector, Tomcat is not returning a > > "close_notify" in response to a client's close_notify, and I cannot figure > > out how to force Tomcat to return a close_notify. This seems to be a > > violation of the TLS protocol which demands both sides issue a close_notify. > > > Careful: both the client and the server are always allowed to be > powered-off before they respond to any network stimulus. This is what > timeouts are for. TLS cannot place any more requirements on the network > peers than TCP has already done. > > > Recreating this situation, as far as I can tell, only requires combining > > the Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, > > TLSv1.2 or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior). > > > How do you trigger this behavior? Just any request like "curl > https://example.com/"; ? > > > Other notes, switching the sslImplementationName to > > org.apache.tomcat.util.net.jsse.JSSEImplementation does return a > > close_notify by the server in response to the client's close_notify. > > > > Also, switching back to Tomcat9, and using the > > org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a > > close_notify in response to a client's close_notify. > > > > I have run out of ideas, googling this behavior has turned up nothing > > related to Tomcat (although there does appear to be a similar behavior > > noticed in Netty also using the OpenSSLEngine > > https://github.com/netty/netty/issues/6167) > > > > Any help would be greatly appreciated, I am happy to send along any other > > information that would be informational for diagnostics > > > So... > > Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad > Tomcat 9.0 + APR+tcnative = good > Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ? > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
