On 29/08/2024 14:05, Christopher Schultz wrote:
Isaac,
On 8/26/24 13:24, Isaac Klickstein wrote:
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.
Aah, okay. You are just using libtcnative on the server side. curl is
the client.
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
That's interesting. When using APR+OpenSSL, the Tomcat code is entirely
responsible for the connection management (e.g. socket, buffers, etc.)
and the crypto (using OpenSSL, of course).
When using NIO+OpenSSL, Java is responsible for the connection
management AND the orchestration of the use of the cryptographic module.
The use of OpenSSL versus some other cryptographic module (e.g. built-in
JSSE) should not affect whether a close_notify is sent. :/
I have TCP dumps for each of these configurations saved and could
upload them as well as the configuration of the connectors.
Is a TCP dump required to observe this behavior, or will e.g. curl -vvv
show it as well?
Is this causing any actual issues in your environment, or are you more
reporting a spec violation that needs to be cleaned-up. It seems to be
that if the client asks the server to close the connection, if the
connection is closed then it's closed whether or not this particular
message is transmitted before termination of the connection.
This should be fixed for the next round of releases.
Mark
-chris
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
---------------------------------------------------------------------
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
