Re: List of replaceable parameters in server.xml, context.xml, etc.

[Mark Thomas]

On 24/02/17 22:11, Christopher Schultz wrote:
> All,
> 
> Is there a list of standard properties that are available for
> replacement in these files? I'm aware of catalina.home and
> catalina.base, and I believe that *any* system property can be used if
> explicitly set (e.g. in bin/setenv.sh).
> 
> But is there a list of those that Tomcat provides out of the box for
> itself? Doing a grep for "-D" in bin/catalina.sh provides some that
> are set on JVM launch. Are there any others that are added after the fac
> t?

Tomcat sets a few properties (grep for System.setProperty) but they are
generally intended for other uses than property replacement.

Mark

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

Re: Getting application root path before servlet is initialized?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 2/24/17 12:37 PM, Martin Knoblauch wrote:
> On Fri, Feb 24, 2017 at 6:00 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Martin,
>> 
>> On 2/21/17 8:31 AM, Martin Knoblauch wrote:
>>> Hi,
>>> 
>>> is there a way to find the absolute path of the application
>>> root before the servlet is initialized?
>>> 
>>> Alternatively: is there a way to defer the initialization of a 
>>> datasource until the servlet is initialized?
>>> 
>>> Background: I have extended 
>>> "org.apache.tomcat.jdbc.pool.DataSourceFactory" to
>>> automatically set credentials so that they are not stored in
>>> the "Catalina/localhost/XXX.xml" file. Instead they are taken
>>> from encrypted values in a file below the application root.
>>> Works fine if I know that path at "createDataSource" time.
>> 
>> Where are you configuring your ? In conf/server.xml or
>> in your application's META-INF/context.xml file?
>> 
> 
> conf/Catalina/localhost/XXX.xml

Good. If your custom DataSource can accept custom properties, then you
can add one with a dynamic path, like this:



In your code, you read that path and use it.

>>> In order to avoid hard coding that path, I need a programmatic
>>> to find that value. Unfortunately the datasource is initialized
>>> before the servlet, so "getRealPath()" is not working yet.
>> 
>> getRealPath is a bad idea. Also, your DataSources will be 
>> fully-configured before any servlets are initialized, so it's too
>> late.
> 
> Correct :-( That is the problem I need(ed) to solve. Given enough 
> assumptions about the deployment rules for this app, I was able to
> find a reliable way to deduce the AppRoot. But the fact that the DS
> is initialized before the/any servlet is still ugly.

You can use system property replacement in your Tomcat deployment
descriptor (META-INF/context.xml, or in your case
conf/Catalina/localhost/XXX.xml) to locate the file relative to
CATALINA_BASE like this:



- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsK//AAoJEBzwKT+lPKRYU0QP/30vNxE+FBStms0J8TA0aC6w
ZPyA53htgBnMFbKEPt6zmSx3pYtdRE866I3IXiq7c8j9Fcy3c6img9ohVW9cwx+q
Id8Gc1MqHNk1dMxSUpQN+YBVTg+N6hEQshocxcIAKJ7vzind1dUdJgnGLowZBb2G
OCLbr8BqdhBz97Cw+B2tv+P310ez0RS1ZInbi0cTr7RHkFsUYPFL8Z86668ZYJGA
HO5cOEv1+a2W6kIiVEcyDzAo65y6dlp8/Nn/7J00mufT241F/haON7KHWyGXSYKU
C19zYFWjhbZWENrTO2gOSPumib12RgUs45mVbOzYKnMDAZxzMQETgtX31hJE9Pxt
J++OLvF+OwdFwveBNNNpJOpAcmzmX40RSKp+wez+nLftvI6aKXTXKer8zIiYur9Y
nu4cyj4Hjb1tFOFsl2+2jdhFjHb3dFJ/76qylMNgfpsjw1VYHiUlU6QM6G7I2xZd
AROO6Nk4uPElPzl4u83pJ0knD7CKIV8oTE7H5/7pXgFU1SmUq+S/QLhN9Nvq2XKi
Sykr/lxJWkDIpT1w3mRUhcnREODt4Uzp/0dpuD1i+oSrz8hIcAvZMqgAh8F1nSOQ
d8N0TnrJ2w0j63R0mDfoNiRg+2Olxwy0J+xQgNimSC8rOPahu8msatUkXg/JtFDX
z4DR8aawD45uJ+tO18Tr
=bMSR
-END PGP SIGNATURE-

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

List of replaceable parameters in server.xml, context.xml, etc.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Is there a list of standard properties that are available for
replacement in these files? I'm aware of catalina.home and
catalina.base, and I believe that *any* system property can be used if
explicitly set (e.g. in bin/setenv.sh).

But is there a list of those that Tomcat provides out of the box for
itself? Doing a grep for "-D" in bin/catalina.sh provides some that
are set on JVM launch. Are there any others that are added after the fac
t?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsK+tAAoJEBzwKT+lPKRYO7sP/37mXj9/dZP+iSGGEcBPDGHY
rKlNe6XsTJgTCaCCMc85CKvX0x8iaizHxQmBcevBTC7HKH5BA1Npfd95oFwmwCoL
JaYDOO21AydiSiujJZHaWP8qLJkB3Vrtx4Z+wTh6XAFQ9oHwJ/s16s3kuxr1cKgI
UQf9BxeITOhUYfP/BSfA9blouC38GJx7sH6hmgqp3cezysuvxy8y6XYRKvZM2NYN
xhiovH0XzCsYlbfe1ZdVTn6xyHQihJqAt6kT9RzmNHezjEVB48b9OVfd6gbTMwu9
j0iSRLIJTqL39oW/nIO4Wk34IIxXLhb6UUBklilIyXqldY6O6VJnOl3scPi+20ct
1Qzjr4rlsZC4389Jk+mpJoKtQDMeG/PD6zVZb3TPdKLLFG+CvqxsUB6xyTonVTJu
wg2FYCq1jeSTMqvxRJmxyPXKBDVgvFcXidQjwBBuRxSiVn8SrAHskznVui494zgg
N0cRiUvTdWE7D9T4Hy/FH/F+boqbxJh7aBogBMkul+AqXRNHr2vF57xDCgVDZf1y
bOqUOoi831lIq92uAyBvt7Kak5+65XoHkV56OfBq7s9pHAVFwOFLT8P2XTeoYAlh
F2SqPHUE+vsAcvsHulHu54qXOZYA7LckW/MwQ/EO81XMpryj2CDX8MUk9Y+18jFB
hZH+iEFF1hOag0m96cRu
=gr+/
-END PGP SIGNATURE-

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

Re: Getting application root path before servlet is initialized?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 2/24/17 12:32 PM, Martin Knoblauch wrote:
> On Fri, Feb 24, 2017 at 6:06 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Martin,
>> 
>> On 2/22/17 5:19 AM, Martin Knoblauch wrote:
>>> On Tue, Feb 21, 2017 at 8:55 PM, Mark Thomas
>>>  wrote:
>>> 
 On 21/02/2017 13:31, Martin Knoblauch wrote:
> Hi,
> 
> is there a way to find the absolute path of the
> application root before the servlet is initialized?
> 
> Alternatively: is there a way to defer the initialization
> of a datasource until the servlet is initialized?
> 
> Background: I have extended "org.apache.tomcat.jdbc.pool.
 DataSourceFactory"
> to automatically set credentials so that they are not
> stored in the "Catalina/localhost/XXX.xml" file. Instead
> they are taken from encrypted values in a file below the
> application root. Works fine if I know that
 path
> at "createDataSource" time.
 
 And the decryption key for that file is stored where?
 
 https://wiki.apache.org/tomcat/FAQ/Password
 
 
>>> Thanks for link. It clearly reflects my opinion as well
>> 
>> Good. At least you know this is all a farce.
>> 
> 
> Not sure I'd call it a farce, but yes this is all hide and seek
> 
> 
>> 
>>> , but the customer demand is:
>>> 
>>> - no plain-text credentials (Big multinational company
>>> security policies - fight them if you need the fun). And yes,
>>> this is all about making auditors happy
>> 
>> Obviously, you are still failing this requirement. The only 
>> requirement you are satisfying is "no plain-text credentials in
>> a standard configuration file". What you are doing is moving the 
>> plain-text credentials into a non-standard configuration file.
>> 
>> 
> No, there are no plain-text credentials stored anywhere. They are
> stored crypted with an api to decrypt them.

... and the keys passed-into the API.

> But of course
> 
> - how good is the decryption key protected

It must be plain-text somewhere. You can obscure it all you want, but
you are just buying yourself a small amount of time.

> - what about the in-memory copy of the credentials once the
> datasource has been initialized

They are always available, since the connection-pool manager may have
to open a new connection at any moment.

> - what about snooping them on the network when the DB connection is
> built. OK. We are using SSL there.

TLS should do your job, here. Of course, nobody needs your credentials
if they can sniff the network traffic. So TLS is important to ensure.
I would even require it as a condition of all non-local connections.

> This makes most auditors and penetration testers sufficiently
> happy.
> 
> 
>>> - minimize the locations where credentials are stored. This is 
>>> only lightly related to the decrypt issue. Having to store 
>>> identical stuff in more than one place is opening up all other 
>>> sorts of practical issues
>> 
>> This is a reasonable requirement, as it helps reduce the attack 
>> surface. But when the attack surface is "a file on the disk",
>> getting owned means you are owned, regardless of the location of
>> the file(s).
>> 
>> As for the location of the secrets file, would it be possible to
>> store it *outside* of the web application's on-disk footprint?
>> That will in fact make you more secure. Let's say for example
>> that a vulnerability exists in the DefaultServlet, or one of your
>> application's own servlets. It allows path-traversal or whatever.
>> A file living in your application will then be potentially
>> remotely-fetchable :( If you move that file outside of the web
>> application, you have a better change of preventing that kind of
>> thing.
> 
> There is no secrets file. As I said before - the app has obfuscated
> the key deep in the source...

So the secrets file is called MySecrets.class :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsK2qAAoJEBzwKT+lPKRYQbEP/RamJmHnm+G3Pz4hCprsGrqA
n6xCcdCyU2jMqHpIdnhVHNLoMAYmeRDHpetn4GTWLff3TNjcljRfEdmPggQOy4Ei
bE7sq/1A79TS/Y+Xo2/QuYdMFHm0F0nAuyMsVdJ/XzoMuQtNlWjq3SlZQcYzkzGC
aofnpd7FjtePrCyBeSQfyAZ+lep8Tjvsg0tzH03eUMsgM6RJ5E0jcloBbqm7hsVP
oo6oS4cwts/Vq+PnNbmTiQaQA/wQWEvZRLQctflyeRYjvcLr5/ABJ1iBJc6tdTXA
zY8qd8Zx2DMOdsSvVLSdjATm1YvT+ucQl5O1TJ6AXJKRa+f76eM17kr7fafOyG4U
IeQgCwS9/q0UB4HH14bvsb9jhSXup3j5aNHMGgI6xyZtbaRoI8jrwQvGd/KNXDjQ
jXtr7xBBWFTxE6r3bk5afJvHC+A3n0KlBySoQ4S0Wg6B37QFW+ThU4sTpOKrH/Bs
NiM0r+qEDXA255O3LuvYJJUYPBGSL0AD7UaV14LWiFN9iPgWZyB633JW8Ngnm5ZO
9Ogp0udT4zjuZc2Q20MNuheR9LFKDcji0K92STGbhhHhsk/TBJBrijq2ApIAkeSH
CDU5jIVfzjwd5vVXzlGc44s2vIbMxaok6grbEl5fWvthqlO3kYfgozHS1k43qvFb
hPiAqnZv9E+e/fBqME4u
=uY5I
-END PGP SIGNATURE-

-
To 

Propagation of Subject with JAAS and SecurityManager enabled

[kommersz]

Hi,

I am playing around with the following things:
 - X.509 authentication
- Security Manager enabled
- Custom JAAS login module via JAASRealm

My custom JAAS login module properly propagates a javax.security.auth.Subject 
instance at commit() back. My aim is to use this javax.security.auth.Subject as 
a basis for authorization checks - expect 
org.apache.catalina.security.SecurityUtil to take this over.
Curiously, by the time it comes to 
org.apache.catalina.security.SecurityUtil.execute(...) applying 
Subject.doAsPrivileged, it is done with another javax.security.auth.Subject 
instance.

Having looked a bit into it what is happening, I see the followings
- org.apache.catalina.security.SecurityUtil.execute(...) looks for a subject to 
be present in the session object with key Globals.SUBJECT_ATTR 
("javax.security.auth.subject").
- if it is not present, it will create a new blank Subject containing only one 
Principal, which is extracted from the requests 
org.apache.catalina.connector.Request object (and store it in the session 
afterwards under Globals.SUBJECT_ATTR)
- org.apache.catalina.connector.Requests setUserPrincipal(Principal 
principal) sets the session object with key Globals.SUBJECT_ATTR to a newly 
initialized javax.security.auth.Subject with a single Principal. 

Summary: to me it seems that the mechanism currently used to propagate the 
Subject to org.apache.catalina.security.SecurityUtil.execute(...) _always_ 
creates a new empty Subject and adds a single user principal into it.

Questions:
- do I miss something about Subject propagation?
If not:
- is this intentionally planned like this?
- would it not make sense to allow Subjects to be propagated to SecurityUtil 
1:1 from JAAS Login modules to be used as the Subject for privileged execution?

Btw, I am on 7.0.68, but seems that the relevant pieces of code has not been 
changed by 7.0.75 - most recent version checked. 

Thank you for any help upfront!

Regards,
Gabor
 
 

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

Resolved, Re: Connection reset while trying to access a web service running under Tomcat

[James H. H. Lampert]

On 2/24/17, 8:56 AM, Christopher Schultz wrote:


You need to enable logging at a lower level than this if a TLS
connection is failing. Tomcat doesn't get any indication that anyone
even tried to make a connection if the TLS handshake fails.

. . .

Dear Mr. Schultz (and all others who responded):

As it turns out, it *WAS* still a problem at the customer's end. They 
did something else (they didn't say *what*) and now, it's working just fine.


Thanks for getting back to me, though.

--
JHHL


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

Re: Getting application root path before servlet is initialized?

[Martin Knoblauch]

On Fri, Feb 24, 2017 at 6:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 2/21/17 8:31 AM, Martin Knoblauch wrote:
> > Hi,
> >
> > is there a way to find the absolute path of the application root
> > before the servlet is initialized?
> >
> > Alternatively: is there a way to defer the initialization of a
> > datasource until the servlet is initialized?
> >
> > Background: I have extended
> > "org.apache.tomcat.jdbc.pool.DataSourceFactory" to automatically
> > set credentials so that they are not stored in the
> > "Catalina/localhost/XXX.xml" file. Instead they are taken from
> > encrypted values in a file below the application root. Works fine
> > if I know that path at "createDataSource" time.
>
> Where are you configuring your ? In conf/server.xml or in
> your application's META-INF/context.xml file?
>

conf/Catalina/localhost/XXX.xml


>
> > In order to avoid hard coding that path, I need a programmatic to
> > find that value. Unfortunately the datasource is initialized before
> > the servlet, so "getRealPath()" is not working yet.
>
> getRealPath is a bad idea. Also, your DataSources will be
> fully-configured before any servlets are initialized, so it's too late.
>
>
 Correct :-( That is the problem I need(ed) to solve. Given enough
assumptions about the deployment rules for this app, I was able to find a
reliable way to deduce the AppRoot. But the fact that the DS is initialized
before the/any servlet is still ugly.

Thanks
Martin

Re: Getting application root path before servlet is initialized?

[Martin Knoblauch]

On Fri, Feb 24, 2017 at 6:06 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 2/22/17 5:19 AM, Martin Knoblauch wrote:
> > On Tue, Feb 21, 2017 at 8:55 PM, Mark Thomas 
> > wrote:
> >
> >> On 21/02/2017 13:31, Martin Knoblauch wrote:
> >>> Hi,
> >>>
> >>> is there a way to find the absolute path of the application
> >>> root before the servlet is initialized?
> >>>
> >>> Alternatively: is there a way to defer the initialization of a
> >>> datasource until the servlet is initialized?
> >>>
> >>> Background: I have extended "org.apache.tomcat.jdbc.pool.
> >> DataSourceFactory"
> >>> to automatically set credentials so that they are not stored
> >>> in the "Catalina/localhost/XXX.xml" file. Instead they are
> >>> taken from encrypted values in a file below the application
> >>> root. Works fine if I know that
> >> path
> >>> at "createDataSource" time.
> >>
> >> And the decryption key for that file is stored where?
> >>
> >> https://wiki.apache.org/tomcat/FAQ/Password
> >>
> >>
> > Thanks for link. It clearly reflects my opinion as well
>
> Good. At least you know this is all a farce.
>

Not sure I'd call it a farce, but yes this is all hide and seek


>
> > , but the customer demand is:
> >
> > - no plain-text credentials (Big multinational company security
> > policies - fight them if you need the fun). And yes, this is all
> > about making auditors happy
>
> Obviously, you are still failing this requirement. The only
> requirement you are satisfying is "no plain-text credentials in a
> standard configuration file". What you are doing is moving the
> plain-text credentials into a non-standard configuration file.
>
>
No, there are no plain-text credentials stored anywhere. They are stored
crypted with an api to decrypt them. But of course

- how good is the decryption key protected
- what about the in-memory copy of the credentials once the datasource has
been initialized
- what about snooping them on the network when the DB connection is built.
OK. We are using SSL there.

This makes most auditors and penetration testers sufficiently happy.


> > - minimize the locations where credentials are stored. This is
> > only lightly related to the decrypt issue. Having to store
> > identical stuff in more than one place is opening up all other
> > sorts of practical issues
>
> This is a reasonable requirement, as it helps reduce the attack
> surface. But when the attack surface is "a file on the disk", getting
> owned means you are owned, regardless of the location of the file(s).
>
> As for the location of the secrets file, would it be possible to store
> it *outside* of the web application's on-disk footprint? That will in
> fact make you more secure. Let's say for example that a vulnerability
> exists in the DefaultServlet, or one of your application's own
> servlets. It allows path-traversal or whatever. A file living in your
> application will then be potentially remotely-fetchable :( If you move
> that file outside of the web application, you have a better change of
> preventing that kind of thing.
>

There is no secrets file. As I said before - the app has obfuscated the key
deep in the source...

Thanks
Martin

-- 
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de

Re: "mime-mapping" and Content-Type

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ryan,

On 2/20/17 10:38 AM, Ryan Yohnk wrote:
> I’ve come across a problem for which the “mime-mapping” element
> would be a good solution. Specifically I have a web application
> who’s source I can’t change, it’s not returning a specific
> Content-Type header and I’d like to start utilizing compression
> based on the mime-type.
> 
> Durning my investigation I created a trivial web app for testing
> but was unable to get the mime-type specified in the mime-mapping
> applied to requests sent to the specific extension. This was with
> Tomcat 8.0.33. The details can be found below or at the stack
> overflow post here: 
> http://stackoverflow.com/questions/42261607/tomcat-8-0-mime-mapping-co
ntent-type.

Just
> 
so you know, the mime-mapping only applies to resources served by
the DefaultServlet. If the application is accepting a request to e.g.
/my-file.txt, then the content-type isn't automatically being set to
"text/plain" by Tomcat... it's up to the servlet to do that.

The Mime-Mappings are available to servlets, but it's pretty rare for
a custom servlet to bother actually using them.

> As noted in the SO post, I can see that 
> StandardContext:addMimeMapping() is being called with my specific 
> mapping during initialization. But I’m never seeing the backing 
> mimeMappings called from there.
> 
> I’ve seen quite a few online posts on this topic but can’t seem
> find any official documentation for 8+. Is this feature something
> that’s still supported? If so, is there something I’m overlooking
> in my test or configuration?
> 
> Any light you guys can shine on the subject would be greatly 
> appreciated.
> 
> Thanks! Ryan
> 
> 
> 
> Servlet:
> 
> public class SimpleServlet extends HttpServlet { protected void 
> doGet(HttpServletRequest req, HttpServletResponse resp) throws 
> ServletException, IOException { IOUtils.write("Hello There!", 
> resp.getOutputStream()); resp.setStatus(202); } }
> 
> web.xml:
> 
> http://java.sun.com/xml/ns/javaee; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;>
> 
>  SimpleServlet 
> com.jamf.swa.SimpleServlet
> 
> 
>  SimpleServlet 
> *.swa 
> 
>  swa 
> text/rtf;charset=UTF-8 
> 
> 
> 
> cURL request:
> 
> curl --trace-ascii - http://localhost:8080/testing.swa == Info: 
> Trying ::1... == Info: TCP_NODELAY set == Info: Connected to 
> localhost (::1) port 8080 (#0) => Send header, 89 bytes (0x59)
> : GET /testing.swa HTTP/1.1 001b: Host: localhost:8080 0031: 
> User-Agent: curl/7.51.0 004a: Accept: * /* 0057: <= Recv header,
> 23 bytes (0x17) : HTTP/1.1 202 Accepted <= Recv header, 27
> bytes (0x1b) : Server: Apache-Coyote/1.1 <= Recv header, 20
> bytes (0x14) : Content-Length: 12 <= Recv header, 37 bytes
> (0x25) : Date: Wed, 15 Feb 2017 22:37:17 GMT <= Recv header, 2
> bytes (0x2) : <= Recv data, 12 bytes (0xc) : Hello There!
> Hello There!== Info: Curl_http_done: called premature == 0 == Info:
> Connection #0 to host localhost left intact

Yup: you are making a request to a custom servlet that doesn't do
anything with the MIME mappings.

You said you don't want to modify the source... what about *adding* to
it? Would it be okay to write a Filter and add it to the configuration
of the application? That is a very easy thing to do, and you can add
whatever headers you want for whatever reason.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsGl1AAoJEBzwKT+lPKRYCkwP/i1lBjt3v6zsdYMWafdCNoTj
cIlYc3P6AAafDED7/Sf/8H3RQ1uOrp9n0DuM6hnjrh55ptv/VoAGDY3836ONSQ8S
ldWDJOipeTFW2byOeWc9fjT9+AJJ0B/3BidjUFgmljsyCw+f71ZYvHt2ECXNoXOO
T1nQG/OqqTnRZ54UZ1/d/PyZJSbEw1YHmS3f5DFfhtDHjgOS2bBsuQvSvX2XCUjK
lEcdCTbP1XaIU2jMIlRLF///i1Ytz2OsS12byt+tnotRC0MIVr1ST8Je6yvgaBLw
JHnStDdSJW4yFiy9aW8L54qChmdr1KCybavsnEHJKKgc7R5n+2qY2wDm4RwXl8b3
Aqyc9A5ELGhL/xn+kf3w4sC41yEAUXitYJyNkg33o69XoV+nxLfmuWTEqANwh5K+
RRsDQXTnnNZx9fewHpg2+/OnWUkLxaCtqfInU907c7AyXnuJ1jhWD9tBMXFy1SBA
jCQfj7U6hL/LsjQRPdpl0I0qpQ/KrxuCdBLCWwl28xwdXu21enlCV6ZvgHe3z6Vc
HVTc3dB/QbFNHJ9Qm1tbemOPTfR8rr2rycu3dcEXNlmwAwZ3yPASQGPnILZnxDyD
q1VmitMK3vfvoErXfMJ8yrPluQXRMus3f6Guu5k3gIYA/y9a+FUmUZ3pMPaTl69M
wLc5oAFEfPZcqfIdZlRd
=TfdZ
-END PGP SIGNATURE-

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

Re: Getting application root path before servlet is initialized?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 2/22/17 5:19 AM, Martin Knoblauch wrote:
> On Tue, Feb 21, 2017 at 8:55 PM, Mark Thomas  
> wrote:
> 
>> On 21/02/2017 13:31, Martin Knoblauch wrote:
>>> Hi,
>>> 
>>> is there a way to find the absolute path of the application 
>>> root before the servlet is initialized?
>>> 
>>> Alternatively: is there a way to defer the initialization of a 
>>> datasource until the servlet is initialized?
>>> 
>>> Background: I have extended "org.apache.tomcat.jdbc.pool.
>> DataSourceFactory"
>>> to automatically set credentials so that they are not stored
>>> in the "Catalina/localhost/XXX.xml" file. Instead they are
>>> taken from encrypted values in a file below the application
>>> root. Works fine if I know that
>> path
>>> at "createDataSource" time.
>> 
>> And the decryption key for that file is stored where?
>> 
>> https://wiki.apache.org/tomcat/FAQ/Password
>> 
>> 
> Thanks for link. It clearly reflects my opinion as well

Good. At least you know this is all a farce.

> , but the customer demand is:
> 
> - no plain-text credentials (Big multinational company security 
> policies - fight them if you need the fun). And yes, this is all 
> about making auditors happy

Obviously, you are still failing this requirement. The only
requirement you are satisfying is "no plain-text credentials in a
standard configuration file". What you are doing is moving the
plain-text credentials into a non-standard configuration file.

> - minimize the locations where credentials are stored. This is
> only lightly related to the decrypt issue. Having to store
> identical stuff in more than one place is opening up all other
> sorts of practical issues

This is a reasonable requirement, as it helps reduce the attack
surface. But when the attack surface is "a file on the disk", getting
owned means you are owned, regardless of the location of the file(s).

As for the location of the secrets file, would it be possible to store
it *outside* of the web application's on-disk footprint? That will in
fact make you more secure. Let's say for example that a vulnerability
exists in the DefaultServlet, or one of your application's own
servlets. It allows path-traversal or whatever. A file living in your
application will then be potentially remotely-fetchable :( If you move
that file outside of the web application, you have a better change of
preventing that kind of thing.

If the file is located outside of the application, you may be able to
reference it directly -- e.g. /etc/secrets/my-application-secrets.conf

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsGgKAAoJEBzwKT+lPKRYzeEQAKV4Gn9E2ymPQpY4sQQqmuNW
hTUVT2Wc/yIO5Cy7leyrDCTKIwPgasavmuF1c4qjno+i7Q9utL58s7XkeUYUpJTf
6y/Ry+XcCFtS493YAhNl64oJnAt5++vKSO7/b97qe2NaHbOfAGOH8IsNlyjelPPw
N0an2Z8sjkyTQ+x7Anic239coEUf0wAKJ/lczI4KhkugHiz3JCwUQl/YqKRsgJZ7
UQQbX4lO/8qib+8Bcqgn1OoAf64bYN8J2/7/yB4+fEmEUeRc5NTK3knePDX2VtTr
r62iRlh0a8YHHgEvgPNPwn4CwGF3gBYuv2Wfo6+g8exQpRBMwAIkyW7+FyulALGr
+cCBn1X+9jiY8YZBqJxdweb02kotYga1rTUHAorguGHzGryCrC7KiVy5CdXC9aYj
wTRlEKauXH+G878M0iJw1oMJlEiAOO+5UIW/Jb9T8Z8nhcpgRwb50O4IpwKU84Gn
dMDhkUc6WL2almtlD9gu3/Uzbju41NzZWhEdXcfSr/JafsoiEBl2c1wAP/tgmzSu
GvQnT1OHBpbNcqCOsKfGAi8B/HGwVHuaUCjVuTX8qfVf3EcZ1Y8A4COGLITorawr
AbPgnHrTM9a16o+50Jzzylv4FUieBJlfehMgfRKhlEWPsBkeT0bfnBZGeXtnHsu6
4MzpshE1LrK5LI+5fvEJ
=xzqv
-END PGP SIGNATURE-

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

Re: Strange URL rewrite when reverse proxy with Apache HTTP Server

[Aaron Gray]

I found the old notes from years ago when we were on tomcat 6 (included
with the BMC software app) and did the same thing, renaming their "tomcat"
folder with the extracted 7.0.75 and did *.war (more .war's in this new
release and the instructions below state) and tweaks to server.xml etc

It works now.  100% W O R K S!
I dont know why yet, and there's so many things I could test (like
downloading the exact same release of tomcat they used and see if my
vanilla one works, and theirs doesnt.  Or check release notes for
subsequent releases, etc.)  but I will put that on the vendor.

Pretty crazy that after all this, it was at least in testing, solved like
this.  Man! wow.

 NOTES 

1. Stop the Control-M Web Server.

2. Rename folder tomcat to tomcat.orig, folders path:

a. Windows: %EM_HOME%/emweb/tomcat
b. UNIX: $EM_HOME/etc/emweb/tomcat

3. Download tomcat 6.0.41 Binaries from http://tomcat.apache.org/
download-60.cgi#6.0.41 (Binary distribution Core, ZIP or tar.gz file)

4. Extract the downloaded file to "emweb" folder (%EM_HOME%/emweb or
$EM_HOME/etc/emweb/tomcat)

5. Rename the root folder name from "apache-tomcat-6.0.41" to "tomcat"

6. Copy the following files from "tomcat.orig" folder to "tomcat" folder
using their relative path:

a. tomcat.orig/webapps/SelfService.war
b. tomcat.orig/webapps/WorkloadChangeManager.war
c. tomcat.orig/webapps/bim.war
d. tomcat.orig/conf/server.xml (overwrite existing)
e. tomcat.orig/webapps/ROOT/index.html (overwrite existing)
f. If SSL is enable on Tomcat, please copy the certificate located at
tomcat.orig/conf

7. Edit the copied tomcat/conf/server.xml xml file and add the following
lines where other listeners are defined:




 For example, in the default "server.xml", the lines are as follows:















The new section should look like:












8. Start the Control-M Web Server


On Fri, Feb 24, 2017 at 8:29 AM, Aaron Gray  wrote:

> Andre, that is all very educational and I feel even when this is resolved,
> that I have learned a good amount here; so I thank you for everything.
>
> I have an update.  I decided to shutdown the vendor included/supplied
> 7.0.50 release of Tomcat.  I extracted vanilla 7.0.75 tomcat, updated
> server.xml to change port from 8080 to 18080, and added the static line
> (created a new /static location like:
> /app/home/agray/apache-tomcat-7.0.75/static
> Started that tomcat
>
> https://loadbalancer.domain.com/static
> loads PERFECTLY!  Wh?  Now I guess I could be investigating the
> differences between these two environments.  I do remember though they had
> a document that I followed a long time ago when the release of Tomcat they
> included had a major vulnerability in it (years ago) to copy their specific
> .war and changes in to a vanilla Tomcat and deploy it there.  I think I
> want to do that.  I have escalated to their developers, since I can prove a
> vanilla tomcat can serve up my static content through the browser -> F5 ->
> apache http proxy server -> app server   yet their included one cant
> without 302 and adding the :port and having to remove it, etc.
>
> Wild.  I'll update soon.
> BTW, hope you got some sleep after last night, but want to thank you again.
>
> On Thu, Feb 23, 2017 at 4:00 PM, André Warnier (tomcat) 
> wrote:
>
>> To avoid getting totally confused, you may want to read this explanation
>> first :
>> https://wiki.apache.org/httpd/DirectoryListings
>>
>> In other words, when you send this request from the browser :
>> https://loadbalancer.domain.com/SelfService
>>
>> The first response that /should/ come back, would be a "re-direct"
>> response from the (final) server, with a special HTTP header added :
>> Location: https://loadbalancer.domain.com/SelfService/
>>
>> Then your browser should re-issue the request automatically, this time to
>> :
>> https://loadbalancer.domain.com/SelfService/
>> (with the trailing "/" added)
>>
>> Then, in a second step, what should happen is :
>>
>> Your browser indicates a URL, which on the server resolves to a directory.
>> The server /may/ be configured in such a way, that for this kind of
>> request, it returns an auto-generated list of all the files in that
>> directory, automatically.
>> Or it may be configured to return instead, a specific html page.
>> (That what you do in Apache, with the DirectoryIndex directive)
>> And if the server is not configured at all for that, it would probably
>> return a response "Forbidden", for security reasons (you probably don't
>> want someone to be able to list the files in that directory, unless you
>> specifically configured the server to allow that).
>>
>> Or, the server may be configured so that for such a request, it defaults
>> to running some standard servlet which is part of the application, and
>> which would return the application starting page.
>> That would probably be the case in your "/SelfService" tomcat webapp.
>>
>> So, the 302 responses which you get in 

Re: Getting application root path before servlet is initialized?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 2/21/17 8:31 AM, Martin Knoblauch wrote:
> Hi,
> 
> is there a way to find the absolute path of the application root
> before the servlet is initialized?
> 
> Alternatively: is there a way to defer the initialization of a
> datasource until the servlet is initialized?
> 
> Background: I have extended
> "org.apache.tomcat.jdbc.pool.DataSourceFactory" to automatically
> set credentials so that they are not stored in the 
> "Catalina/localhost/XXX.xml" file. Instead they are taken from
> encrypted values in a file below the application root. Works fine
> if I know that path at "createDataSource" time.

Where are you configuring your ? In conf/server.xml or in
your application's META-INF/context.xml file?

> In order to avoid hard coding that path, I need a programmatic to
> find that value. Unfortunately the datasource is initialized before
> the servlet, so "getRealPath()" is not working yet.

getRealPath is a bad idea. Also, your DataSources will be
fully-configured before any servlets are initialized, so it's too late.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsGa4AAoJEBzwKT+lPKRYSFEP/148R7SLCoXyYMyx8e5heN+J
3YwyJriefzfD1Y1t/X2koKmluaz4waOZgFdiJDEoGwdYiX0r9oD/IGk026vrO9pF
5o/RRGB/WioedqniPRrdosn9zObYnAea2HNgn2uYndlHioJ1KSR9xomlcYuAiW9+
ZCaKxCH+jmnh9OXmpV025pfips8Iga4EKGE2mtQI6yGW9chgy1v+PX+3usMy6b2L
jE0koGCBQcnaQQHxDsFI3sUBmnY8nkQ80bCq21gQy+TEvFs7mZte1i+Zi+pgwlTe
mZ4RpMebQUZzqeH8fmEHUwSuaphrP2O+xq07rWl/oXQCjEQGrlZJml2C9C6nS3Ds
2uhfclEz+Yhb3aw/iRtEHXWKnTa58PZ4Qtqlq9gDH3SYvIj+ancPKy3Wkv+K+dc8
ora7qKl97OoAcsAkKT0dL+psUcpepskw7EoCiEwPHeQKqSKOW1X0PXNVpHgZD2J4
kjX38PzFmtTjWj+wPa8cdZmD576iT8iiD4nClwON0dF6ipOY6R321GKmXPT2UUup
YSmSO39WqKuehy5uhIK4EXs0XGlZU4y5ASPS0frdAv3SvxX7BqxKT1UJLbrEQFm6
QTJuFlZeRuPxEnsKpBMaEQtTrbwB3M9FTP/znrjCh7Bxq0TuMSafe2/nCXEFg201
jpJkYWzch8pZ2CKzU6Yw
=d2oI
-END PGP SIGNATURE-

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

Re: Connection reset while trying to access a web service running under Tomcat

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 2/23/17 7:08 PM, André Warnier (tomcat) wrote:
> On 24.02.2017 00:57, James H. H. Lampert wrote:
>> On 2/23/17, 3:13 PM, André Warnier (tomcat) wrote:
>>> It seems to say right up here what the problem is : the
>>> customer system cannot establish a HTTPS connection with your
>>> server. The connection attempt starts, but then your server
>>> rejects it and closes the connection. Maybe they cannot agree
>>> on a common SSL protocol ?
>> . . .
>> 
>> Is there a diagnostic setting I can apply to the Tomcat server,
>> that would shed any light on what's happening?
>> 
> 
> Probably, if you set the log level high enough. Unfortunately, the 
> tomcat logging configuration is also not really my thing. One
> expert in these matters on this list is Christopher, but he seems
> to get list emails after some delay.

High praise. My delays are usually self-imposed. :)

> So have a little patience, and you'll probably be helped.
> 
> In the meantime, there is always the helpful on-line tomcat 
> documentation which you could try. 
> http://tomcat.apache.org/tomcat-8.0-doc/logging.html

You need to enable logging at a lower level than this if a TLS
connection is failing. Tomcat doesn't get any indication that anyone
even tried to make a connection if the TLS handshake fails.

James, are you using APR/tcnative/OpenSSL or JSSE? With JSSE, you can
enable logging with the system property "-Djavax.net.debug=all"
(without quotes, of course). Beware: this will produce ENORMOUS
amounts of debugging output. Don't put it into production... just
set-up a test server within the same environment and try to make
connections.

Back to the original report... is this a single client that
*sometimes* gets connection resets or is it multiple clients, some of
which always get resets and other clients are okay? If it's one
client, do they have multiple boxes/client services, etc. that can be
identified as "always working" or "always failing", or is this all
totally intermittent?

Finally... what's the underlying protocol? Plain-old HTTP or
Websocket? I guess you are getting reset-on-connect and not
reset-during-communication, so the underlying protocol might not
matter at all.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYsGXGAAoJEBzwKT+lPKRYCpcP/1liYo5BOSR7cyb7kKYBmnfC
WA3V8Faw8IXZGeeEwFGVEYB8HAa+jnivX8nlYSf8q6pU/FBA5KuO4fVAZJchOLB4
I+DC83+FjciMXcgklYIt+i8IVlw3wQssriMgEDG/xhoQB7i+NPRp66RBvZ/+OEhu
iyY1nndw8SU+RvQAz97r8GcUNz5eTfqxJmt030D/K72oHdoLjSLjLUD3rze/0/wm
9AysEEEYwck8rzq3WrYKXhBbxCkor+rKt24ZT1zAzLqfNMXWLko0MMn+el3ChuDf
2dLRGThq6itu08Pq3neiUu7jC1Cx9XUen8MozSe4dGL2snG8/lAxuq2j3S7i8/b1
mq4yzyVDZqsaBm8Ctnb95nFf4KeTbG0HUxMUPNbzHaOSJKknrYg4NWNSstT4d2Bk
b9kDx7ue7LhxWoaekp8d9CvBrMwMv6P5bVb994Z6onfGOSatilgUrZW8zOmfxTJD
OwWpwDGPw5rse4r+PudPkX3iKjFtejKzsmExI+89AwbQD8R/bBNL3sN4Jm5fY+Gz
4pYGICiEGzxlpJyvtYaIZtmUvubyj8RQ3dKNbkpziPXY3r8q7M18VVMQIVp59P5J
3yVnJUWdDTHMFNIuI8wVwE4VXgf3yO13MlnVQvWdhc/TVcrlAgwWw0QT3RdcS8Y5
fEQc0kmhPkKioZOcFJce
=p7IF
-END PGP SIGNATURE-

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

Re: Strange URL rewrite when reverse proxy with Apache HTTP Server

[Aaron Gray]

Andre, that is all very educational and I feel even when this is resolved,
that I have learned a good amount here; so I thank you for everything.

I have an update.  I decided to shutdown the vendor included/supplied
7.0.50 release of Tomcat.  I extracted vanilla 7.0.75 tomcat, updated
server.xml to change port from 8080 to 18080, and added the static line
(created a new /static location like:
/app/home/agray/apache-tomcat-7.0.75/static
Started that tomcat

https://loadbalancer.domain.com/static
loads PERFECTLY!  Wh?  Now I guess I could be investigating the
differences between these two environments.  I do remember though they had
a document that I followed a long time ago when the release of Tomcat they
included had a major vulnerability in it (years ago) to copy their specific
.war and changes in to a vanilla Tomcat and deploy it there.  I think I
want to do that.  I have escalated to their developers, since I can prove a
vanilla tomcat can serve up my static content through the browser -> F5 ->
apache http proxy server -> app server   yet their included one cant
without 302 and adding the :port and having to remove it, etc.

Wild.  I'll update soon.
BTW, hope you got some sleep after last night, but want to thank you again.

On Thu, Feb 23, 2017 at 4:00 PM, André Warnier (tomcat) 
wrote:

> To avoid getting totally confused, you may want to read this explanation
> first :
> https://wiki.apache.org/httpd/DirectoryListings
>
> In other words, when you send this request from the browser :
> https://loadbalancer.domain.com/SelfService
>
> The first response that /should/ come back, would be a "re-direct"
> response from the (final) server, with a special HTTP header added :
> Location: https://loadbalancer.domain.com/SelfService/
>
> Then your browser should re-issue the request automatically, this time to :
> https://loadbalancer.domain.com/SelfService/
> (with the trailing "/" added)
>
> Then, in a second step, what should happen is :
>
> Your browser indicates a URL, which on the server resolves to a directory.
> The server /may/ be configured in such a way, that for this kind of
> request, it returns an auto-generated list of all the files in that
> directory, automatically.
> Or it may be configured to return instead, a specific html page.
> (That what you do in Apache, with the DirectoryIndex directive)
> And if the server is not configured at all for that, it would probably
> return a response "Forbidden", for security reasons (you probably don't
> want someone to be able to list the files in that directory, unless you
> specifically configured the server to allow that).
>
> Or, the server may be configured so that for such a request, it defaults
> to running some standard servlet which is part of the application, and
> which would return the application starting page.
> That would probably be the case in your "/SelfService" tomcat webapp.
>
> So, the 302 responses which you get in some cases, are probably normal, as
> explained by all the above.
> What is definitely /not/ normal, is that port that you get either in these
> redirect responses, or in the error messages.  Because that means that,
> somewhere in the chain, one of the elements is not doing its job properly
> when proxying.
> The point of the ProxyPassReverse directive, is precisely that : ensure
> that if the "proxied to" server returns a re-direct response, the
> "Location:" header that is in that redirect response would be properly
> edited before returning that redirect response back up the chain, in such a
> way that the ultimate client would not try next, to access a URL that leads
> nowhere.
>
> And now it's really late..
>
>
>
> On 24.02.2017 00:06, André Warnier (tomcat) wrote:
>
>> On 23.02.2017 21:17, Aaron Gray wrote:
>>
>>> Another weird thing...
>>>
>>> If you go to:
>>> https://loadbalancer.domain.com/SelfService
>>> If I am viewing the headers immedaitely I see 302 not found.
>>>
>>
>> 302 is not "not found". It is "Found", and it is a Redirect response.
>> See : https://en.wikipedia.org/wiki/HTTP_302
>> for a good explanation.
>> (But stop after the second paragraph, otherwise you'll get confused
>> again..)
>>
>>   Then I wait
>>
>>> the 30 sec for it to totally fail and change the URL in the browser to
>>> https://loadbalancer.domain.com:232700/SelfService
>>>
>>> If you just remove the :232700 and hit Enter, it then loads properly.
>>> See
>>> immedaitly 200 OK and it is fine.  Don't navigate anywhere else like to
>>> https://loadbalancer.domain.com/static or else you'll have to repeat the
>>> same thing as above with the :232700 and removing it, hit Enter.
>>>
>>> Weird.
>>>
>>> Of course none of this is an issue if you dont hit it with the F5 Load
>>> Balancer to start.
>>>
>>
>> Yes. There seems to be something weird *when a Redirect response is being
>> sent back by
>> tomcat*, and has to go back through the load balancer.
>> And it may be linked to the fact that the load-balancer does 

RE: CVE-2017-6056.

[Caldarale, Charles R]

> From: Paralos Trainings [mailto:paralostranin...@gmail.com] 
> Subject: CVE-2017-6056.

> I'd like to know if the latest version of Tomcat 7 and Tomcat 8 are
> affected by CVE-2017-6056.

Real Tomcat releases (downloaded from tomcat.apache.org) are not affected.  
Some 3rd-party repackaged versions do have the problem due to failure on their 
part to include relevant fixes.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

CVE-2017-6056.

[Paralos Trainings]

I’d like to know if the latest version of Tomcat 7 and Tomcat 8 are
affected by CVE-2017-6056.

If so, when is the update to fix the vulnerability going to be released.

I couldn’t find the reference on any of the vulnerabilities pages:

https://tomcat.apache.org/security.html

Thanks.
PT