Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

[Isaac Klickstein]

Hello Christopher and Tomcat crew

This TLS protocol violation has been seen to cause issues where a client will 
"linger" with the unclosed connection (usually by default for a minute for each 
webservice call)  until Tomcat timesout the connection and closes the socket 
(this "linger" occurs for clients who more strictly follow the TLS protocol 
than others). For clients that require making many webservice calls to a Tomcat 
configured with the Nio+OpenSSL connector, this can extremely slow down the 
client code. 

While a TCP dump is the most conclusive way to demonstrate the fact that the 
Tomcat server does not return the server's close_notify in response to the 
client's close_notify (when using Nio+OpenSSL), I have a Python script that can 
demonstrate the lack of a server close_notify which I have put after my email 
signature. When the ssl_socket_instance.unwrap() is called, the client sends 
its close_notify, and waits for the close_notify from the server, which for 
Nio+JSSE or APR+OpenSSL, is received promptly, but for Nio+OpenSSL, it never 
arrives and instead an EOF on the socket is received after a timeout is reached 
(on the Tomcat side).

Unfortunately, even an extremely verbose curl will not show enough of the ssl 
communication. You can see the different behaviors by sending "Q" to an openssl 
s_client (built with the ability to use the -debug flag).

openssl s_client -connect : -state -debug <<< "Q"

For the Nio+JSSE or Apr+OpenSSL connector, you see the client close_notify go 
out, followed by the client reading the server's close_notify:

---
DONE
write to 0x5b93da131c40 [0x5b93da13cee3] (31 bytes => 31 (0x1F))
 - 15 03 03 00 1a 83 0b b7-5a e0 00 ad f3 2c 8f 9c   Z,..
0010 - 13 8c 04 8f 57 48 e9 7a-15 a6 ef 9c b0 16 b2  WH.z...
SSL3 alert write:warning:close notify
read from 0x5b93da131c40 [0x5b93da089670] (8192 bytes => 31 (0x1F))
 - 15 03 03 00 1a a0 f4 7f-e5 65 84 ed df 3a a4 ec   .e...:..
0010 - 76 42 bd c6 37 28 cf 21-03 ca 9a dc 9f 5c 23  vB..7(.!.\#
read from 0x5b93da131c40 [0x5b93da089670] (8192 bytes => 0)

For the Nio+OpenSSL connector, you will not see the close_notify returned by 
the server.

---
DONE
write to 0x5714dc99ac40 [0x5714dc9a5ee3] (31 bytes => 31 (0x1F))
 - 15 03 03 00 1a f9 41 8b-50 31 2f 8b 6c 7a 77 c3   ..A.P1/.lzw.
0010 - 12 ca 2d 15 fc 7d 33 cd-ad ee 5c 3d 23 aa 11  ..-..}3...\=#..
SSL3 alert write:warning:close notify
read from 0x5714dc99ac40 [0x5714dc8f2670] (8192 bytes => 0)

You will not see the same "lingering" behavior though because openssl s_client 
will disconnect quickly if the server does not return a close_notify. 

The Python code after my email signature demonstrates the "lingering" behavior 
seen for some clients which wait for the server's close_notify where the client 
"unwraps" the SSL layer from the socket, but keeps the socket open. 

Please let me know if you'd like any more diagnostic information

Best,
Isaac Klickstein

##
# PYTHON EXAMPLE #

# USAGE:
# python3 tomcat_ssl_unwrap_example.py   
 

import sys
import socket
import ssl
import os
import time
import errno
from urllib.parse import urlparse
import base64

def call_manager_app(url,username,password):

ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
ssl_context.verify_mode = ssl.CERT_NONE

parsed_url = urlparse(url)
hostname, port = parsed_url.netloc.split(":") if ":" in parsed_url.netloc 
else (parsed_url.netloc, 443)
credentials = f"{username}:{password}"
encoded_credentials = base64.b64encode(credentials.encode()).decode()

socket_instance = socket.socket(socket.AF_INET, socket.SOCK_STREAM);
#socket_instance.setblocking(True)
ssl_socket_instance = ssl_context.wrap_socket(socket_instance, 
server_hostname=hostname)
ssl_socket_instance.settimeout(1)
ssl_socket_instance.connect((hostname,int(port)))

request = f"GET {parsed_url.path} HTTP/1.1\r\nHost: {hostname}\r\n"
request += "Accept: */*\r\n"
request += f"Authorization: Basic {encoded_credentials}\r\n\r\n"

ssl_socket_instance.send(request.encode())

response_data = b""
while True:
  try:
data = ssl_socket_instance.recv(16384)
  except socket.timeout:
break

  response_data += data

response = response_data.decode()
headers, body = response.split("\r\n\r\n", 1)

print("Headers:")
print(headers)
print("Body:")
print(body)

# Unwrap the socket, and waiting for the server's close notify
ssl_socket_instance.settimeout(120)
socket_instance = ssl_socket_instance.unwrap()
socket_instance.close()




host=sys.argv[1]
port=sys.argv[2]
username=sys.argv[3]
password=sys.argv[4]
# Supply the URL of the Tomcat manager page's /text/list endpoint
#url = "https://localhost:9015/manager/text/list";
#
#
url = "https://"; + host + ":" + port + "/manager/text/list"
print(url)

call_manager_app(url,username,passwor

JNDI connection pool in Tomcat 10.1

[charliedidonato]

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

 

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

 

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

 

Context.xml

   

 

Server.xml

  







   ResourceLink name="jdbc/CodereaperDB"

global="jdbc/CodereaperDB"

auth="Container"

type="javax.sql.DataSource" />   

  



When I deploy my Spring MVC 6 app I get the following in the Tomcat logs

 

Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

... 88 more

Related cause:

org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

 

Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below







 

 

RE: JNDI connection pool in Tomcat 10.1

[charliedidonato]

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

 

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

 

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

 

Context.xml

   

 

Server.xml

  







   ResourceLink name="jdbc/CodereaperDB"

global="jdbc/CodereaperDB"

auth="Container"

type="javax.sql.DataSource" />   

  

When I deploy my Spring MVC 6 app I get the following in the Tomcat logs

 

Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

... 88 more

Related cause:

org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

 

Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below







 

Addendum

The bean above is now defined as







 

 

 

Re: How to resolve 403 forbidden error in Tomcat level

[Christopher Schultz]

Jagadish,

On 8/30/24 10:52, jagadish sahu wrote:> Please find the attached text 
screenshot as you requested.


Okay, I'm going to be perfectly honest: I'm not going to download and 
read all those attachments. That's why I asked for plain-text.


If someone else is willing to go through all that, feel free.

I'm not going to go through a bunch of effort to provide free support.

-chris

On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Jadgish,

This list does not accept image attachments. We are not seeing what you
are posting. Please post text-only.

-chris

On 8/29/24 11:01, jagadish sahu wrote:
 > Hi Team and Christopher,
 >
 > We have attached a 403 error screenshot with full information.
 > The error seems to be generated from Tomcat level.
 >
 > We don't have any changes in the java code and our application is
 > working as expected in Tomcat 9.0.14.
 >
 > After upgrading to latest version Tomcat,we have been facing this
 > issue(Error communicating with web server status:403)
 >
 > Please find attached screenshot for authentication and web.xml.
 >
 > It would be great help if you provide a solution for this.
 >
 > Thanks,
 > Jagadish
 >
 >
 >
 > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
 > mailto:ch...@christopherschultz.net>
>> wrote:
 >
 >     Jagdesh,
 >
 >     On 8/29/24 06:29, jagadish sahu wrote:
 >      > We have tested our application in Apache tomcat 9.0.14. It is
 >     working as
 >      > expected, After upgrading from 9.0.14 to the latest
versions it
 >     is not
 >      > working.
 >      >
 >      >    When we leave the session for 30 mins, we will get some
 >     warning like
 >      > due to an inactive session, you can click on Ok to
continue the
 >     session,
 >      > after clicking Ok we are getting a 403 error message (attached
 >      > screenshot for your reference).
 >
 >     Your screenshot has been stripped from the list. Is this an
 >     application-generated 403 or one from Tomcat?
 >
 >      > The correct functionality is it should not get any error
message,
 >     after
 >      > clicking waring message it should redirect to login page
again,
 >     but in
 >      > the latest version of tomcat its not working, so we are
 >     contacting you
 >      > people.
 >      >
 >      > Please provide a solution/ workaround for this issue.
 >
 >     What kind of authentication are you using? What kind of login
mechanism
 >     are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
 >
 >     Can you post the relevant parts of your web.xml?
 >
 >     -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

AW: How to resolve 403 forbidden error in Tomcat level

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

based on the file "authenticationmethod.docx" there is a context param which 
set the authentication method to the value 0.
The context param is not used by tomcat but by the application.
So, the application seems to take care of authentication and authorization.
0 which stands for "ssa fm security authentication" according to the comment is 
not something, which tomcat provides.

I would suggest contacting the developer(s) or the supplier first to get deeper 
insights about the issue.

Greetings,
Thomas


> -Ursprüngliche Nachricht-
> Von: Rob Sargent 
> Gesendet: Donnerstag, 5. September 2024 04:36
> An: users@tomcat.apache.org
> Betreff: Re: How to resolve 403 forbidden error in Tomcat level
> 
> 
> 
> 
> On 9/3/24 11:22, Christopher Schultz wrote:
> > Jagadish,
> >
> > On 8/30/24 10:52, jagadish sahu wrote:> Please find the attached text
> > screenshot as you requested.
> >
> > Okay, I'm going to be perfectly honest: I'm not going to download and
> > read all those attachments. That's why I asked for plain-text.
> >
> > If someone else is willing to go through all that, feel free.
> >
> > I'm not going to go through a bunch of effort to provide free support.
> >
> > -chris
> Jagadish,
> Chris actually will 'go through a bunch of effort', but not extraneous.
> user-inflicted, unnecessary effort.
> 
> rjs
> >
> >> On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz
> >> mailto:ch...@christopherschultz.net>>
> >> wrote:
> >>
> >>     Jadgish,
> >>
> >>     This list does not accept image attachments. We are not seeing
> >> what you
> >>     are posting. Please post text-only.
> >>
> >>     -chris
> >>
> >>     On 8/29/24 11:01, jagadish sahu wrote:
> >>  > Hi Team and Christopher,
> >>  >
> >>  > We have attached a 403 error screenshot with full information.
> >>  > The error seems to be generated from Tomcat level.
> >>  >
> >>  > We don't have any changes in the java code and our application
> >> is
> >>  > working as expected in Tomcat 9.0.14.
> >>  >
> >>  > After upgrading to latest version Tomcat,we have been facing
> >> this
> >>  > issue(Error communicating with web server status:403)
> >>  >
> >>  > Please find attached screenshot for authentication and web.xml.
> >>  >
> >>  > It would be great help if you provide a solution for this.
> >>  >
> >>  > Thanks,
> >>  > Jagadish
> >>  >
> >>  >
> >>  >
> >>  > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
> >>  >  >>     
> >>      >>     >> wrote:
> >>  >
> >>  >     Jagdesh,
> >>  >
> >>  >     On 8/29/24 06:29, jagadish sahu wrote:
> >>  >      > We have tested our application in Apache tomcat 9.0.14.
> >> It is
> >>  >     working as
> >>  >      > expected, After upgrading from 9.0.14 to the latest
> >>     versions it
> >>  >     is not
> >>  >      > working.
> >>  >      >
> >>  >      >    When we leave the session for 30 mins, we will get
> >> some
> >>  >     warning like
> >>  >      > due to an inactive session, you can click on Ok to
> >>     continue the
> >>  >     session,
> >>  >      > after clicking Ok we are getting a 403 error message
> >> (attached
> >>  >      > screenshot for your reference).
> >>  >
> >>  >     Your screenshot has been stripped from the list. Is this
> >> an
> >>  >     application-generated 403 or one from Tomcat?
> >>  >
> >>  >      > The correct functionality is it should not get any
> >> error
> >>     message,
> >>  >     after
> >>  >      > clicking waring message it should redirect to login
> >> page
> >>     again,
> >>  >     but in
> >>  >      > the latest version of tomcat its not working, so we are
> >>  >     contacting you
> >>  >      > people.
> >>  >      >
> >>  >      > Please provide a solution/ workaround for this issue.
> >>  >
> >>  >     What kind of authentication are you using? What kind of
> >> login
> >>     mechanism
> >>  >     are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
> >>  >
> >>  >     Can you post the relevant parts of your web.xml?
> >>  >
> >>  >     -chris
> >>  >
> >>  >
> >>
> >> -
> >>  >     To unsubscribe, e-mail:
> >> users-unsubscr...@tomcat.apache.org
> >>     
> >>  >      >>     >
> >>  >     For additional commands, e-mail:
> >> users-h...@tomcat.apache.org
> >>     
> >>  >      >>     >
> >>  >
> >>  >
> >>  >
> >>  >
> >> --