allow symlink tomcat 9

[Giacomo Morri]

Hi, i have a servlet for uploading files inside a path that contains a 
symbolic link, the upload works fine with tomcat 7 but after upgrading 
it to tomcat 9 the servlet give me a java.lang.NullPointerException at 
java.io.File..


I tried setting the allowLinking param to true for the context in this way:



But it doesn't work.

Can you please help me?

Regards,

Giacomo


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

Re: allow symlink tomcat 9

[Holger Klawitter]

Hi,

allowLinking goes into a Resource Element inside Context,
not into Context itself. This changed in Tomcat 8.0 IIRC.

Giacomo Morri wrote (at 2024-04-24 11:42 +0200):
> Hi, i have a servlet for uploading files inside a path that contains a
> symbolic link, the upload works fine with tomcat 7 but after upgrading it to
> tomcat 9 the servlet give me a java.lang.NullPointerException at
> java.io.File..
>
> I tried setting the allowLinking param to true for the context in this way:
>
> 
>
> But it doesn't work.
>
> Can you please help me?
>
> Regards,
>
> Giacomo
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

--
Mit freundlichem Gruß / With kind regards
  Holger Klawitter
--
listen  klawitter  de

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

Re: allow symlink tomcat 9

[Giacomo Morri]

Hi Holger, thanks for your reply.

consider that the symlink is /MTF/Content -> /realt/path/, how can i set 
the Resource element for that path?


Regards,

Giacomo



On 24/04/24 11:55, Holger Klawitter wrote:

Hi,

allowLinking goes into a Resource Element inside Context,
not into Context itself. This changed in Tomcat 8.0 IIRC.

Giacomo Morri wrote (at 2024-04-24 11:42 +0200):

Hi, i have a servlet for uploading files inside a path that contains a
symbolic link, the upload works fine with tomcat 7 but after upgrading it to
tomcat 9 the servlet give me a java.lang.NullPointerException at
java.io.File..

I tried setting the allowLinking param to true for the context in this way:



But it doesn't work.

Can you please help me?

Regards,

Giacomo


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



--
Mit freundlichem Gruß / With kind regards
   Holger Klawitter
--
listen  klawitter  de

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


--

*Cone *
*Essentially digital*
Via Sandro Totti 7A - 60131 Ancona
Tel 071 42 974
Cell 3273458156
eMail giacomo.mo...@cone.it 
Web www.cone.it 


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

Re: allow symlink tomcat 9

[Holger Klawitter]

A plain

  

should suffice.

Giacomo Morri wrote (at 2024-04-24 12:03 +0200):
> Hi Holger, thanks for your reply.
>
> consider that the symlink is /MTF/Content -> /realt/path/, how can i set the
> Resource element for that path?
>
> Regards,
>
> Giacomo
>
>
>
> On 24/04/24 11:55, Holger Klawitter wrote:
> > Hi,
> >
> > allowLinking goes into a Resource Element inside Context,
> > not into Context itself. This changed in Tomcat 8.0 IIRC.
> >
> > Giacomo Morri wrote (at 2024-04-24 11:42 +0200):
> > > Hi, i have a servlet for uploading files inside a path that contains a
> > > symbolic link, the upload works fine with tomcat 7 but after upgrading it 
> > > to
> > > tomcat 9 the servlet give me a java.lang.NullPointerException at
> > > java.io.File..
> > >
> > > I tried setting the allowLinking param to true for the context in this 
> > > way:
> > >
> > >  > > />
> > >
> > > But it doesn't work.
> > >
> > > Can you please help me?
> > >
> > > Regards,
> > >
> > > Giacomo
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> > --
> > Mit freundlichem Gruß / With kind regards
> >Holger Klawitter
> > --
> > listen  klawitter  de
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> --
>
> *Cone *
> *Essentially digital*
> Via Sandro Totti 7A - 60131 Ancona
> Tel 071 42 974
> Cell 3273458156
> eMail giacomo.mo...@cone.it 
> Web www.cone.it 
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

--
Mit freundlichem Gruß / With kind regards
  Holger Klawitter
--
listen  klawitter  de

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

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi  Chris,

Sorry I understood wrongly here with regards to my environment, Let me
start from the beginning. I donot want to use redirect at all. I simply
wanted to force apache tomcat to use both localhost and dns name of the
localhost via url.
I have DNS resollution as below.

server.lbg.com --> localhost

nslookup server.lbg.com (localhost)
Name:server.lbg.com
Address:  192.168.100.20
alias: example.lbg.com

We have working the below urls working:
https://server.lbg.com:8443/towl
https://example.lbg.com:8443/towl --> redirects to
https://server.lbg.com:8443/towl  --> still works --> we have SSL
configured for the same but this SSL certificate doesnot have additional
DNS setup.
But I would need to somehow  access https://example.lbg.com --> which means
I would need to access via 443 here ?

I tried to adding the below to  server.xml as below, but that doesnot seems
to work.


-->

Do i need additional SSL certificate for the https://example.lbg.com  to
make it work ?

Do i need to set up an additional web server for this like apache or nginx
for redirecting requests?

I look forward to your feedback.

Thanks and Best Regards,
Lavanya






On Tue, Apr 23, 2024 at 10:52 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 4/22/24 05:21, lavanya tech wrote:
> > Could you please explain, what you exactly mean ? So here redirect is
> not a
> > solution right ?
>
> Redirecting is fine.
>
> Perhaps you should take a step back and decide: what do you actually
> want, here? You might be trying to solve problem X by applying solution
> Y, and you've already decided that solution Y is correct so you are
> trying to get help with that.
>
> Perhaps ask for help with Problem X?
>
> For example, "I don't want users to have to type the name of my
> application to reach it so I want example.com/ to go to my application
> instead of example.com/myapp/".
>
> Or, "I have multiple domains and I want all of them to redirect to the
> canonical domain example.com and to go to me web application /myapp so
> everything goes to example.com/myapp/".
>
> > "You'd have to use a glob/regex if
> > you wanted to check for [anything and maybe nothing.]example.com."
>
> There is nothing in your configuration or question that suggests that
> the hostname in the request is relevant, but you are making it a
> *requirement* that the request contains a specific Host header. IF you
> don't actually need that, why do you have it?
>
> -chris
>
> > On Fri, Apr 19, 2024 at 3:03 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Ammu,
> >>
> >> On 4/19/24 08:32, lavanya tech wrote:
> >>> Thank you very much. I removed  for example.com as well as
> adding
> >> an
> >>>  in server.xml
> >>> I copied context.xml file
> >>> /git/app/apache-tomcat-10.1.11/webapps/towl/META-INF/context.xml
> >>> Removed < in rewrite.config files.
> >>>
> >>> But still I dont redirect the URL.
> >>
> >> If you have  in server.xml and also your application in the
> >> webapps/ directory, then you will be double-deploying your application.
> >>
> >> Re-name /git/app/apache-tomcat-10.1.11/webapps/towl/ to be
> >> /git/app/apache-tomcat-10.1.11/webapps/ROOT (the capitals are important)
> >> and remove the  element from your server.xml.
> >>
> >> Then start your server and read the logs.
> >>
> >>> *nslookup alias.example.com 
> >>> gives-->Non-authoritative answer:Name: www.example.com
> >>> Address:  192.168.200.10Aliases:
> >> alias.example.com
> >>> *
> >>>
> >>>
> >>> Just to give some information here, *www.example.com
> >>> * has alias* "alias.example.com
> >>> "*
> >>> But https://www.example.com:/example --> works fine with out
> issues
> >> but
> >>> the alias doesnot works (https://alias.example.com)
> >>> So i am not sure if the redirect url helps or if its correct
> >>
> >> Your rewrite configuration says that you have to be using host
> >> "example.com" but your request goes to www.example.com. Your
> >> configuration should only redirect a request such as:
> >>
> >> $ curl -v http://example.com:/something
> >>
> >> HTTP/1.1 301 Moved Permanently
> >> ...
> >> Location: https://www.example.com:/example
> >>
> >> If you make a request like:
> >>
> >> $ curl -v http://www.example.com:/something
> >>
> >> I wouldn't expect a redirect because of your "host" condition. The
> >> "%{HTTP_HOST} example.com" looks at the entire Host header and not just
> >> anything that ends in "example.com". You'd have to use a glob/regex if
> >> you wanted to check for [anything and maybe nothing.]example.com.
> >>
> >> You'd also have to make sure that your application is serving responses
> >> to requests to / which is why I'm recommending you use the ROOT web
> >> application name instead of "towl".
> >>
> >> -chris
> >>
> >>> On Fri, Apr 19, 2024 at 1:21 PM Christopher Schult

Re: allow symlink tomcat 9

[Giacomo Morri]

Thanks. it works fine.

G



On 24/04/24 12:27, Holger Klawitter wrote:

A plain

   

should suffice.

Giacomo Morri wrote (at 2024-04-24 12:03 +0200):

Hi Holger, thanks for your reply.

consider that the symlink is /MTF/Content -> /realt/path/, how can i set the
Resource element for that path?

Regards,

Giacomo



On 24/04/24 11:55, Holger Klawitter wrote:

Hi,

allowLinking goes into a Resource Element inside Context,
not into Context itself. This changed in Tomcat 8.0 IIRC.

Giacomo Morri wrote (at 2024-04-24 11:42 +0200):

Hi, i have a servlet for uploading files inside a path that contains a
symbolic link, the upload works fine with tomcat 7 but after upgrading it to
tomcat 9 the servlet give me a java.lang.NullPointerException at
java.io.File..

I tried setting the allowLinking param to true for the context in this way:



But it doesn't work.

Can you please help me?

Regards,

Giacomo


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



--
Mit freundlichem Gruß / With kind regards
Holger Klawitter
--
listen  klawitter  de

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


--

*Cone *
*Essentially digital*
Via Sandro Totti 7A - 60131 Ancona
Tel 071 42 974
Cell 3273458156
emailgiacomo.mo...@cone.it  
Webwww.cone.it  


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



--
Mit freundlichem Gruß / With kind regards
   Holger Klawitter
--
listen  klawitter  de

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


--

*Cone *
*Essentially digital*
Via Sandro Totti 7A - 60131 Ancona
Tel 071 42 974
Cell 3273458156
eMail giacomo.mo...@cone.it 
Web www.cone.it 

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 4/24/24 07:37, lavanya tech wrote:

Sorry I understood wrongly here with regards to my environment, Let me
start from the beginning. I donot want to use redirect at all. I simply
wanted to force apache tomcat to use both localhost and dns name of the
localhost via url.


When you say "force" what do you mean?

When you say "use both localhost and DNS name" what do you mean?

When you say "localhost" do you mean 127.0.0.1 or "the machine I'm 
logged-into right now"?



I have DNS resollution as below.

server.lbg.com --> localhost


Is that a CNAME record?


nslookup server.lbg.com (localhost)
Name:server.lbg.com
Address:  192.168.100.20
alias: example.lbg.com


That's a weird DNS response. The DNS name "localhost" should *always* 
return 127.0.0.1 for IPv4 and ::1 for IPv6. It shouldn't return 
191.168.100.20.



We have working the below urls working:
https://server.lbg.com:8443/towl
https://example.lbg.com:8443/towl --> redirects to


What do you mean "redirect"? Does it return a 30x response that causes 
the browser to make a new request to \/



https://server.lbg.com:8443/towl  --> still works --> we have SSL
configured for the same but this SSL certificate doesnot have additional
DNS setup.


What SANs are in your certificate? How many certificates do you have?


But I would need to somehow  access https://example.lbg.com --> which means
I would need to access via 443 here ?


I'm so confused. What needs to access what?


I tried to adding the below to  server.xml as below, but that doesnot seems
to work.

 


This will only redirect (HTTP 302) requests to http://yourhost/anything 
to https://yourhost/anything *if the application specifically requests 
CONFIDENTIAL transport*. It doesn't just redirect everything by default. 
If you want it to redirect everything, you'll need to set that up e.g. 
using RewriteValve. There are other options, too.



Do i need additional SSL certificate for the https://example.lbg.com  to
make it work ?


If you don't want your browser to complain, you will need at least one 
TLS certificate that contains every Subject Alternative Name (SAN) for 
every possible hostname you expect to use with this service. You ca do 
it with multiple certificates as well, but a single cert with multiple 
SANs is less work.



Do i need to set up an additional web server for this like apache or nginx
for redirecting requests?


No.

Please stop saying "redirect" because it sounds like you almost never 
mean "HTTP 30x redirect" and that's confusing everything.


I *think* you only need the following:

1. A TLS certificate with the following SANs:

  * server.lbg.com
  * example.lbg.com
  * localhost (you shouldn't do this)

2. DNS configured for all hostnames:

  * server.lbg.com -> A 192.168.100.20
  * example.lgb.com -> A 192.168.100.20

3. Tomcat configured with a single  which is the default virtual 
host. Note that this is the *default Tomcat configuration* and doesn't 
need to be changed from the default.


4. Tomcat configured with your certificate like this:

   
 
   
   
 
   

If your SANs are configured properly, this should allow you to connect 
using any of these URLs:


$ curl https://server.lbg.com/towl/login.jsp

  (returns login page)

$ curl https://example.lbg.com/towl/login.jsp

  (returns login page)

If your application's web.xml contains something like this:

  

  theapp
  /*


  CONFIDENTIAL

  

... then these URLs insecure HTTP URLs should redirect your clients:

$ curl http://server.lbg.com/towl/login.jsp

  (returns HTTP 302 redirect to https://server.lbg.com/towl/login.jsp)

$ curl https://server.lbg.com/towl/login.jsp

  (returns HTTP 302 redirect to https://example.lbg.com/towl/login.jsp)

I don't think you need any use of the RewriteValve unless you want to 
handle sending HTTP 302 redirect responses to insecure requests without 
specifying the CONFIDENTIAL transport-guarantee in your application's 
web.xml file. But I don't see any reason NOT to have that in there.


-chris


On Tue, Apr 23, 2024 at 10:52 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/22/24 05:21, lavanya tech wrote:

Could you please explain, what you exactly mean ? So here redirect is

not a

solution right ?


Redirecting is fine.

Perhaps you should take a step back and decide: what do you actually
want, here? You might be trying to solve problem X by applying solution
Y, and you've already decided that solution Y is correct so you are
trying to get help with that.

Perhaps ask for help with Problem X?

For example, "I don't want users to have to type the name of my
application to reach it so I want example.com/ to go to my application
instead of example.com/myapp/".

Or, "I have multiple domains and I want all of them to redirect to the
canonical domain example.com and to go to me web application /myapp so
everything goes to example.com/myapp/".


"You'd have to use a glob/regex if
you 

Re: Tomcat closes connections on unexpected status codes

[Stefan Ansing]

Op do 18 apr 2024 om 17:42 schreef Mark Thomas :

> On 18/04/2024 15:18, Stefan Ansing wrote:
> > Hi Rémy, Mark,
> >
> >
> >
> > I just want to make sure that we’re understanding each other. I can see
> > that the connection needs to be closed in certain conditions to prevent
> > request smuggling attacks. I certainly don’t want to change that
> behaviour.
> >
> > However, I’m facing a scenario where an application is responding to a
> > valid request (from HTTP perspective), with a valid response using these
> > status codes (more specifically status codes 400 and 500).
>
> If the request is a valid HTTP request then a 400 status doesn't seem
> appropriate to me.
>
> If the server is correctly handling that request to generate the
> response, a 500 status doesn't seem right either.
>
> >
> > I don’t think that in this scenario a request smuggling attack could be
> > executed, or am I missing something?
>
> The main issue is if the original request is invalid HTTP there is no
> way to determine where the next HTTP request starts.
>
> If there is a proxy in the mix then the risks of something going wrong
> tend to go up.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Hi Mark,

I can see your point of view regarding the use of the status codes for
application errors. Unfortunately the HTTP spec doesn't clearly
differentiate the use of status codes for protocol or application errors.
Which is probably why these status codes are now also commonly used for
application errors.

Tomcat (and other servlet containers) currently allow applications to set
any status code, but with the current behaviour of Tomcat this leads to
unexpected side effects for some status codes.

This behaviour makes it so that Tomcat might not be fit for our purpose
(Spring Boot services to services communications). I think the way to
resolve that is to alter the behaviour in Tomcat to differentiate between
protocol and application errors when using these status codes (and to make
this behaviour potentially configurable). I also think that this change
would benefit most users of Tomcat since the behaviour in this scenario is
unnecessary. Would the Tomcat developers be willing to do that?

Stefan

Re: Tomcat closes connections on unexpected status codes

[Christopher Schultz]

Stefan,

On 4/24/24 13:58, Stefan Ansing wrote:

Op do 18 apr 2024 om 17:42 schreef Mark Thomas :


On 18/04/2024 15:18, Stefan Ansing wrote:

Hi Rémy, Mark,



I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that

behaviour.


However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).


If the request is a valid HTTP request then a 400 status doesn't seem
appropriate to me.

If the server is correctly handling that request to generate the
response, a 500 status doesn't seem right either.



I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?


The main issue is if the original request is invalid HTTP there is no
way to determine where the next HTTP request starts.

If there is a proxy in the mix then the risks of something going wrong
tend to go up.

Mark

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



Hi Mark,

I can see your point of view regarding the use of the status codes for
application errors. Unfortunately the HTTP spec doesn't clearly
differentiate the use of status codes for protocol or application errors.
Which is probably why these status codes are now also commonly used for
application errors.

Tomcat (and other servlet containers) currently allow applications to set
any status code, but with the current behaviour of Tomcat this leads to
unexpected side effects for some status codes.

This behaviour makes it so that Tomcat might not be fit for our purpose
(Spring Boot services to services communications). I think the way to
resolve that is to alter the behaviour in Tomcat to differentiate between
protocol and application errors when using these status codes (and to make
this behaviour potentially configurable). I also think that this change
would benefit most users of Tomcat since the behaviour in this scenario is
unnecessary. Would the Tomcat developers be willing to do that?


Assuming it's easy for Tomcat to differentiate between errors generated 
by Tomcat (e.g. "real" 400 responses) and those generated by the 
application, I think this is a good idea. HTTP 400 indicates a protocol 
error, but if the application is generating it, then Tomcat need not 
close the connection.


Theoretically this could also be true for other status codes as well. I 
chose 400 because it means the connection MUST be closed for security if 
Tomcat is the one detecting that there is actually an HTTP protocol 
violation.


-chris

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

Re: Regarding Tomcat url redirection

[lavanya tech]

Hi Chris,

Thanks for the reply.

Local host means the machine i am logged in to server.lbg.com

You are right, example.lbg.com is CNAME record.

I dont have any SAN configured for the certificate. The certificate is
requested for only server.lbg.com

So if i just request new certificate with SAN it should work ? If yes, I
will request for it and follow your steps as below suggested.

Should i use CName record or DNS? Does it make difference?

Thanks,
Lavanya






On Wednesday, April 24, 2024, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Lavanya,
>
> On 4/24/24 07:37, lavanya tech wrote:
>
>> Sorry I understood wrongly here with regards to my environment, Let me
>> start from the beginning. I donot want to use redirect at all. I simply
>> wanted to force apache tomcat to use both localhost and dns name of the
>> localhost via url.
>>
>
> When you say "force" what do you mean?
>
> When you say "use both localhost and DNS name" what do you mean?
>
> When you say "localhost" do you mean 127.0.0.1 or "the machine I'm
> logged-into right now"?
>
> I have DNS resollution as below.
>>
>> server.lbg.com --> localhost
>>
>
> Is that a CNAME record?
>
> nslookup server.lbg.com (localhost)
>> Name:server.lbg.com
>> Address:  192.168.100.20
>> alias: example.lbg.com
>>
>
> That's a weird DNS response. The DNS name "localhost" should *always*
> return 127.0.0.1 for IPv4 and ::1 for IPv6. It shouldn't return
> 191.168.100.20.
>
> We have working the below urls working:
>> https://server.lbg.com:8443/towl
>> https://example.lbg.com:8443/towl --> redirects to
>>
>
> What do you mean "redirect"? Does it return a 30x response that causes the
> browser to make a new request to \/
>
> https://server.lbg.com:8443/towl  --> still works --> we have SSL
>> configured for the same but this SSL certificate doesnot have additional
>> DNS setup.
>>
>
> What SANs are in your certificate? How many certificates do you have?
>
> But I would need to somehow  access https://example.lbg.com --> which
>> means
>> I would need to access via 443 here ?
>>
>
> I'm so confused. What needs to access what?
>
> I tried to adding the below to  server.xml as below, but that doesnot seems
>> to work.
>>
>>  > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> connectionTimeout="2"
>> redirectPort="443" />
>>
>
> This will only redirect (HTTP 302) requests to http://yourhost/anything
> to https://yourhost/anything *if the application specifically requests
> CONFIDENTIAL transport*. It doesn't just redirect everything by default. If
> you want it to redirect everything, you'll need to set that up e.g. using
> RewriteValve. There are other options, too.
>
> Do i need additional SSL certificate for the https://example.lbg.com  to
>> make it work ?
>>
>
> If you don't want your browser to complain, you will need at least one TLS
> certificate that contains every Subject Alternative Name (SAN) for every
> possible hostname you expect to use with this service. You ca do it with
> multiple certificates as well, but a single cert with multiple SANs is less
> work.
>
> Do i need to set up an additional web server for this like apache or nginx
>> for redirecting requests?
>>
>
> No.
>
> Please stop saying "redirect" because it sounds like you almost never mean
> "HTTP 30x redirect" and that's confusing everything.
>
> I *think* you only need the following:
>
> 1. A TLS certificate with the following SANs:
>
>   * server.lbg.com
>   * example.lbg.com
>   * localhost (you shouldn't do this)
>
> 2. DNS configured for all hostnames:
>
>   * server.lbg.com -> A 192.168.100.20
>   * example.lgb.com -> A 192.168.100.20
>
> 3. Tomcat configured with a single  which is the default virtual
> host. Note that this is the *default Tomcat configuration* and doesn't need
> to be changed from the default.
>
> 4. Tomcat configured with your certificate like this:
>
>   SSLEnabled="true">
>  
>certificateFile="/path/to/your/cert.crt"
>certificateKeyFile="/path/to/your/key.pem" />
>
>  
>
>
> If your SANs are configured properly, this should allow you to connect
> using any of these URLs:
>
> $ curl https://server.lbg.com/towl/login.jsp
>
>   (returns login page)
>
> $ curl https://example.lbg.com/towl/login.jsp
>
>   (returns login page)
>
> If your application's web.xml contains something like this:
>
>   
> 
>   theapp
>   /*
> 
> 
>   CONFIDENTIAL
> 
>   
>
> ... then these URLs insecure HTTP URLs should redirect your clients:
>
> $ curl http://server.lbg.com/towl/login.jsp
>
>   (returns HTTP 302 redirect to https://server.lbg.com/towl/login.jsp)
>
> $ curl https://server.lbg.com/towl/login.jsp
>
>   (returns HTTP 302 redirect to https://example.lbg.com/towl/login.jsp)
>
> I don't think you need any use of the RewriteValve unless you want to
> handle sending HTTP 302 redirect responses to insecure requests without
> specifying the

Re: Tomcat closes connections on unexpected status codes

[Adwait Kumar Singh]

> Assuming it's easy for Tomcat to differentiate between errors generated

My PR was based on the assumption that it is easy, since Tomcat always
invokes this method[1] if it's a badRequest.


[1]
https://github.com/apache/tomcat/blob/main/java/org/apache/coyote/http11/Http11Processor.java#L849-L850

On Wed, Apr 24, 2024 at 11:51 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Stefan,
>
> On 4/24/24 13:58, Stefan Ansing wrote:
> > Op do 18 apr 2024 om 17:42 schreef Mark Thomas :
> >
> >> On 18/04/2024 15:18, Stefan Ansing wrote:
> >>> Hi Rémy, Mark,
> >>>
> >>>
> >>>
> >>> I just want to make sure that we’re understanding each other. I can see
> >>> that the connection needs to be closed in certain conditions to prevent
> >>> request smuggling attacks. I certainly don’t want to change that
> >> behaviour.
> >>>
> >>> However, I’m facing a scenario where an application is responding to a
> >>> valid request (from HTTP perspective), with a valid response using
> these
> >>> status codes (more specifically status codes 400 and 500).
> >>
> >> If the request is a valid HTTP request then a 400 status doesn't seem
> >> appropriate to me.
> >>
> >> If the server is correctly handling that request to generate the
> >> response, a 500 status doesn't seem right either.
> >>
> >>>
> >>> I don’t think that in this scenario a request smuggling attack could be
> >>> executed, or am I missing something?
> >>
> >> The main issue is if the original request is invalid HTTP there is no
> >> way to determine where the next HTTP request starts.
> >>
> >> If there is a proxy in the mix then the risks of something going wrong
> >> tend to go up.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> > Hi Mark,
> >
> > I can see your point of view regarding the use of the status codes for
> > application errors. Unfortunately the HTTP spec doesn't clearly
> > differentiate the use of status codes for protocol or application errors.
> > Which is probably why these status codes are now also commonly used for
> > application errors.
> >
> > Tomcat (and other servlet containers) currently allow applications to set
> > any status code, but with the current behaviour of Tomcat this leads to
> > unexpected side effects for some status codes.
> >
> > This behaviour makes it so that Tomcat might not be fit for our purpose
> > (Spring Boot services to services communications). I think the way to
> > resolve that is to alter the behaviour in Tomcat to differentiate between
> > protocol and application errors when using these status codes (and to
> make
> > this behaviour potentially configurable). I also think that this change
> > would benefit most users of Tomcat since the behaviour in this scenario
> is
> > unnecessary. Would the Tomcat developers be willing to do that?
>
> Assuming it's easy for Tomcat to differentiate between errors generated
> by Tomcat (e.g. "real" 400 responses) and those generated by the
> application, I think this is a good idea. HTTP 400 indicates a protocol
> error, but if the application is generating it, then Tomcat need not
> close the connection.
>
> Theoretically this could also be true for other status codes as well. I
> chose 400 because it means the connection MUST be closed for security if
> Tomcat is the one detecting that there is actually an HTTP protocol
> violation.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Regarding Tomcat url redirection

[Christopher Schultz]

Lavanya,

On 4/24/24 15:39, lavanya tech wrote:

Local host means the machine i am logged in to server.lbg.com

You are right, example.lbg.com is CNAME record.


Okay, thanks for clearing that up.


I dont have any SAN configured for the certificate. The certificate is
requested for only server.lbg.com


You will never be able to make a secure request to anything other than 
server.lbg.com without seeing an error. I highly recommend adding the 
other hostname as a SAN to your certificate if you really want to 
support this.


Even if you wanted https://example.lbg.com/whatever to return an HTTP 
302 redirect to https://server.lbg.com/whatever, the user would see a 
certificate hostname mismatch error which is ugly. It's best to make it 
work without users seeing ugly things.



So if i just request new certificate with SAN it should work ? If yes, I
will request for it and follow your steps as below suggested.


Yes, it should.


Should i use CName record or DNS? Does it make difference?


CNAME *is* DNS.

Whenever possible, use hostnames and not IP addresses as SANs. It's more 
flexible that way, and users get to see hostnames instead of IP addresses.


-chris


On Wednesday, April 24, 2024, Christopher Schultz <
ch...@christopherschultz.net> wrote:


Lavanya,

On 4/24/24 07:37, lavanya tech wrote:


Sorry I understood wrongly here with regards to my environment, Let me
start from the beginning. I donot want to use redirect at all. I simply
wanted to force apache tomcat to use both localhost and dns name of the
localhost via url.



When you say "force" what do you mean?

When you say "use both localhost and DNS name" what do you mean?

When you say "localhost" do you mean 127.0.0.1 or "the machine I'm
logged-into right now"?

I have DNS resollution as below.


server.lbg.com --> localhost



Is that a CNAME record?

nslookup server.lbg.com (localhost)

Name:server.lbg.com
Address:  192.168.100.20
alias: example.lbg.com



That's a weird DNS response. The DNS name "localhost" should *always*
return 127.0.0.1 for IPv4 and ::1 for IPv6. It shouldn't return
191.168.100.20.

We have working the below urls working:

https://server.lbg.com:8443/towl
https://example.lbg.com:8443/towl --> redirects to



What do you mean "redirect"? Does it return a 30x response that causes the
browser to make a new request to \/

https://server.lbg.com:8443/towl  --> still works --> we have SSL

configured for the same but this SSL certificate doesnot have additional
DNS setup.



What SANs are in your certificate? How many certificates do you have?

But I would need to somehow  access https://example.lbg.com --> which

means
I would need to access via 443 here ?



I'm so confused. What needs to access what?

I tried to adding the below to  server.xml as below, but that doesnot seems

to work.

  



This will only redirect (HTTP 302) requests to http://yourhost/anything
to https://yourhost/anything *if the application specifically requests
CONFIDENTIAL transport*. It doesn't just redirect everything by default. If
you want it to redirect everything, you'll need to set that up e.g. using
RewriteValve. There are other options, too.

Do i need additional SSL certificate for the https://example.lbg.com  to

make it work ?



If you don't want your browser to complain, you will need at least one TLS
certificate that contains every Subject Alternative Name (SAN) for every
possible hostname you expect to use with this service. You ca do it with
multiple certificates as well, but a single cert with multiple SANs is less
work.

Do i need to set up an additional web server for this like apache or nginx

for redirecting requests?



No.

Please stop saying "redirect" because it sounds like you almost never mean
"HTTP 30x redirect" and that's confusing everything.

I *think* you only need the following:

1. A TLS certificate with the following SANs:

   * server.lbg.com
   * example.lbg.com
   * localhost (you shouldn't do this)

2. DNS configured for all hostnames:

   * server.lbg.com -> A 192.168.100.20
   * example.lgb.com -> A 192.168.100.20

3. Tomcat configured with a single  which is the default virtual
host. Note that this is the *default Tomcat configuration* and doesn't need
to be changed from the default.

4. Tomcat configured with your certificate like this:


  


  


If your SANs are configured properly, this should allow you to connect
using any of these URLs:

$ curl https://server.lbg.com/towl/login.jsp

   (returns login page)

$ curl https://example.lbg.com/towl/login.jsp

   (returns login page)

If your application's web.xml contains something like this:

   
 
   theapp
   /*
 
 
   CONFIDENTIAL
 
   

... then these URLs insecure HTTP URLs should redirect your clients:

$ curl http://server.lbg.com/towl/login.jsp

   (returns HTTP 302 redirect to https://server.lbg.com/towl/login.jsp)

$ curl https://server.lbg.com/towl/login.jsp

   (returns HTT