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.
-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
