Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

[Mark Thomas]

On 29/08/2023 21:51, Bhavesh Mistry wrote:

Hi Mark,


curl - -k "https://www.mydomain.com/login; -H  'Host:
attackerHostHeaderInjection.com'


*Why? What problem are you trying to solve?*

Host Header injection is a vulnerability that needs to be addressed., I am
trying to solve if the host is a mismatch between the HOST ( or Authority)
header because links are generated based on the host headers.

For now only way to prevent it is to have a set of allowed hosts and check
against this list.


I'd argue that links shouldn't be being generated based on the Host 
header. You should be able to use relative links. That said...


Given the wide variety of deployment architectures (CDN, reverse procy 
etc) if you do need to use the Host header, validation against a known 
trusted list is probably the most robust option. TLS information may not 
always be available.



Should I update the bug to provide SNI information for the request or
should I file another request ?
See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353


I'd say add it to that issue as the two are closely related.


3) I tried following but again curl - shows it never sent
www.mydomain.com  since it only used to
reach the IP. (This is what Thomas Hoffmann mentioned).
https://serverfault.com/questions/850955/tomcat-virtual-host-to-prevent-improper-input-handling-attack

Thanks for your help so far.


There is another option.

The Host header is used for virtual host selection. If you create a 
valid virtual host for each valid host name (you can have aliases so 
they could all go to the same host) then the default virtual host could 
just have a ROOT webapp that returned you 4xx response of choice.


It is just a different way of implementing an allow list for the Host 
header. The advantage is that it is transparent to the application(s).


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

[Bhavesh Mistry]

Hi Mark,

> curl - -k "https://www.mydomain.com/login; -H  'Host:
> attackerHostHeaderInjection.com'

*Why? What problem are you trying to solve?*

Host Header injection is a vulnerability that needs to be addressed., I am
trying to solve if the host is a mismatch between the HOST ( or Authority)
header because links are generated based on the host headers.

For now only way to prevent it is to have a set of allowed hosts and check
against this list.


Should I update the bug to provide SNI information for the request or
should I file another request ?
See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353

3) I tried following but again curl - shows it never sent
www.mydomain.com  since it only used to
reach the IP. (This is what Thomas Hoffmann mentioned).
https://serverfault.com/questions/850955/tomcat-virtual-host-to-prevent-improper-input-handling-attack

Thanks for your help so far.

Thanks,

Bhavesh

On Tue, Aug 29, 2023 at 1:16 PM Mark Thomas  wrote:

> On 29/08/2023 08:00, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > I am sorry for delayed response.
> >
> > Basically, when request url does not match host header then I would
> reject
> > it.  For example,
> >
> > curl - -k "https://www.mydomain.com/login; -H  'Host:
> > attackerHostHeaderInjection.com'
>
> Why? What problem are you trying to solve?
>
>
> > Based curl -vvv output,  tomcat server does not know host name used
> > www.mydomain.com but Host header is attackerHostHeaderInjection.com.
> >
> > In this case I would like to reject request send 403 or 404.  As you
> > explained that request Line does not have Full URL,
> allowHostHeaderMismatch
> > will not reject.
> >
> > So my idea is using SNI I could get hostname and compare with HOST header
> > or :authority and reject it.
> >
> > Is it possible to request new feature on Tomcat to get or expose SNI name
> > used by client?
>
> That is certainly possible. How likely it is to get implemented depends
> on the justification.
>
> See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: war file timestamp change

[Mark Thomas]

On 29/08/2023 21:28, Loeschmann, Lori wrote:

Hello,

We have a Tomcat application which authenticates via CAS. The application and 
CAS reside on different servers.

We also have an internal audit process that flags files on these servers when 
they change. It's a retroactive review of authorized changes.

When the SSL certificate was updated on the CAS server, the timestamp on the 
application.war and war-tracker files also changed, so these files were 
flagged. The war file was NOT redeployed. There are other application war files 
on the same server whose timestamps did NOT change.  I need to provide a 
justification for the timestamp change, but I can't think of any reason why it 
would have happened by updating the CAS SSL cert on a different server.

I appreciate any insights you may have to share.


There is no reason for any such change in a default Tomcat installation.

All I can suggest is that you review the Tomcat instance and the 
deployed web applications for any  elements that refer 
to the TLS certificate. I can't think of any other reason for the web 
application to be redeployed.


Is there anything in the logs? Anything that updates the war-tracker 
file should also create at least one log message.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

war file timestamp change

[Loeschmann, Lori]

Hello,

We have a Tomcat application which authenticates via CAS. The application and 
CAS reside on different servers.

We also have an internal audit process that flags files on these servers when 
they change. It's a retroactive review of authorized changes.

When the SSL certificate was updated on the CAS server, the timestamp on the 
application.war and war-tracker files also changed, so these files were 
flagged. The war file was NOT redeployed. There are other application war files 
on the same server whose timestamps did NOT change.  I need to provide a 
justification for the timestamp change, but I can't think of any reason why it 
would have happened by updating the CAS SSL cert on a different server.

I appreciate any insights you may have to share.

Thanks,
--
Lori Loeschmann
She/Her
Enterprise Database Administrator Supervisor | Information Services
Medical College of Wisconsin
lloes...@mcw.edu
--
MCW-IS Service Desk
h...@mcw.edu | (414) 955-4357, option 8 | 
servicedesk.mcw.edu
System Status: 
infoscope.mcw.edu/is/support/systemstatus.htm

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

[Mark Thomas]

On 29/08/2023 08:00, Bhavesh Mistry wrote:

Hi Mark,

I am sorry for delayed response.

Basically, when request url does not match host header then I would reject
it.  For example,

curl - -k "https://www.mydomain.com/login; -H  'Host:
attackerHostHeaderInjection.com'


Why? What problem are you trying to solve?



Based curl -vvv output,  tomcat server does not know host name used
www.mydomain.com but Host header is attackerHostHeaderInjection.com.

In this case I would like to reject request send 403 or 404.  As you
explained that request Line does not have Full URL, allowHostHeaderMismatch
will not reject.

So my idea is using SNI I could get hostname and compare with HOST header
or :authority and reject it.

Is it possible to request new feature on Tomcat to get or expose SNI name
used by client?


That is certainly possible. How likely it is to get implemented depends 
on the justification.


See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Mark Thomas]

On 28/08/2023 18:44, Amit Pande wrote:

Oh, sure. So, what would be the best way to get some conclusion on this thread?


Provide a patch for review based on the feedback provided here and in 
the BZ issue.



https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the ticket 
isn't updated for long. Perhaps add comments/ask the folks on user list to vote?


That is more likely to irritate folks rather than encourage them to help 
you progress your patch.


Mark




Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Monday, August 28, 2023 11:20 AM
To: Tomcat Users List 
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



28 Aug 2023 17:11:20 Amit Pande :


Mark,

Just checking - Did this issue get discussed in any of the core
members' meeting?


There are no such meetings. Discussion happens on the mailing lists.

Mark




Thanks,
Amit

-Original Message-
From: Amit Pande
Sent: Monday, July 31, 2023 9:29 AM
To: Tomcat Users List 
Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat

Yes, understood.

Thank you for clarifying. Even I was referring to initial consensus
without any timeline or approach conclusion.

Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Friday, July 28, 2023 2:48 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

On 28/07/2023 19:21, Amit Pande wrote:

Thank you all for the valuable discussion on this topic.

Is it okay to say that we're agreeing to adding proxy protocol
support in Tomcat?


I think that is a little too strong. At this point there is a proposed
approach and no one is objecting but until there is an actual patch to
discuss...

Keep in mind that any committer can veto a change.

My sense is that it should be possible to implement this feature while
addressing any concerns that may be raised but it is not guaranteed.

Mark




Thanks,
Amit

-Original Message-
From: Christopher Schultz 
Sent: Thursday, July 27, 2023 4:13 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

All,

On 7/27/23 12:39, Mark Thomas wrote:

On 27/07/2023 16:27, Jonathan S. Fisher wrote:

On the topic of security, may we consider a trustedProxies setting?


Seems reasonable.


We should probably look at what httpd did for all of this.

-chris


   This
would be an analog to the internalProxies setting on RemoteIpValve.
It would need to be able to function with APR/NIO listening in a
Unix Domain Socket.

I'm not sure if this is super useful, but the goal would be an
added layer of security to prevent Proxy Protocol header injection.

On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas 
wrote:


On 26/07/2023 21:53, Christopher Schultz wrote:

Mark,

On 7/26/23 13:58, Mark Thomas wrote:

I'm not a huge fan of this feature in general. I prefer
supporting features backed by specifications rather than vendor
specific hacks.


I think the PROXY protocol is fairly standard, even if it's not
backed by an RFC. It's published by haproxy, but supported by
nginx,
(obviously) haproxy, AWS, httpd[1], and a whole bunch of others (

https://ww/
w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
s
-
ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
f
a
b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
2
6
0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
V
2
luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpIL
a
0
rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0
).

ACK. That reduces my concerns somewhat.


Well, the reality is that people want to use this in the real
world and this is essentially the only way to do it, barring
coming up with a whole new protocol for the purpose (I'm looking
at /you/ AJP!).


Indeed.


So why not use /the/ protocol that (a) exists and (b) is
supported by every single product that currently supports this
type of thing?


My support for any patch is going to depend on the specifics of
the patch.

In addition to the comments in the BZ
- exposing the data as a request attribute is inconsistent with
other
  mechanisms that solve the same problem (e.g. see
RemoteIpFilter)


+1

The whole point of PROXY is to kind of mix-together the
capabilities of both the RemoteIPFilter/Valve (which uses HTTP
headers for
source-information) and the top-level idea of a Connector
(something that binds to a socket and pushes bytes around).

The confusing thing here is that those two jobs are performed at
relatively different levels in Tomcat at the moment, as I
understand things.


Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
higher level because that is where they sit but the data
originates from the 

Re: Disabling cipher warning

[Mark Thomas]

On 29/08/2023 20:53, David Cleary wrote:

2023-08-29T15:31:57.840-04:00 WARN  [main] o.a.t.u.n.j.JSSEUtil - Some of the 
specified [ciphers] are not supported by the SSL engine and have been skipped: 
[Dozens of OpenSSL ciphers]

We use OpenSSL and moving to Tomcat 10.1.13 has caused an overload of useless 
information to appear when starting Tomcat. Any way to turn this off? Looking 
at the source code, it doesn't look like it.


Specify the ciphers you want to use rather than relying on the defaults.

If you think the message is wrong then please provide your TLS 
configuration so we can try and re-create the issue.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Disabling cipher warning

[David Cleary]

2023-08-29T15:31:57.840-04:00 WARN  [main] o.a.t.u.n.j.JSSEUtil - Some of the 
specified [ciphers] are not supported by the SSL engine and have been skipped: 
[Dozens of OpenSSL ciphers]

We use OpenSSL and moving to Tomcat 10.1.13 has caused an overload of useless 
information to appear when starting Tomcat. Any way to turn this off? Looking 
at the source code, it doesn't look like it.

boolean warnOnSkip = !sslHostConfig.getCiphers().equals(SSLHostConfig.DEFAU.

Thanks
Dave

RE: [EXTERNAL] RE: DataSource Connection pool leak

[Scott,Tim]

Hi all,

Thanks for your responses. I think I've found the problem.

My wrapping class which detects the invocation of the close() method to 
decrement its count is no longer decrementing its count because 
method.getDeclaringClass() has changed from java.sql.Connection to 
java.lang.AutoCloseable.

Is it safe to check for either java.sql.Connection or java.lang.AutoCloseable?

.. or should I just check for the "close()" method invocation, based on the 
fact that I'm not wrapping anything (here) that I shouldn't be counting?

Thanks,
Tim

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

[Bhavesh Mistry]

Hi Mark,

I am sorry for delayed response.

Basically, when request url does not match host header then I would reject
it.  For example,

curl - -k "https://www.mydomain.com/login; -H  'Host:
attackerHostHeaderInjection.com'


Based curl -vvv output,  tomcat server does not know host name used
www.mydomain.com but Host header is attackerHostHeaderInjection.com.

In this case I would like to reject request send 403 or 404.  As you
explained that request Line does not have Full URL, allowHostHeaderMismatch
will not reject.

So my idea is using SNI I could get hostname and compare with HOST header
or :authority and reject it.

Is it possible to request new feature on Tomcat to get or expose SNI name
used by client?

Thanks,

Bhavesh


On Tue, Aug 22, 2023, 3:03 PM Mark Thomas  wrote:

> Tomcat doesn't expose the SNI information.
>
> What problem are you trying to solve here?
>
> Tomcat rejects requests with mis-matched host headers by default and can
> be configured to allow them in 8.5.x, 9.0.x and 10.1.x. You shouldn't
> need to write any extra code for this.
>
> Mark
>
>
> On 21/08/2023 12:59, Bhavesh Mistry wrote:
> >>
> >>
> >> Hi Mark and Thomas,
> >>
> >>
> >>
> >> I understood now that Tomcat does not have information other than HOST
> >> (HTTP 1.1) and :authority: (HTTP2).  So there is no way to check what
> URL
> >> used to connect and headers.
> >>
> >>
> >>
> >> I was wondering if TLS Handshake can provide *SNI can be used for this
> >> purpose**. *
> >>
> >> *Server Name Indication (SNI) is an extension of the TLS protocol. The
> >> client specifies which hostname they want to connect to using the SNI
> >> extension in the TLS handshake. *
> >>
> >>
> >>
> >> *SNI will be the hostname that the browser used to negotiate TLS.  so my
> >> idea is to check SNI vs (host or  *:authority: ) header and if there is
> a
> >> mismatch between host/authority vs. SNI.  I can reject requests and
> throw
> >> 404 status.
> >>
> >>
> >>
> >> Do you know how I can *obtain SNI* from the tomcat HttpRequest object?
> >> What hostname was negotiated with TLS?  Do you think the idea of
> checking
> >> against SNI and *host or  *:authority:  headers?
> >>
> >>
> >>
> >> As always, your opinion and suggestion are always appreciated.
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Bhavesh
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>