[ANN] Apache Tomcat 8.0.47 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.0.47.

Please note that Tomcat 8.x users should normally be using 8.5.x
releases in preference to 8.0.x releases. The Apache Tomcat team
announced that support for Apache Tomcat 8.0.x will end on
30 June 2018.

Apache Tomcat 8.0 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language and Java
WebSocket technologies.

Apache Tomcat 8.0.47 includes fixes for issues identified in 8.0.46 as
well as other enhancements and changes. The notable changes since
8.0.46 include:


- Fix CVE-2017-12617

- Add ExtractingRoot, a new WebResourceRoot implementation that extracts
  JARs to the work directory for improved performance when deploying
  packed WAR files.

- Update the packaged version of the Tomcat Native Library to 1.2.14 to pick
  up the latest Windows binaries built with APR 1.6.2 and OpenSSL 1.0.2l.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload

[Michael Smith]

Mark,

Do you know if tomcat 5.x and 6.x are vulnerable to this issue? I know they
are not supported, but are they exploitable by this vulnerability?

Thx

Mike

On 3 October 2017 at 11:55, Mark Thomas  wrote:

> CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP Upload
>
> Severity: Important
>
> Vendor: The Apache Software Foundation
>
> Versions Affected:
> Apache Tomcat 9.0.0.M1 to 9.0.0
> Apache Tomcat 8.5.0 to 8.5.22
> Apache Tomcat 8.0.0.RC1 to 8.0.46
> Apache Tomcat 7.0.0 to 7.0.81
>
> Description:
> When running with HTTP PUTs enabled (e.g. via setting the readonly
> initialisation parameter of the Default servlet to false) it was
> possible to upload a JSP file to the server via a specially crafted
> request. This JSP could then be requested and any code it contained
> would be executed by the server.
>
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 9.0.1 or later
> - Upgrade to Apache Tomcat 8.5.23 or later
> - Upgrade to Apache Tomcat 8.0.47 or later
> - Upgrade to Apache Tomcat 7.0.82 or later
>
> Credit:
> This issue was first reported publicly followed by multiple reports to
> the Apache Tomcat Security Team.
>
> History:
> 2017-10-03 Original advisory
>
> References:
> [1] http://tomcat.apache.org/security-9.html
> [2] http://tomcat.apache.org/security-8.html
> [3] http://tomcat.apache.org/security-7.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Mapping role names to groups

[Sebastian Trost]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, October 03, 2017 4:10 PM
To: Tomcat Users List 
Subject: Re: Mapping role names to groups

On 03/10/17 14:01, Sebastian Trost wrote:
>> Hi!
>> 
>> I was looking for a way to map security role names from tomcat to LDAP 
>> groups. I found an old thread from August 2009 with the exact problem in 
>> which Christopher Schultz recommended to write a servlet filter or valve to 
>> do that. 
>> 
>> Original mail: 
>> http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3C1249556542.8225.6.camel@habanero%3E
>> Response from Christopher Schulz: 
>> http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3c4a7af405.7090...@christopherschultz.net%3E
>> 
>> It has now been eight years and I'm wondering if there is still no other 
>> solution than this?

> security-role-ref ?

AFAIK,  is only valid within the  element. 
Therefore, it doesn't work with JSPs or filters which are not servlets. 

Regards
Sebastian Trost

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

Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

On 04/10/17 08:27, Michael Smith wrote:
> Mark,
> 
> Do you know if tomcat 5.x and 6.x are vulnerable to this issue? I know they
> are not supported, but are they exploitable by this vulnerability?

I don't know. I haven't tested them and I don't plan to test them.

My expectation is that 6.x and 5.x would be vulnerable to CVE-2017-12617
as well as CVE-2017-12615 and CVE-2017-12616 in some form as the code
that handles resources in 7.0.x is also present (in an early form) in
those versions.

Mark


> 
> Thx
> 
> Mike
> 
> On 3 October 2017 at 11:55, Mark Thomas  wrote:
> 
>> CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP Upload
>>
>> Severity: Important
>>
>> Vendor: The Apache Software Foundation
>>
>> Versions Affected:
>> Apache Tomcat 9.0.0.M1 to 9.0.0
>> Apache Tomcat 8.5.0 to 8.5.22
>> Apache Tomcat 8.0.0.RC1 to 8.0.46
>> Apache Tomcat 7.0.0 to 7.0.81
>>
>> Description:
>> When running with HTTP PUTs enabled (e.g. via setting the readonly
>> initialisation parameter of the Default servlet to false) it was
>> possible to upload a JSP file to the server via a specially crafted
>> request. This JSP could then be requested and any code it contained
>> would be executed by the server.
>>
>> Mitigation:
>> Users of the affected versions should apply one of the following
>> mitigations:
>> - Upgrade to Apache Tomcat 9.0.1 or later
>> - Upgrade to Apache Tomcat 8.5.23 or later
>> - Upgrade to Apache Tomcat 8.0.47 or later
>> - Upgrade to Apache Tomcat 7.0.82 or later
>>
>> Credit:
>> This issue was first reported publicly followed by multiple reports to
>> the Apache Tomcat Security Team.
>>
>> History:
>> 2017-10-03 Original advisory
>>
>> References:
>> [1] http://tomcat.apache.org/security-9.html
>> [2] http://tomcat.apache.org/security-8.html
>> [3] http://tomcat.apache.org/security-7.html
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


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

Re: Mapping role names to groups

[tomcat]

On 04.10.2017 10:20, Sebastian Trost wrote:

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Tuesday, October 03, 2017 4:10 PM
To: Tomcat Users List 
Subject: Re: Mapping role names to groups

On 03/10/17 14:01, Sebastian Trost wrote:

Hi!

I was looking for a way to map security role names from tomcat to LDAP groups. 
I found an old thread from August 2009 with the exact problem in which 
Christopher Schultz recommended to write a servlet filter or valve to do that.

Original mail: 
http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3C1249556542.8225.6.camel@habanero%3E
Response from Christopher Schulz: 
http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3c4a7af405.7090...@christopherschultz.net%3E

It has now been eight years and I'm wondering if there is still no other 
solution than this?



security-role-ref ?


AFAIK,  is only valid within the  element. 
Therefore, it doesn't work with JSPs or filters which are not servlets.



Isn't a JSP page ultimately translated into a servlet ?



Regards
Sebastian Trost

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




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

Re: encodeURL, jsessionid and mod_rewrite ?

[tomcat]

On 04.10.2017 07:40, Peter Kreuser wrote:


Peter Kreuser


Am 04.10.2017 um 02:44 schrieb Christopher Schultz 
:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurant,


On 10/3/17 5:17 PM, Laurent Perez wrote:
I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
"foo" war is deployed at /foo context path under tomcat. The /foo
path is not public, apache has a rewrite rule defined as : /bar/*
rewrites internally to /foo/*.

I'm using jstl and its  for every url in my
jsps to gain the ;jsessionid from encodeURL whenever jsessionid
cookie is not yet set (1st requests)



adding to Christopher, accepting the jsessionid from the Url is a bad security 
risk (Session fixation). So you should disable that by accepting the session 
only via COOKIE via

COOKIE 
then at least this rewriting problem is gone.

Peter



Well, a cookie can also be path-specific.  Which is only *one* of these issues which we 
are talking about, when we say "don't".




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

Re: Mapping role names to groups

[Mark Thomas]

On 04/10/17 09:20, Sebastian Trost wrote:
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Tuesday, October 03, 2017 4:10 PM
> To: Tomcat Users List 
> Subject: Re: Mapping role names to groups
> 
> On 03/10/17 14:01, Sebastian Trost wrote:
>>> Hi!
>>>
>>> I was looking for a way to map security role names from tomcat to LDAP 
>>> groups. I found an old thread from August 2009 with the exact problem in 
>>> which Christopher Schultz recommended to write a servlet filter or valve to 
>>> do that. 
>>>
>>> Original mail: 
>>> http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3C1249556542.8225.6.camel@habanero%3E
>>> Response from Christopher Schulz: 
>>> http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3c4a7af405.7090...@christopherschultz.net%3E
>>>
>>> It has now been eight years and I'm wondering if there is still no other 
>>> solution than this?
> 
>> security-role-ref ?
> 
> AFAIK,  is only valid within the  element. 
> Therefore, it doesn't work with JSPs or filters which are not servlets.

JSPs are still handled by a servlet so you could work around that
problem. There isn't such an easy solution available for filters.

This sort of mapping is probably something we need to think about adding
to the Realm.

There is this enhancement request:
https://bz.apache.org/bugzilla/show_bug.cgi?id=55477

The code needs review but from a quick look the general approach looks
good. The thing I'd want to think about is exactly how the mapping was
defined. A few thoughts...

Putting it in server.xml means restarting Tomcat to change it. Putting
it in a separate file removes that issue - if the ability to reload it
is added.

Experience tells me multiple elements will be less hassle (i.e. less
edge case bugs) than a single element with some form of special syntax.

Mark

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

Re: Embedded tomcat does not find web-fragment in jars outside web-inf\lib continued...

[Brian Toal]

Jetty also makes it very easy to scan jar for @WebServlet, @WebFilter,
@WebListener via AnnotationConfiguration.

http://www.eclipse.org/jetty/documentation/9.4.x/configuring-webapps.html

On Wed, Oct 4, 2017 at 12:53 AM, Brian Toal  wrote:

> The chain [1] left of with:
> "The relevant language is in section 8.2.1
>
> 
> If a framework wants its META-INF/web-fragment.xml honored in such a way
> that it augments a web application's web.xml, the framework must be bundled
> within the web application's WEB-INF/lib directory
> 
>
> Therefore, Tomcat 8.0 looks to be doing the right thing."
>
> Which I think is fine for the case where the container is augmenting a
> existing web.xml.
>
> However the spec also says "If a framework is packaged as a jar file and
> has metadata information in the form of deployment descriptor then the
> web-fragment.xml descriptor must be in the META-INF/ directory of the jar
> file."
>
> I'm not interested in augmenting a existing web.xml, nor my embedded app
> is using WEB-INF/lib, which seems not to meet the eligibility critieria for
> adding the jar to WEB-INF/lib , tomcat should honor
> META-INF/web-fragment.xml in jars in the absence of web.xml, to determine
> if the Servlet 3.0 annotations are going to be scanned.  This is the
> problem I'm having after fixing the classloading issues in [2].
>
> Thoughts?
>
>
> [1] - https://marc.info/?l=tomcat-user=149443917508077=2
> [2] - https://marc.info/?l=tomcat-user=150701409822162=2
>
>
>

Re: encodeURL, jsessionid and mod_rewrite ?

[Mark Thomas]

On 4 October 2017 06:40:24 BST, Peter Kreuser  wrote:
>
>Peter Kreuser
>
>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz
>:
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Laurant,
>> 
>>> On 10/3/17 5:17 PM, Laurent Perez wrote:
>>> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
>>> "foo" war is deployed at /foo context path under tomcat. The /foo
>>> path is not public, apache has a rewrite rule defined as : /bar/* 
>>> rewrites internally to /foo/*.
>>> 
>>> I'm using jstl and its  for every url in my
>>> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
>>> cookie is not yet set (1st requests)
>>> 
>
>adding to Christopher, accepting the jsessionid from the Url is a bad
>security risk (Session fixation). So you should disable that by
>accepting the session only via COOKIE via
>
>COOKIE 
>then at least this rewriting problem is gone.

... to be exchanged for a problem with the cookie path.


>>> Now my question is : the  results in a
>>> "/foo/page.jsp;jsessionid=..." I want the result instead as
>>> /bar/pages.jsp;jsessionid=
>>> 
>>> Should I go straight for a HttpServletResponseWrapper replacing
>>> every /foo/ with /bar/ or is there a more elegant way ? If the
>>> apache rewrite rule is modified - say, to /barv2/, is it ok to use 
>>> mod_headers to pass the original path instead of hardcoding /bar/
>>> ?
>> 
>> You are going down a path that will produce endless problems, hacks,
>> and ugly solutions to those problems. It will be much easier for you
>> to simply re-name your application from "foo" to "bar" and not worry
>> about any of this rewriting foolishness.

Huge +1

Mark


>> 
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULvMdHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrIw//fPYMRXFyX4Ad4Qcl
>> f6H2XjoFU7zOH9sQXjj5KgDL+DWS2nMH20RWes74ehYNv3BGDLIsv4CHClessOhW
>> f7euy0y18IAhnTGjUaP3WjbN6xt2M6UgWsIv2jxS30DdI6irZ8/9IWdZ4xy8PNWV
>> OujeuQBWniQH6jPVUwQ17qapiBDbAzB58HXb72KYFDj+Z6C0gacK/MT9yTkiNEX/
>> bFNucLH2oTMomRcNeGZsmWCmQ+jShx0bMjmaKX5JndtckRCWSG8bAZYBhq5JA+bd
>> GlFk/jZl+PT0cO1q6ViHvv9r3DDIUAMXvfvQnf6RciQ86GB+GrJn/GnRtPo7R5RH
>> MoNRr7H16XBXER1SlzjXHLd2HOKf5pFduG1lgwY1z4OWKdqHY39/bSJynfCjyiNC
>> VAvlZZQ2tCudwa+7Pit85FryW4HWECvw10vwYNLHDfFD63juI6YexaN+Fd5RGu8R
>> jGqN3GqR1iboveGTv8O2kSvTgJjGa0nxsd6CTZLMJXt1GPlZ4r9MRdZWO/dobvGt
>> QV18dvwHYHo1Jsgo1+pR6Hw34hw0dPfD5IYiHV9k+9yIeWj3l4/tYu+k1VA9j/Yp
>> /LJ6otvJ+zBaa2swroy+EnnbMP6JR04GnXrezglXxbndaP1l7POCFngH34veM4+S
>> j/5ZMvfJiUZdDAdQxoFH6B9ochU=
>> =0zb2
>> -END PGP SIGNATURE-
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 


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

Re: encodeURL, jsessionid and mod_rewrite ?

[tomcat]

On 04.10.2017 02:44, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Laurant,

On 10/3/17 5:17 PM, Laurent Perez wrote:

I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
"foo" war is deployed at /foo context path under tomcat. The /foo
path is not public, apache has a rewrite rule defined as : /bar/*
rewrites internally to /foo/*.

I'm using jstl and its  for every url in my
jsps to gain the ;jsessionid from encodeURL whenever jsessionid
cookie is not yet set (1st requests)

Now my question is : the  results in a
"/foo/page.jsp;jsessionid=..." I want the result instead as
/bar/pages.jsp;jsessionid=

Should I go straight for a HttpServletResponseWrapper replacing
every /foo/ with /bar/ or is there a more elegant way ? If the
apache rewrite rule is modified - say, to /barv2/, is it ok to use
mod_headers to pass the original path instead of hardcoding /bar/
?


You are going down a path that will produce endless problems, hacks,
and ugly solutions to those problems. It will be much easier for you
to simply re-name your application from "foo" to "bar" and not worry
about any of this rewriting foolishness.

- -chris


+1.
I can only agree 100% with what Chris is saying above.
The fact that you /can/ do these things at the front-end proxy level, does not mean that 
it is a good idea to do it.  There are probably cases when you can *really* not do 
otherwise, and that's why these mechanisms are there.
But doing this, brings endless other practical inconvenients, extra work, confusion, 
documentation issues, understanding issues 6 months later, support issues, etc.

So, in a nutshell : don't do it.

P.S. The annoying bit about recommendations such as the above, is that if you follow them, 
you will not even know how much work and hassle you have saved to yourself, and

1) you will not even feel thankful
and
2) we won't have the satisfaction of saying later : "well, we told you so"
;-)



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

Embedded tomcat does not find web-fragment in jars outside web-inf\lib continued...

[Brian Toal]

The chain [1] left of with:
"The relevant language is in section 8.2.1


If a framework wants its META-INF/web-fragment.xml honored in such a way
that it augments a web application's web.xml, the framework must be bundled
within the web application's WEB-INF/lib directory


Therefore, Tomcat 8.0 looks to be doing the right thing."

Which I think is fine for the case where the container is augmenting a
existing web.xml.

However the spec also says "If a framework is packaged as a jar file and
has metadata information in the form of deployment descriptor then the
web-fragment.xml descriptor must be in the META-INF/ directory of the jar
file."

I'm not interested in augmenting a existing web.xml, nor my embedded app is
using WEB-INF/lib, which seems not to meet the eligibility critieria for
adding the jar to WEB-INF/lib , tomcat should honor
META-INF/web-fragment.xml in jars in the absence of web.xml, to determine
if the Servlet 3.0 annotations are going to be scanned.  This is the
problem I'm having after fixing the classloading issues in [2].

Thoughts?


[1] - https://marc.info/?l=tomcat-user=149443917508077=2
[2] - https://marc.info/?l=tomcat-user=150701409822162=2

Re: Embedded tomcat does not find web-fragment in jars outside web-inf\lib continued...

[Mark Thomas]

On 04/10/17 08:53, Brian Toal wrote:
> The chain [1] left of with:
> "The relevant language is in section 8.2.1
> 
> 
> If a framework wants its META-INF/web-fragment.xml honored in such a way
> that it augments a web application's web.xml, the framework must be bundled
> within the web application's WEB-INF/lib directory
> 
> 
> Therefore, Tomcat 8.0 looks to be doing the right thing."
> 
> Which I think is fine for the case where the container is augmenting a
> existing web.xml.
> 
> However the spec also says "If a framework is packaged as a jar file and
> has metadata information in the form of deployment descriptor then the
> web-fragment.xml descriptor must be in the META-INF/ directory of the jar
> file."
> 
> I'm not interested in augmenting a existing web.xml, nor my embedded app is
> using WEB-INF/lib, which seems not to meet the eligibility critieria for
> adding the jar to WEB-INF/lib , tomcat should honor
> META-INF/web-fragment.xml in jars in the absence of web.xml, to determine
> if the Servlet 3.0 annotations are going to be scanned.  This is the
> problem I'm having after fixing the classloading issues in [2].
> 
> Thoughts?

If you use addContext() the expectation is that you also take on
responsibility for performing all of the configuration.

If you want all the standard Servlet spec behaviour out of the box, you
need to use addWebapp().

If you take the addContext() route then you can make use of the same
code Tomcat uses to perform the configuration. Suggestions on how to
make that more extensible / flexible / etc. welcome.

Mark


> [1] - https://marc.info/?l=tomcat-user=149443917508077=2
> [2] - https://marc.info/?l=tomcat-user=150701409822162=2
> 


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

Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code Execution via JSP upload

[Violeta Georgieva]

Hello,

2017-10-04 4:52 GMT+03:00 Caldarale, Charles R :
>
> > From: Baron Fujimoto [mailto:ba...@hawaii.edu]
> > Subject: Re: [SECURITY] CVE-2017-12617 Apache Tomcat Remote Code
Execution
> via JSP upload
>
> > I haven't seen an announcement for 8.0.47, nor does the Apache Tomcat
> > website seem to reference it yet, but it appears to be available in the
> > distribution archive(s). E.g.:
>
> > 
>
> > Is this 8.0.47 blessed for use?
>
> Pretty much - the voting process completed over the weekend (it passed),
but
> the announcement isn't made until the mirrors all catch up.  Should be
fine
> to use from the archive.

The Tomcat site was updated with information about version 8.0.47.
Announcement also was sent.

Regards,
Violeta

Re: Can i use tomcat 9.0.x version in production

[s v n trimurthulu]

Thanks Mark and Christopher

On Wed, Oct 4, 2017 at 6:12 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Murthy,
>
> On 10/3/17 7:38 AM, s v n trimurthulu wrote:
> > At present we are using 7.0.x in our production environment. As we
> > have received few CVE alerts we wanted to migrate it to latest
> > version 9.0.x. But when i see the status of the 9.0.x release it is
> > showing "Stable = No". So i request you to suggest me whether i
> > can use the latest version(9.0.1) of tomcat in production or not.
> > Thanks in advance.
>
> I'd recommend moving towards Tomcat 8.5 (after extensive testing in an
> appropriate environment). There are very few differences between 8.5
> and 9.0 (other than Servlet Spec changes) and so moving from 8.5 ->
> 9.0 in the future should be fairly easy.
>
> Tomcat 8.5 *is* currently considered production-ready.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULoIdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhEWw//bpMgdIQCx11yDxUZ
> a1TxW8C3jqzKrTJdF1qbWmlZRIVt0kL8gryU8YGtPEP2Ge0c7uf6uqIIwsSJAPKO
> VoJhHwXe9lQWjZL4EUxzK9w+uU77Kl/C4kroojz2PiNS2CTeYOcrw6dfTmFdAMhY
> KAHMnl6oxp/mwf2s5DW9E7XZ/E+6Y+Ovr1gNIZ5u0qZHSRDJhimsfiTQfaQ2JnuS
> hORk/M1toaatDX0YiMXdyXIsWjDN4i+GpUvmIZheOP2SZauvyBCcCsL+OEEfWWSL
> lFvJHCLBkGxGzjN9lIIISi/EYnhZa2xhPpGpr9UjbDLIip898nB/5JBPEgVaBfvu
> lcCIzYJhfQpAwj2R0huY0P5NS0z1fUwnrhHntJpN0B/wXkkaBBuBc011MGl+1V0w
> 5GGGrPUhgHKxumWxR+VUn4ZUWL4jvg6V3lGx5i/GY0M4wjjlpZCIGBP+6Cg+CFD4
> zhYQOre3IAFnb+CmJZhTXpp2kjjjgrDUcHLyjLWvcdl8JFLsBmWIqOvPBZvAbjN3
> zWYg/GOis/obJ7quBlL/z0E2E2RI0yacuQ5sxO1z6HPbMFaQ9OIAjY0yEFZG+qlo
> MuMVnckGpdiDdE+StUZcUHExpX+PXONL6VmT55m8lOrMjvQK5w/qtb5NPkgWM+ZO
> Ys4yaxBShFtkVdAOlOAzYKGtmAs=
> =7W8F
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

AJP connection pool issue bug?

[TurboChargedDad .]

 Hello all..
I am going to do my best to describe my problem.  Hopefully someone will
have some sort of insight.

Tomcat 7.0.41 (working on updating that)
Java 1.6 (Working on getting this updated to the latest minor release)
RHEL Linux

I inherited an opti-tenant setup.  Individual user accounts on the system
each have their own Tomcat instance, each is started using sysinit.  This
is done to keep each website in its own permissible world so one website
can't interfere with a others data.

There are two load balanced apache proxies at the edge that point to one
Tomcat server (I know I know but again I inherited this)

Apache lays over the top of tomcat to terminate SSL and uses AJP to
proxypass to each tomcat instance based on the users assigned port.

Things have run fine for years (so I am being told anyway) until recently.
Let me give an example of an outage.

User1, user2 and user3 all use unique databases on a shared database
server, SQL server 10.

User 4 runs on a windows jboss server and also has a database on shared
database server 10.

Users 5-50 all run in the mentioned Linux server using tomcat and have
databases on *other* various shared databases servers but have nothing to
do with database server 10.

User 4 had a stored proc go wild on database server 10 basically knocking
it offline.

  Now one would expect sites 1-4 to experience interruption of service
because they use a shared DBMS platform.  However.

Every single site goes down. I monitor the connections for each site with a
custom tool.  When this happens, the connections start stacking up across
all the components. (Proxies all the way through the stack)
Looking at the AJP connection pool threads for user 9 shows that user has
exhausted their AJP connection pool threads.  They are maxed out at 300 yet
that user doesn't have high activity at all. The CPU load, memory usage and
traffic for everything except SQL server 10 is stable during this outrage.
The proxies start consuming more and more memory the longer the outrage
occurs but that's expected as the connection counts stack up into the
thousands.  After a short time all the sites apache / ssl termination later
start throwing AJP timeout errors.  Shortly after that the edge proxies
will naturally also starting throwing timeout errors of their own.

I am only watching user 9 using a tool that allows me to have insight into
what's going on using JMX metrics but I suspect that once I get all the
others instrumented that I will see the same thing. Maxed out AJP
connection pools.

Aren't those supposed to be unique per user/ JVM? Am I missing something in
the docs?

Any assistance from the tomcat gods is much appreciated.


Thanks in advance.
TCD

RE: Mapping role names to groups

[Sebastian Trost]

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Wednesday, October 04, 2017 11:14 AM
To: users@tomcat.apache.org
Subject: Re: Mapping role names to groups

> On 04.10.2017 10:20, Sebastian Trost wrote:
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Tuesday, October 03, 2017 4:10 PM
>> To: Tomcat Users List 
>> Subject: Re: Mapping role names to groups
>>
>> On 03/10/17 14:01, Sebastian Trost wrote:
 Hi!

 I was looking for a way to map security role names from tomcat to LDAP 
 groups. I found an old thread from August 2009 with the exact problem in 
 which Christopher Schultz recommended to write a servlet filter or valve 
 to do that.

 Original mail: 
 http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3C1249556542.8225.6.camel@habanero%3E
 Response from Christopher Schulz: 
 http://mail-archives.apache.org/mod_mbox/tomcat-users/200908.mbox/%3c4a7af405.7090...@christopherschultz.net%3E

 It has now been eight years and I'm wondering if there is still no other 
 solution than this?
>>
>>> security-role-ref ?
>>
>> AFAIK,  is only valid within the  element. 
>> Therefore, it doesn't work with JSPs or filters which are not servlets.
>>

> Isn't a JSP page ultimately translated into a servlet ?


I don't know. You tell me! ;)
My knowledge is very limited and as far as I know, you can have servlets but 
also standalone JSP files (which still can use isUserInRole()). While adding 
the  tag to the  element works with the servlet, it 
doesn't work with the standalone JSP file. 

Example:

Authentication and authorization is done with LDAP.
Due to company policy the admin-role must be named "company-application-admin". 
The application has one servlet named FooServlet and one JSP file called 
importantLegacyJsp.jsp.

In the web.xml the admin role is defined like this:


   Application admin role
   admin


Also in the web.xml the servlet is defined like this:


   FooServlet
   com.vendor.app.servlet.FooServlet
   
  admin
  company-application-admin
   



Calling request.isUserInRole("admin") inside the servlet FooServlet will return 
"true", because the of the security-role-ref element inside the 
servlet-element. Everything works fine and as intended. The user then opens 
importantLegacyJsp.jsp which also calls request.isUserInRole("admin"). Now that 
method will return false, because the mapping is only defined inside the 
servlet element. 

It seems that there doesn't exist a way to make that work without creating a 
custom realm. 

Regards
Sebastian Trost

migration from tomcat 7.0 to 8.5

[Aquatic Safaris Diver]

I've read the migration manuals and have tried to make the changes to
my configuration to work correctly in tomcat v8.5, but it's not.  I'm
not an experton XML files and JDK so please help me.   I'm sure this is crazy 
simple
for you experts.

The server.xml conf file is OK between the two versions.   But my
application's deployment is having problems.

In my tomcat v7 conf/Catalina/localhost directory, I have ed.xml file
for my application containing:








After spending about 6 hours and reading tons of other web posts from
others trying to do the same thing, I finally have
something working, kinda.  My web application at least deploys when
tomcat starts.  The Loader part in the .xml was replaced with:

    
    
    
    
    
    


However, when I access the JSP page that need to resolve classes in these 
.jar's, I get
org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: [20] in the generated java file: 
[/work/Catalina/localhost/ed/org/apache/jsp/charters_jsp.java]
Only a type can be imported. com.google.api.client.json.JsonFactory resolves to 
a package

Line 20 is:
import com.google.api.client.json.JsonFactory;

I think I'm up to 12 hours messing with this and reading everything I can get 
my hands on.
Something that was so simple in tomcat 7 has turned out to be a nightmare in 
tomcat 8.
I still don't have a good understanding of what webAppMount is or what I should 
set it to.
I changed PostResources to JarResources and nothing changed.   The jar files 
are not getting found
or the classes in the jar files are not getting found. 

There is no way this can be this hard and complicated in tomcat 8.

Please help.




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

Force ParallelWebappClassLoader to load instrumentation agent after VM starts

[M. Manna]

Hi,

I was hoping to get some help/suggestion since I have nearly exhausted all
options (at least, I have tried quite a few items).

I have an instrumentation agent which i want to load after the VM starts
tomcat. I have no problem loading the agent itself.

What I am having issues with is the classloader that loads the agent. By
Default System class loader loads any agent as per Instrumentation docs.
But I suppose there might be a trick which can use the same classloader as
the web application e.g. using ParallelWebappClassLoader.

If I do Class.forName() check before the agent is injected
ParallelWebappClassLoader loads my agent class. But as soon as the VM
invokes the agent, I can no longer have the same loader. System class
loader takes over.

Could anyone share any experience in this area so that I can load my agent
with one of Tomcat's app classloaders?

Kindest Regards,

Re: AJP connection pool issue bug?

[Mark Thomas]

On 04/10/17 13:51, TurboChargedDad . wrote:
>  Hello all..
> I am going to do my best to describe my problem.  Hopefully someone will
> have some sort of insight.
> 
> Tomcat 7.0.41 (working on updating that)
> Java 1.6 (Working on getting this updated to the latest minor release)
> RHEL Linux
> 
> I inherited an opti-tenant setup.  Individual user accounts on the system
> each have their own Tomcat instance, each is started using sysinit.  This
> is done to keep each website in its own permissible world so one website
> can't interfere with a others data.
> 
> There are two load balanced apache proxies at the edge that point to one
> Tomcat server (I know I know but again I inherited this)
> 
> Apache lays over the top of tomcat to terminate SSL and uses AJP to
> proxypass to each tomcat instance based on the users assigned port.
> 
> Things have run fine for years (so I am being told anyway) until recently.
> Let me give an example of an outage.
> 
> User1, user2 and user3 all use unique databases on a shared database
> server, SQL server 10.
> 
> User 4 runs on a windows jboss server and also has a database on shared
> database server 10.
> 
> Users 5-50 all run in the mentioned Linux server using tomcat and have
> databases on *other* various shared databases servers but have nothing to
> do with database server 10.
> 
> User 4 had a stored proc go wild on database server 10 basically knocking
> it offline.
> 
>   Now one would expect sites 1-4 to experience interruption of service
> because they use a shared DBMS platform.  However.
> 
> Every single site goes down. I monitor the connections for each site with a
> custom tool.  When this happens, the connections start stacking up across
> all the components. (Proxies all the way through the stack)
> Looking at the AJP connection pool threads for user 9 shows that user has
> exhausted their AJP connection pool threads.  They are maxed out at 300 yet
> that user doesn't have high activity at all. The CPU load, memory usage and
> traffic for everything except SQL server 10 is stable during this outrage.
> The proxies start consuming more and more memory the longer the outrage
> occurs but that's expected as the connection counts stack up into the
> thousands.  After a short time all the sites apache / ssl termination later
> start throwing AJP timeout errors.  Shortly after that the edge proxies
> will naturally also starting throwing timeout errors of their own.
> 
> I am only watching user 9 using a tool that allows me to have insight into
> what's going on using JMX metrics but I suspect that once I get all the
> others instrumented that I will see the same thing. Maxed out AJP
> connection pools.
> 
> Aren't those supposed to be unique per user/ JVM? Am I missing something in
> the docs?
> 
> Any assistance from the tomcat gods is much appreciated.

TL;DR - Try switching to the NIO AJP connector on Tomcat.

Take a look at this session I just uploaded from TomcatCon London last
week. You probably want to start around 35:00 and the topic of thread
exhaustion.

HTH,

Mark

P.S. The other sessions we have are on the way. I plan to update the
site and post links once I have them all uploaded.

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

Re: AJP connection pool issue bug?

[Mark Thomas]

On 4 October 2017 15:17:25 BST, Mark Thomas  wrote:
>On 04/10/17 13:51, TurboChargedDad . wrote:
>>  Hello all..
>> I am going to do my best to describe my problem.  Hopefully someone
>will
>> have some sort of insight.
>> 
>> Tomcat 7.0.41 (working on updating that)
>> Java 1.6 (Working on getting this updated to the latest minor
>release)
>> RHEL Linux
>> 
>> I inherited an opti-tenant setup.  Individual user accounts on the
>system
>> each have their own Tomcat instance, each is started using sysinit. 
>This
>> is done to keep each website in its own permissible world so one
>website
>> can't interfere with a others data.
>> 
>> There are two load balanced apache proxies at the edge that point to
>one
>> Tomcat server (I know I know but again I inherited this)
>> 
>> Apache lays over the top of tomcat to terminate SSL and uses AJP to
>> proxypass to each tomcat instance based on the users assigned port.
>> 
>> Things have run fine for years (so I am being told anyway) until
>recently.
>> Let me give an example of an outage.
>> 
>> User1, user2 and user3 all use unique databases on a shared database
>> server, SQL server 10.
>> 
>> User 4 runs on a windows jboss server and also has a database on
>shared
>> database server 10.
>> 
>> Users 5-50 all run in the mentioned Linux server using tomcat and
>have
>> databases on *other* various shared databases servers but have
>nothing to
>> do with database server 10.
>> 
>> User 4 had a stored proc go wild on database server 10 basically
>knocking
>> it offline.
>> 
>>   Now one would expect sites 1-4 to experience interruption of
>service
>> because they use a shared DBMS platform.  However.
>> 
>> Every single site goes down. I monitor the connections for each site
>with a
>> custom tool.  When this happens, the connections start stacking up
>across
>> all the components. (Proxies all the way through the stack)
>> Looking at the AJP connection pool threads for user 9 shows that user
>has
>> exhausted their AJP connection pool threads.  They are maxed out at
>300 yet
>> that user doesn't have high activity at all. The CPU load, memory
>usage and
>> traffic for everything except SQL server 10 is stable during this
>outrage.
>> The proxies start consuming more and more memory the longer the
>outrage
>> occurs but that's expected as the connection counts stack up into the
>> thousands.  After a short time all the sites apache / ssl termination
>later
>> start throwing AJP timeout errors.  Shortly after that the edge
>proxies
>> will naturally also starting throwing timeout errors of their own.
>> 
>> I am only watching user 9 using a tool that allows me to have insight
>into
>> what's going on using JMX metrics but I suspect that once I get all
>the
>> others instrumented that I will see the same thing. Maxed out AJP
>> connection pools.
>> 
>> Aren't those supposed to be unique per user/ JVM? Am I missing
>something in
>> the docs?
>> 
>> Any assistance from the tomcat gods is much appreciated.
>
>TL;DR - Try switching to the NIO AJP connector on Tomcat.
>
>Take a look at this session I just uploaded from TomcatCon London last
>week. You probably want to start around 35:00 and the topic of thread
>exhaustion.

Whoops. Here is the link.

https://youtu.be/2QYWp1k5QQM

Mark


>
>HTH,
>
>Mark
>
>P.S. The other sessions we have are on the way. I plan to update the
>site and post links once I have them all uploaded.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


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

[ANN] Apache Tomcat 7.0.82 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.82.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.81. The notable changes since 7.0.81 include:


- A fix for CVE-2017-12617.

- Update the packaged version of the Tomcat Native Library to 1.2.14 to pick
  up the latest Windows binaries built with APR 1.6.2 and OpenSSL 1.0.2l.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

Re: Java 9 support + HSTS for tomcat.apache.org

[Konstantin Kolinko]

2017-09-28 19:56 GMT+03:00 Konstantin Kolinko :
> 2017-09-26 11:57 GMT+03:00 Oliver Heister :
>>  2. Currently MITM attacks by evil ISPs or WiFi networks are possible
>> against people downloading tomcat from
>> http://tomcat.apache.org/download-80.cgi . (The page has links to PGP, md5
>> and sha1 hashes for validation, but the links are on a http page that does
>> not redirect to https. This means they could be replaced in case of MITM.)
>>
>> IMO a HTTP 301 redirect to the https version and HSTS headers should be
>> added to http://tomcat.apache.org/ .
>
> The recommended way to validate releases it to check the PGP
> signature, not the checksums.
>
> It is not so easy to compromise a PGP signature. You cannot generate a
> new signature without having a key.
>
>
> I think that HSTS is an overkill.
>
> Maybe update links to *.cgi pages (in menu and on the site) to use https:

I updated XSLT stylesheet that is used to generate the tomcat.apache.org site
so that all links to *.cgi pages are automatically updated to use
https://tomcat.apache.org.

I also updated the links to archive.apache.org, blogs.apache.org,
wiki.apache.org
and ASF fundraising & sponsorship pages to use https.


Best regards,
Konstantin Kolinko

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

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/4/17 12:54 PM, James H. H. Lampert wrote:
> I wrote:
>>> I mean, I know that I need to get HTTPAPI and Tomcat speaking
>>> the same language, but where do I begin?
> Here's what I got back when I ran the SSLLabs server test on the
> cloud server:
> 
>> Protocols TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes TLS 1.0
>> Yes SSL 3 No SSL 2 No
> 
>> Cipher Suites # TLS 1.2 (server has no preference) 
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1
>> (eq. 15360 bits RSA)   FS 128 
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp521r1
>> (eq. 15360 bits RSA)   FS 128 
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1
>> (eq. 15360 bits RSA)   FS 256 
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1
>> (eq. 15360 bits RSA)   FS 256 # TLS 1.1 (server has no
>> preference) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH
>> secp521r1 (eq. 15360 bits RSA)   FS 128 
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1
>> (eq. 15360 bits RSA)   FS 256 # TLS 1.0 (server has no
>> preference) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH
>> secp521r1 (eq. 15360 bits RSA)   FS 128 
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1
>> (eq. 15360 bits RSA)   FS 256
> 
> On the HTTPAPI/FTPAPI list, I was told that HTTPAPI uses the
> operating system's SSL support (which was how I thought it worked),
> and directed to look through the system values to see what it
> supports. What I found was:
> 
> QSSLPCL *SEC Secure sockets layer protocols
>> *OPSYS
> (which I'm pretty sure means that all OS-supported protocols are 
> available; they can also be individually specified as any or all
> of *TLSV1, *SSLV3, and *SSLV2)
> 
> QSSLCSL *SEC Secure sockets layer cipher specification
> list
>> *RSA_AES_128_CBC_SHA *RSA_RC4_128_SHA *RSA_RC4_128_MD5 
>> *RSA_AES_256_CBC_SHA *RSA_3DES_EDE_CBC_SHA *RSA_DES_CBC_SHA 
>> *RSA_EXPORT_RC4_40_MD5 *RSA_EXPORT_RC2_CBC_40_MD5 *RSA_NULL_SHA 
>> *RSA_NULL_MD5
> 
> and unfortunately, IBM doesn't backport new cipher suites to older
> OS releases.

Looks like your server only has ECDHE-based suites available, and the
client supports none of those. Can you post your 
configuration from conf/server.xml?

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnVIfEdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjzgRAAjCWH+md+/fyVZn83
E6TiieaqXHOkD2CSWkgXk0nmG1+Vj2Llf6S/IYblNGeKZw+QY0tSTYVu57z5qE+Q
Hu2bf8o45xJ2QE+GZXbjkknCd+dz1TAyEAwHLAGsgbdhOUSCaeaLCNkk48kN7yoT
H0Y+KKuihHPrDsGJyErM8JUcN591UfBCFQOu44ACU0YaiSmhu6WzEDoDVKY5KitK
kdijejhT55gOkLHUDkwLLgimAEdcRpSSy4NlCitJ2GuXEglBW7mYxnz9aMTC/Pye
JYA9VQvbkPXJQZmX+509H8cXei0AVCtv3hSRW3BsQHsopzGiqy7dGznWq206omd5
5KckRzS5e7dIxyIM3Rt4zg27BDMeA4QEPvO+ADYb7OenYIVAKHi8EvqDgRwAzVYt
t+d79NZVmNl3ISc8Quau+Pjklx9ihgqQXANDQDQoaK0BK/+IGwGHANIbkDxo6WK0
o6cK1iodG0+/eKE8X9cwCIW/xt1pKuXZlKbjE3ZbUHpDWJb2vVYjBowMJ/S7foGm
OlCXeRky99JCckxztxz19glAviokzrL70DwvOSBkyMFZP6ml08byD7S6hxOi8Gk8
iw9EtCnF98fvWbFRzAp43ngBpWNDlNYTwBAqk759wPM7LHiiLejJ1jWM9iOOkw+O
2A1YRhrorJdUMXFRshZbsi9se8U=
=JfBi
-END PGP SIGNATURE-

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

Re: migration from tomcat 7.0 to 8.5

[Konstantin Kolinko]

2017-10-04 17:53 GMT+03:00 Aquatic Safaris Diver :
>
> I've read the migration manuals and have tried to make the changes to
> my configuration to work correctly in tomcat v8.5, but it's not.  I'm
> not an experton XML files and JDK so please help me.   I'm sure this is crazy 
> simple
> for you experts.
>
> The server.xml conf file is OK between the two versions.   But my
> application's deployment is having problems.
>
> In my tomcat v7 conf/Catalina/localhost directory, I have ed.xml file
> for my application containing:
>
> 
> 

"path" cannot be used here, ignored

docBase is rare to be seen here, but OK (it is outside of webapps)

> 
> 
> 
> virtualClasspath="/usr/local/calendar/libs/google-api-client-1.22.0.jar;/usr/local/calendar/google-api-services-calendar-v3-rev230-1.22.0.jar;/usr/local/calendar/libs/google-http-client-1.22.0.jar;/usr/local/calendar/libs/google-http-client-jackson2-1.22.0.jar;/usr/local/calendar/libs/google-oauth-client-1.22.0.jar;/usr/local/calendar/libs/jackson-core-2.1.3.jar"/>
> 
>
> After spending about 6 hours and reading tons of other web posts from
> others trying to do the same thing, I finally have
> something working, kinda.  My web application at least deploys when
> tomcat starts.  The Loader part in the .xml was replaced with:
> 
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/google-api-client-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>
> base="/usr/local/calendar/google-api-services-calendar-v3-rev230-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/google-http-client-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>
> base="/usr/local/calendar/libs/google-http-client-jackson2-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/google-oauth-client-1.22.0.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
>  className="org.apache.catalina.webresources.JarResourceSet"
>base="/usr/local/calendar/libs/jackson-core-2.1.3.jar" 
> webAppMount="/WEB-INF/lib" internalPath="/."/>
> 

I'd use org.apache.catalina.webresources.FileResourceSet.  There is an
example in "Ordering" section here:
http://tomcat.apache.org/tomcat-8.5-doc/config/resources.html#Nested_Components

The docs could be better.

> However, when I access the JSP page that need to resolve classes in these 
> .jar's, I get
> org.apache.jasper.JasperException: Unable to compile class for JSP:
>
> An error occurred at line: [20] in the generated java file: 
> [/work/Catalina/localhost/ed/org/apache/jsp/charters_jsp.java]
> Only a type can be imported. com.google.api.client.json.JsonFactory resolves 
> to a package
>
> Line 20 is:
> import com.google.api.client.json.JsonFactory;

It is odd.
Stacktrace?

In my experience I faced
https://bz.apache.org/bugzilla/show_bug.cgi?id=47323
but it is quite different from your case.

isPackage(className) check mentioned there tries to load (className +
".class") as a resource and reports "true, it is a package" if the
class resource is not found.

> I think I'm up to 12 hours messing with this and reading everything I can get 
> my hands on.
> Something that was so simple in tomcat 7 has turned out to be a nightmare in 
> tomcat 8.
> I still don't have a good understanding of what webAppMount is or what I 
> should set it to.
> I changed PostResources to JarResources and nothing changed.   The jar files 
> are not getting found
> or the classes in the jar files are not getting found.
>
> There is no way this can be this hard and complicated in tomcat 8.
>
> Please help.

Best regards,
Konstantin Kolinko

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

TomcatCon London slides and recordings

[Mark Thomas]

... are now (mostly) available:

http://tomcat.apache.org/presentations.html

I thought Jean-Frederic sent me his slides but I can't find the e-mail.
I'm sure one of us will update that page shortly.

Enjoy!

Mark

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

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[James H. H. Lampert]

I wrote:

I mean, I know that I need to get HTTPAPI and Tomcat speaking the
same language, but where do I begin?
Here's what I got back when I ran the SSLLabs server test on the cloud 
server:



Protocols
TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3   No
SSL 2   No



Cipher Suites
# TLS 1.2 (server has no preference)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS   128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS   256
# TLS 1.1 (server has no preference)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  256
# TLS 1.0 (server has no preference)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits 
RSA)   FS  256


On the HTTPAPI/FTPAPI list, I was told that HTTPAPI uses the operating 
system's SSL support (which was how I thought it worked), and directed 
to look through the system values to see what it supports. What I found was:


QSSLPCL *SEC Secure sockets layer protocols
> *OPSYS
(which I'm pretty sure means that all OS-supported protocols are 
available; they can also be individually specified as any or all of 
*TLSV1, *SSLV3, and *SSLV2)


QSSLCSL *SEC Secure sockets layer cipher specification list

*RSA_AES_128_CBC_SHA
*RSA_RC4_128_SHA
*RSA_RC4_128_MD5
*RSA_AES_256_CBC_SHA
*RSA_3DES_EDE_CBC_SHA
*RSA_DES_CBC_SHA
*RSA_EXPORT_RC4_40_MD5
*RSA_EXPORT_RC2_CBC_40_MD5
*RSA_NULL_SHA
*RSA_NULL_MD5


and unfortunately, IBM doesn't backport new cipher suites to older OS 
releases.


--
JHHL

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

Re: TomcatCon Where (and when) next?

[Mark Thomas]

Thanks for the suggestions. Pulling the various suggestions so far we have:

- Frankfurt, Germany
- Paris, France
- Washington DC, USA
- Manchester, UK

With some of those locations coming with a venue provided and/or
potential for sponsorship.

My current thinking (and this is just my personal view although it is
informed by the suggestions) is:

- Frankfurt
  - possible for March (ish) 2018
  - rjung can get there easily
  - I can get there fairly cheaply

- Paris
  - possible for after Frankfurt - May? (ish) 2018
  - remm is near by
  - I can get there fairly cheaply
  - at least one session in French (so not me for that one)

- Washington
  - too far / expensive for non-US committers without significant
sponsorship
  - maybe wait and see what the plans are for ApacheCon in 2018 and run
TomcatCon alongside it much like we did in Miami

- Manchester
  - possible for January 2018
  - easy for me to get to
  - asking a lot for other committers to travel so soon after London
  - maybe run it more as training / workshop (i.e. large % of hands-on)
rather than a conference as this makes it less of an issue if it is
just me presenting


Between the conference and the recent security issues, I've been rather
busy these last few weeks so I want to take the opportunity to catch up
a bit before starting on the planning for these events. I wanted to get
the above down on email to give folks an opportunity to provide some
feedback.

Also, as previously promised, I've put some notes on the organisation
and finances for the London event on the wiki:

https://cwiki.apache.org/confluence/display/TOMCAT/TomcatCon
https://cwiki.apache.org/confluence/display/TOMCAT/TomcatCon+London+2017

Mark


On 27/09/17 22:14, Mark Thomas wrote:
> All,
> 
> TomcatCon London 2017 took place yesterday and was even more successful
> than hoped. We sold 16 tickets for a full day of content from 3 Tomcat
> committers.
> 
> I'd like to take this opportunity to once again thank our sponsors.
> 
> Liferay generously provided the venue - including all the associated
> organisation. This provided us with a very nice venue, removed a
> significant amount of the organisational overhead and also removed all
> of the financial risk to the PMC members organising the event.
> 
> c2b2 generously purchased 2 tickets and contributed towards the other
> expenses (speaker travel expenses, buying a microphone so we could
> record some of the sessions, name badges, etc,).
> 
> We were able to record 4 out of the 6 sessions and these will be
> uploaded to YouTube and linked from the Tomcat website hopefully by the
> end of the week.
> 
> As planned, the event generated a sufficient surplus to underwrite the
> next event. With this in mind, thoughts are already turning to future
> events.
> 
> We are looking for suggestions for possible locations for the next
> event. Please add your suggestions to this thread.
> 
> Some points to keep in mind:
> 
> - Events close to one or more Tomcat committters will generally have
>   lower overheads due to reduced travel costs. At this point that
>   probably means Europe if the event runs without sponsorship.
> 
> - Sponsorship to cover speaker travel and/or to provide a venue
>   increases the options available with regard to location. I was
>   serious when I said in a previous thread that the next event could be
>   in India if a sponsor offered to provide a venue and cover speaker
>   travel.
> 
> If you'd like to discuss sponsorship options privately, please feel free
> to contact me off-list.
> 
> With regards to timing, the aim is to try and organise one of these
> events every couple of months. That probably means we need to start
> thinking about event N+1 and N+2 in parallel.
> 
> I look forward to your suggestions,
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: AJP connection pool issue bug?

[TurboChargedDad .]

  My initial reads about BIO vs NIO seems to involve terminating SSL at the
tomcat instance.  Which we do not do.  Am I running off into the weeds with
that?

Thanks,
TCD

On Wed, Oct 4, 2017 at 9:17 AM, Mark Thomas  wrote:

> On 04/10/17 13:51, TurboChargedDad . wrote:
> >  Hello all..
> > I am going to do my best to describe my problem.  Hopefully someone will
> > have some sort of insight.
> >
> > Tomcat 7.0.41 (working on updating that)
> > Java 1.6 (Working on getting this updated to the latest minor release)
> > RHEL Linux
> >
> > I inherited an opti-tenant setup.  Individual user accounts on the system
> > each have their own Tomcat instance, each is started using sysinit.  This
> > is done to keep each website in its own permissible world so one website
> > can't interfere with a others data.
> >
> > There are two load balanced apache proxies at the edge that point to one
> > Tomcat server (I know I know but again I inherited this)
> >
> > Apache lays over the top of tomcat to terminate SSL and uses AJP to
> > proxypass to each tomcat instance based on the users assigned port.
> >
> > Things have run fine for years (so I am being told anyway) until
> recently.
> > Let me give an example of an outage.
> >
> > User1, user2 and user3 all use unique databases on a shared database
> > server, SQL server 10.
> >
> > User 4 runs on a windows jboss server and also has a database on shared
> > database server 10.
> >
> > Users 5-50 all run in the mentioned Linux server using tomcat and have
> > databases on *other* various shared databases servers but have nothing to
> > do with database server 10.
> >
> > User 4 had a stored proc go wild on database server 10 basically knocking
> > it offline.
> >
> >   Now one would expect sites 1-4 to experience interruption of service
> > because they use a shared DBMS platform.  However.
> >
> > Every single site goes down. I monitor the connections for each site
> with a
> > custom tool.  When this happens, the connections start stacking up across
> > all the components. (Proxies all the way through the stack)
> > Looking at the AJP connection pool threads for user 9 shows that user has
> > exhausted their AJP connection pool threads.  They are maxed out at 300
> yet
> > that user doesn't have high activity at all. The CPU load, memory usage
> and
> > traffic for everything except SQL server 10 is stable during this
> outrage.
> > The proxies start consuming more and more memory the longer the outrage
> > occurs but that's expected as the connection counts stack up into the
> > thousands.  After a short time all the sites apache / ssl termination
> later
> > start throwing AJP timeout errors.  Shortly after that the edge proxies
> > will naturally also starting throwing timeout errors of their own.
> >
> > I am only watching user 9 using a tool that allows me to have insight
> into
> > what's going on using JMX metrics but I suspect that once I get all the
> > others instrumented that I will see the same thing. Maxed out AJP
> > connection pools.
> >
> > Aren't those supposed to be unique per user/ JVM? Am I missing something
> in
> > the docs?
> >
> > Any assistance from the tomcat gods is much appreciated.
>
> TL;DR - Try switching to the NIO AJP connector on Tomcat.
>
> Take a look at this session I just uploaded from TomcatCon London last
> week. You probably want to start around 35:00 and the topic of thread
> exhaustion.
>
> HTH,
>
> Mark
>
> P.S. The other sessions we have are on the way. I plan to update the
> site and post links once I have them all uploaded.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[James H. H. Lampert]

Christopher Schultz (Tomcat list guru) wrote:


Looks like your server only has ECDHE-based suites available, and the
client supports none of those. Can you post your 
configuration from conf/server.xml?


Yes, and I can also post something else.

I found the Java source for your own "SSLInfo" program (yes, I actually 
do attempt to pursue any line of research that occurs to me, even as I'm 
begging for help), compiled it, and put it onto both the local box where 
the AS/400 is able to connect to the Tomcat server, and on the cloud 
server where it isn't.


On the local box, running Tomcat 7, I get:

java -showversion SSLInfo
java version "1.7.0_131"
OpenJDK Runtime Environment (IcedTea 2.6.9) (7u131-2.6.9-2~deb8u1)
OpenJDK Client VM (build 24.131-b00, mixed mode, sharing)

Default Cipher
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256
*   TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
*   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
*   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
*   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
*   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
*   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
*   TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
*   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
*   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
*   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
*   TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
*   TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
*   TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
*   TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
TLS_ECDH_anon_WITH_NULL_SHA
TLS_ECDH_anon_WITH_RC4_128_SHA
*   TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_RC4_128_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA256
*   TLS_RSA_WITH_AES_256_CBC_SHA
*   TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256
and the relevant connector in server.xml (line breaks added, sensitive 
information redacted) is





On the cloud box, running Tomcat 8, I get:

java -showversion SSLInfo
java version "1.7.0_151"
OpenJDK Runtime Environment (IcedTea 2.6.11) (7u151-2.6.11-1~deb8u1)
OpenJDK 64-Bit Server VM (build 24.151-b01, mixed mode)

Default Cipher
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[James H. H. Lampert]

On 10/4/17, 12:26 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

. . .

Okay so you are in no way interfering with the defaults. That means
you'll get (depending upon your exact versions of various things) a
Tomcat which supports TLSv1 or later, and most of the cipher suites
that are shown as "default" above.

Your choice of TLS certificate may affect some of the things that you
can do, but I see that you've got an RSA certificate from the output
from SSLLabs, so you shouldn't have any problems with a DSS
certificate or anything like that. (Use of DSS certs these days is
fairly rare).

. . .

Strange. I would have expected Tomcat to enable more cipher suites
with a default configuration given the SSLInfo output above.

Are you sure you are using the same Java version with Tomcat as you
did to run those commands above?


Dear Mr. Schultz:
It sure looks like the same Java version. Here is what the manager returns:

Apache Tomcat/8.5.14 (Debian) 1.7.0_151-b01 Oracle Corporation Linux
3.16.0-4-amd64  amd64


It would definitely be helpful if the OS/400 names of the cipher suites 
more precisely matched the Java names. To recap, the QSSLCSL system 
value on the AS/400 shows (using the OS/400 naming conventions)

*RSA_AES_128_CBC_SHA
*RSA_RC4_128_SHA
*RSA_RC4_128_MD5
*RSA_AES_256_CBC_SHA
*RSA_3DES_EDE_CBC_SHA
*RSA_DES_CBC_SHA
*RSA_EXPORT_RC4_40_MD5
*RSA_EXPORT_RC2_CBC_40_MD5
*RSA_NULL_SHA
*RSA_NULL_MD5


--
JHHL

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

Re: AJP connection pool issue bug?

[TurboChargedDad .]

  Perhaps I am not wording my question correctly.

Today we have...
[Prxoy 1]  |  [Proxy 2]   ---> [Apache ---> tomcat1]
(HTTPS) (HTTPS) (HTTPS) --> (AJP) -->

So we send the information from the proxies over https to the instance
running the tomcat server.

The SSL is terminated by Apache/HTTPD and handed back to tomcat over AJP.
Tomcat doesn't handle SSL in anyway.  It can't, it's not configured to do
so.  Is that how you understand the question I asked?

As a test I changed the following line in one of the many tomcat instances
running on the server and bounced it.
Old

New


As the docs state I am able to verify that it did in fact switch over to
NIO.

INFO: Starting ProtocolHandler ["ajp-nio-9335"]


Will running NIO and BIO on the same box have a negative impact?  I am
thinking they should all be switched to NIO, this was just a test to see if
I was understanding what I was reading.  That being said I suspect there
are going to be far more tweaks that needs to be applied as there are none
to date.  I also know that the HTTPD server is running in prefork mode.
Which I think leaves me with no control over how many connections can be
handed back from apache on a site by site basis.
Really having hard time explaining to others how BIO could have caused the
connection pool for another use to become exhausted.

 Thanks,
 TCD



On Wed, Oct 4, 2017 at 1:31 PM, Mark Thomas  wrote:

> On 04/10/17 19:26, TurboChargedDad . wrote:
> >   My initial reads about BIO vs NIO seems to involve terminating SSL at
> the
> > tomcat instance.  Which we do not do.  Am I running off into the weeds
> with
> > that?
>
> Yes. The NIO AJP connector is a drop in replacement for the BIO AJP
> connector.
>
> https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.
> html#Standard_Implementations
>
> Look for the protocol attribute.
>
> Mark
>
>
> >
> > Thanks,
> > TCD
> >
> > On Wed, Oct 4, 2017 at 9:17 AM, Mark Thomas  wrote:
> >
> >> On 04/10/17 13:51, TurboChargedDad . wrote:
> >>>  Hello all..
> >>> I am going to do my best to describe my problem.  Hopefully someone
> will
> >>> have some sort of insight.
> >>>
> >>> Tomcat 7.0.41 (working on updating that)
> >>> Java 1.6 (Working on getting this updated to the latest minor release)
> >>> RHEL Linux
> >>>
> >>> I inherited an opti-tenant setup.  Individual user accounts on the
> system
> >>> each have their own Tomcat instance, each is started using sysinit.
> This
> >>> is done to keep each website in its own permissible world so one
> website
> >>> can't interfere with a others data.
> >>>
> >>> There are two load balanced apache proxies at the edge that point to
> one
> >>> Tomcat server (I know I know but again I inherited this)
> >>>
> >>> Apache lays over the top of tomcat to terminate SSL and uses AJP to
> >>> proxypass to each tomcat instance based on the users assigned port.
> >>>
> >>> Things have run fine for years (so I am being told anyway) until
> >> recently.
> >>> Let me give an example of an outage.
> >>>
> >>> User1, user2 and user3 all use unique databases on a shared database
> >>> server, SQL server 10.
> >>>
> >>> User 4 runs on a windows jboss server and also has a database on shared
> >>> database server 10.
> >>>
> >>> Users 5-50 all run in the mentioned Linux server using tomcat and have
> >>> databases on *other* various shared databases servers but have nothing
> to
> >>> do with database server 10.
> >>>
> >>> User 4 had a stored proc go wild on database server 10 basically
> knocking
> >>> it offline.
> >>>
> >>>   Now one would expect sites 1-4 to experience interruption of service
> >>> because they use a shared DBMS platform.  However.
> >>>
> >>> Every single site goes down. I monitor the connections for each site
> >> with a
> >>> custom tool.  When this happens, the connections start stacking up
> across
> >>> all the components. (Proxies all the way through the stack)
> >>> Looking at the AJP connection pool threads for user 9 shows that user
> has
> >>> exhausted their AJP connection pool threads.  They are maxed out at 300
> >> yet
> >>> that user doesn't have high activity at all. The CPU load, memory usage
> >> and
> >>> traffic for everything except SQL server 10 is stable during this
> >> outrage.
> >>> The proxies start consuming more and more memory the longer the outrage
> >>> occurs but that's expected as the connection counts stack up into the
> >>> thousands.  After a short time all the sites apache / ssl termination
> >> later
> >>> start throwing AJP timeout errors.  Shortly after that the edge proxies
> >>> will naturally also starting throwing timeout errors of their own.
> >>>
> >>> I am only watching user 9 using a tool that allows me to have insight
> >> into
> >>> what's going on using JMX metrics but I suspect that once I get all the
> >>> others instrumented that I will see the same thing. Maxed out AJP
> >>> connection pools.
> >>>
> >>> Aren't those supposed to be 

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/4/17 3:15 PM, James H. H. Lampert wrote:
> Christopher Schultz (Tomcat list guru) wrote:

/me bows

>> Looks like your server only has ECDHE-based suites available, and
>> the client supports none of those. Can you post your  
>> configuration from conf/server.xml?
> 
> Yes, and I can also post something else.
> 
> I found the Java source for your own "SSLInfo" program (yes, I
> actually do attempt to pursue any line of research that occurs to
> me, even as I'm begging for help), compiled it, and put it onto
> both the local box where the AS/400 is able to connect to the
> Tomcat server, and on the cloud server where it isn't.
> 
> On the local box, running Tomcat 7, I get:
>> java -showversion SSLInfo java version "1.7.0_131" OpenJDK
>> Runtime Environment (IcedTea 2.6.9) (7u131-2.6.9-2~deb8u1) 
>> OpenJDK Client VM (build 24.131-b00, mixed mode, sharing)
>> 
>> DefaultCipher SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA 
>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA 
>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA 
>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 
>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 *
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA 
>> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA 
>> SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA *
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA *
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 *
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA *
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 *
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA *
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA *
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
>> TLS_DH_anon_WITH_AES_128_CBC_SHA 
>> TLS_DH_anon_WITH_AES_128_CBC_SHA256 
>> TLS_DH_anon_WITH_AES_256_CBC_SHA 
>> TLS_DH_anon_WITH_AES_256_CBC_SHA256 *
>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA *
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA *
>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 *
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA *
>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
>> TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA *
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA *
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA *
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA *
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 
>> TLS_ECDHE_RSA_WITH_NULL_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA *
>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA *
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA *
>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 *
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA *
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 
>> TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA *
>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA *
>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA *
>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA *
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_NULL_SHA 
>> TLS_ECDH_RSA_WITH_RC4_128_SHA 
>> TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA 
>> TLS_ECDH_anon_WITH_AES_128_CBC_SHA 
>> TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_NULL_SHA 
>> TLS_ECDH_anon_WITH_RC4_128_SHA *
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 
>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA 
>> TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_SHA 
>> TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_SHA 
>> TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_WITH_DES_CBC_SHA 
>> TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_RC4_128_SHA *
>> TLS_RSA_WITH_AES_128_CBC_SHA *
>> TLS_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_RSA_WITH_AES_256_CBC_SHA *
>> TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_NULL_SHA256

Right. That confirms that your Tomcat 7 server supports quite a few
cipher suites, many of which are enabled by default. On that server,
you'd have to specifically disable them in order for them not to work.
(Some of them might be SSLv3 cipher suites, and would be disabled
along with that protocol, but most cipher suites are for a "protocol X
or higher" kind of thing).

> and the relevant connector in server.xml (line breaks added,
> sensitive information redacted) is
> 
>> > protocol="org.apache.coyote.http11.Http11Protocol" 
>> compression="on" compressionMinSize="2048" 
>> noCompressionUserAgents="gozilla, traviata" 
>> compressableMimeType="text/html,text/xml,text/plain,text/css,text/jav
ascript,text/json,
>>
>>
>> 
application/x-javascript,application/javascript,application/json"
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true" 
>> maxPostSize="10485760" 
>> keystoreFile="/usr/share/apache-tomcat-7.0.57/$" 
>> keyAlias="" clientAuth="false" sslProtocol="TLS" />

Okay so you are in no way interfering with the defaults. That means
you'll get (depending upon your exact versions of 

Re: encodeURL, jsessionid and mod_rewrite ?

[Laurent Perez]

Thanks for the replies. The jsessionid/cookie tracking mode is not really
part of the problem, sorry about that.

Obviously I'm thinking about renaming the war but the rewriting is really
used, for example seo friendly urls like /bar/steps/1 internally rewrite to
/foo/somesubmodule/steps.jsp?step=1 and the system really can't expose
/somesubmodule/steps.jsp?step=1 as public urls, it messes with google
analytics stats or bookmarked urls.

As last resort I could move the apache RewriteRules to tuckey urlrewriter
under the war itself and just keep the ProxyPasses under apache.
Configuration & docs would be in a sole space.

I know that just because I /can/ do nasty rewriting stuff at the response
wrapper level I may not want to do it. The replies were useful ;)

regards


On Wed, Oct 4, 2017 at 9:58 AM, André Warnier (tomcat) 
wrote:

> On 04.10.2017 07:40, Peter Kreuser wrote:
>
>>
>> Peter Kreuser
>>
>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz <
>>> ch...@christopherschultz.net>:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Laurant,
>>>
>>> On 10/3/17 5:17 PM, Laurent Perez wrote:
 I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
 "foo" war is deployed at /foo context path under tomcat. The /foo
 path is not public, apache has a rewrite rule defined as : /bar/*
 rewrites internally to /foo/*.

 I'm using jstl and its  for every url in my
 jsps to gain the ;jsessionid from encodeURL whenever jsessionid
 cookie is not yet set (1st requests)


>> adding to Christopher, accepting the jsessionid from the Url is a bad
>> security risk (Session fixation). So you should disable that by accepting
>> the session only via COOKIE via
>>
>> COOKIE 
>> then at least this rewriting problem is gone.
>>
>> Peter
>>
>>
> Well, a cookie can also be path-specific.  Which is only *one* of these
> issues which we are talking about, when we say "don't".
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
http://laurentperez.fr
J2EE, HTML5, JS, CSS3

Re: AJP connection pool issue bug?

[Mark Thomas]

On 04/10/17 19:26, TurboChargedDad . wrote:
>   My initial reads about BIO vs NIO seems to involve terminating SSL at the
> tomcat instance.  Which we do not do.  Am I running off into the weeds with
> that?

Yes. The NIO AJP connector is a drop in replacement for the BIO AJP
connector.

https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html#Standard_Implementations

Look for the protocol attribute.

Mark


> 
> Thanks,
> TCD
> 
> On Wed, Oct 4, 2017 at 9:17 AM, Mark Thomas  wrote:
> 
>> On 04/10/17 13:51, TurboChargedDad . wrote:
>>>  Hello all..
>>> I am going to do my best to describe my problem.  Hopefully someone will
>>> have some sort of insight.
>>>
>>> Tomcat 7.0.41 (working on updating that)
>>> Java 1.6 (Working on getting this updated to the latest minor release)
>>> RHEL Linux
>>>
>>> I inherited an opti-tenant setup.  Individual user accounts on the system
>>> each have their own Tomcat instance, each is started using sysinit.  This
>>> is done to keep each website in its own permissible world so one website
>>> can't interfere with a others data.
>>>
>>> There are two load balanced apache proxies at the edge that point to one
>>> Tomcat server (I know I know but again I inherited this)
>>>
>>> Apache lays over the top of tomcat to terminate SSL and uses AJP to
>>> proxypass to each tomcat instance based on the users assigned port.
>>>
>>> Things have run fine for years (so I am being told anyway) until
>> recently.
>>> Let me give an example of an outage.
>>>
>>> User1, user2 and user3 all use unique databases on a shared database
>>> server, SQL server 10.
>>>
>>> User 4 runs on a windows jboss server and also has a database on shared
>>> database server 10.
>>>
>>> Users 5-50 all run in the mentioned Linux server using tomcat and have
>>> databases on *other* various shared databases servers but have nothing to
>>> do with database server 10.
>>>
>>> User 4 had a stored proc go wild on database server 10 basically knocking
>>> it offline.
>>>
>>>   Now one would expect sites 1-4 to experience interruption of service
>>> because they use a shared DBMS platform.  However.
>>>
>>> Every single site goes down. I monitor the connections for each site
>> with a
>>> custom tool.  When this happens, the connections start stacking up across
>>> all the components. (Proxies all the way through the stack)
>>> Looking at the AJP connection pool threads for user 9 shows that user has
>>> exhausted their AJP connection pool threads.  They are maxed out at 300
>> yet
>>> that user doesn't have high activity at all. The CPU load, memory usage
>> and
>>> traffic for everything except SQL server 10 is stable during this
>> outrage.
>>> The proxies start consuming more and more memory the longer the outrage
>>> occurs but that's expected as the connection counts stack up into the
>>> thousands.  After a short time all the sites apache / ssl termination
>> later
>>> start throwing AJP timeout errors.  Shortly after that the edge proxies
>>> will naturally also starting throwing timeout errors of their own.
>>>
>>> I am only watching user 9 using a tool that allows me to have insight
>> into
>>> what's going on using JMX metrics but I suspect that once I get all the
>>> others instrumented that I will see the same thing. Maxed out AJP
>>> connection pools.
>>>
>>> Aren't those supposed to be unique per user/ JVM? Am I missing something
>> in
>>> the docs?
>>>
>>> Any assistance from the tomcat gods is much appreciated.
>>
>> TL;DR - Try switching to the NIO AJP connector on Tomcat.
>>
>> Take a look at this session I just uploaded from TomcatCon London last
>> week. You probably want to start around 35:00 and the topic of thread
>> exhaustion.
>>
>> HTH,
>>
>> Mark
>>
>> P.S. The other sessions we have are on the way. I plan to update the
>> site and post links once I have them all uploaded.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


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

Re: TomcatCon London slides and recordings

[Stefan Mayr]

Hi

Am 04.10.2017 um 19:27 schrieb Mark Thomas:
> ... are now (mostly) available:
> 
> http://tomcat.apache.org/presentations.html
> 
> I thought Jean-Frederic sent me his slides but I can't find the e-mail.
> I'm sure one of us will update that page shortly.

Reverse Proxies, Load-Balancing & Clustering - Part 1 and Part 2 link
the same slides.

Regards,

  Stefan

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

Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/4/17 3:44 PM, James H. H. Lampert wrote:
> On 10/4/17, 12:26 PM, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> James,
> . . .
>> Okay so you are in no way interfering with the defaults. That
>> means you'll get (depending upon your exact versions of various
>> things) a Tomcat which supports TLSv1 or later, and most of the
>> cipher suites that are shown as "default" above.
>> 
>> Your choice of TLS certificate may affect some of the things that
>> you can do, but I see that you've got an RSA certificate from the
>> output from SSLLabs, so you shouldn't have any problems with a
>> DSS certificate or anything like that. (Use of DSS certs these
>> days is fairly rare).
> . . .
>> Strange. I would have expected Tomcat to enable more cipher
>> suites with a default configuration given the SSLInfo output
>> above.
>> 
>> Are you sure you are using the same Java version with Tomcat as
>> you did to run those commands above?
> 
> Dear Mr. Schultz:

"Chris" is fine. We're all friends, here.

> It sure looks like the same Java version. Here is what the manager
> returns:
>> Apache Tomcat/8.5.14 (Debian) 1.7.0_151-b01 Oracle Corporation 
>> Linux 3.16.0-4-amd64 amd64
> 
> It would definitely be helpful if the OS/400 names of the cipher
> suites more precisely matched the Java names. To recap, the QSSLCSL
> system value on the AS/400 shows (using the OS/400 naming
> conventions)
>> *RSA_AES_128_CBC_SHA *RSA_RC4_128_SHA *RSA_RC4_128_MD5 
>> *RSA_AES_256_CBC_SHA *RSA_3DES_EDE_CBC_SHA *RSA_DES_CBC_SHA 
>> *RSA_EXPORT_RC4_40_MD5 *RSA_EXPORT_RC2_CBC_40_MD5 *RSA_NULL_SHA 
>> *RSA_NULL_MD5

If you know how to "read" cipher suite descriptions, the differences
don't matter much. They are all made-up of the following components:

1. protocol (not shown in OpenSSL-style names, like those above)
2. authentication algorithm (usually RSA, ECDH, or ECDHE)
3. bulk (symmetric) cipher algorithm (e.g. RC4, AES-128, 3DES, Camellia)
   This includes the "block cipher mode e.g. CBC, GCM, etc.)
4. signature algorithm (e.g. MD5, SHA, etc.)

The differences between the cipher suite names in different tools
comes down to how expressive they are. For example, Java says "SSL_"
or "TLS_" before every cipher, but that's largely useless. Some names
in different dialects show different levels of detail about the
underlying algorithms, or are more readable.

Take this one for example. Java (and SSLLabs) calls it
"TLS_RSA_WITH_AES_128_CBC_SHA" but the same algorithm is called
"RSA_AES_128_CBC_SHA" by OpenSSL and similar tools. It's all still in
there.. it's just that OpenSSL doesn't bother with the "TLS_" prefix
and the "_WITH_" embedded in the middle.

When it all comes down to it, the TLS (nee SSL) spec defines certain
cipher suites by "cipher id" which is a numeric, explicitly-defined
set of crypto primitives combined into a "cipher suite", which will be
negotiated by the client and server when they perform their initial
handshake.

You can read all the gory details here[1]. For example, the
aforementioned RSA_AES_128_CBC_SHA cipher suite is cipher 0x2F. It
doesn't matter what the tool calls it; cipher 0x2f always has
those criteria. Of course, they aren't very readable.

That document is a bit out of date, but it does show you how things
were back in 2009, and makes you wonder why it took so damned long for
The World to adopt TLSv1.2.

- -chris

[1] https://www.thesprawl.org/research/tls-and-ssl-cipher-suites/
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnVR4odHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiQORAAsV9+BFL06kve1kCU
y42ojIStrzWvoE8yKxVxjfTL1DuaGiLMtmiS+/QfeJWL2E5lWCbolA2i+BDJ5wQB
4MH7iVBbKpRxodyDUuoVI9IE3zuYYxe8bQnVbyfkCl8a1WPGTjAURqFTQHJ3UqI4
CGN1LzQrvVBzJ6WjMu8tOTjm5758pJhI3kwfJ/NSw6gOXguhwMC9uTtxhzhBm1TE
+vIOCccuqjpo/tAZRBK6OPtBHA5yydQjk+vEpUdvurV+vLlSkV+7bpmymWVZtJKF
4XaDuCglKeHYut2/CcEW3+D2JuCjHH6FD08Qp/ft4NiDNG8gPfrO4KBaXd+dQ6Hq
DF6/fvcTQacXpyuPJ5FShXjgd9hweBD4GC1D4pzkdfXtMUtBzlB6PzDNd72Tqq6w
Uf3fgfiVnEZ6ObMonGyX7LcxCRh3yWVA/WzgexBbFxk3WNkvM6/vcbk4+CfPuPuF
sVnw8OzmxeT5nmyy4oNxiAxM93W0CTxA3yPEN/ETSwKvgVlmWyCfmtP1+lq20OZh
JedWCjG4+QmCWk4U1RdKWnl0Dxzk0vTAkrT7REGf084pDc4JiZUjA5/FJgdvq7V6
nDFrkVmXnOaCtk3L0p0NVEodXlqSdOaO/6qF+MqNLIKAdNRgDqRAI4gggM4GlBhf
kYqj6DPpSrNxGE0jd0Eub3dB3RA=
=iFq6
-END PGP SIGNATURE-

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

Re: [OT] Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 10/4/17 12:54 PM, James H. H. Lampert wrote:
> On the HTTPAPI/FTPAPI list, I was told that HTTPAPI uses the
> operating system's SSL support (which was how I thought it worked),
> and directed to look through the system values to see what it
> supports. What I found was:
> 
> QSSLPCL *SEC Secure sockets layer protocols
>> *OPSYS
> (which I'm pretty sure means that all OS-supported protocols are 
> available; they can also be individually specified as any or all
> of *TLSV1, *SSLV3, and *SSLV2)
> 
> QSSLCSL *SEC Secure sockets layer cipher specification
> list
>> *RSA_AES_128_CBC_SHA *RSA_RC4_128_SHA *RSA_RC4_128_MD5 
>> *RSA_AES_256_CBC_SHA *RSA_3DES_EDE_CBC_SHA *RSA_DES_CBC_SHA 
>> *RSA_EXPORT_RC4_40_MD5 *RSA_EXPORT_RC2_CBC_40_MD5 *RSA_NULL_SHA 
>> *RSA_NULL_MD5
> 
> and unfortunately, IBM doesn't backport new cipher suites to older
> OS releases.

Unfortunately, these ciphers suites should no longer be used for
several reasons:

>> *RSA_RC4_128_SHA *RSA_RC4_128_MD5

Use RC4 bulk cipher algorithm, which is known[1] to be weak.

>> *RSA_EXPORT_RC4_40_MD5 *RSA_EXPORT_RC2_CBC_40_MD5

Export-grade encryption. No better than rot13[2].

>> *RSA_NULL_SHA *RSA_NULL_MD5

rot26! Twice as good!

>> *RSA_DES_CBC_SHA

Hideously outdated. I'm sorry, I don't have a reference for this one,
but...

>> *RSA_3DES_EDE_CBC_SHA

3DES (triple DES... literally DES(DES(DES(message is considered
weak[3], so... single-DES is weak(weak(weak(encryption))).

>> *RSA_AES_128_CBC_SHA *RSA_AES_256_CBC_SHA

Sadly, these remaining cipher suites use CBC mode which is also
weak[4] when used with TLSv1 and earlier. Using TLSv1.2 mitigates
these issues. Use of GCM would be better if you can use them. If this
is all the client supports, then that's what you'll have to live with.
But *definitely* disable all the other algorithms if you care even a
little bit about your traffic.

Are you able to use any other kind of client?

Hope that helps,
- -chris


[1]
https://blog.qualys.com/ssllabs/2013/03/19/rc4-in-tls-is-broken-now-what
[2]
https://nakedsecurity.sophos.com/2015/03/04/the-freak-bug-in-tlsssl-what
- -you-need-to-know/
[3]
https://community.qualys.com/thread/16555-triple-des-is-bad-now-sweet-32
- -cve-2016-2183-cve-2016-6329
[4] https://blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls (CBC=wea
k)
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnVRNwdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhWkRAAkSaTqa3OPol82FGw
6LSkLouidyLWyry/WC60h326qbKZoVCoviCfkgRNQAd4lqqiClAncAW1Wl9/4V3d
ijBCI/zDHzGXnsIzG8bQ5cz17FWSQIIWx02nb9VYha3t5MUGes3LHw3EStK/mKWU
6PcX50rm6XJssyUJLLvxKttRtBmEwXfJ1iklRvYhk2P5a35Sq4jp3hO3asZQ7S/L
xAuBTX3vVl0HI2Zonl8486vdNrj/sEFow8DgudfJ86zXh2eLjLOgQhsL2V1ly2+U
ButFwpTjqJTsrWIJcCdqJkJqeHm7oakPt9oVAr2tnltBz1Lxh23eXxTc4IxYTH/g
0IYywgcDdXlWF3T0aT50/sO8c/G3FiyaRvw0Q4q5Ifu9yq75EdGf8WgvXSH9iZYJ
Xh+ozw2wIOTBTcthf+QKQJ5boNjD88f9IyW5PG09ZS3NiSR5BrHDI5dZNuflQ4u/
uVILyZVmNl30MotfJP8FtaWO5VBtnZvh674QmgVpg5IUFMkGo1fIHjBy3NfQaRLt
fW5GvMemGAfATjFh6ElrkmKb6Whkz6qi27+OIZzpGHumN+ZJ7t5u9wy41UMgUqPl
UTJmTUko9vlQkxCtcOrNcWVPAtzFRVBMYROyvUMb1ePwGugeiF36UEtybqjKVR8Z
LEK/qYLdjWFBTc2JqkPBnlslSe4=
=KGQL
-END PGP SIGNATURE-

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

Re: AJP connection pool issue bug?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

TCD,

On 10/4/17 3:45 PM, TurboChargedDad . wrote:
> Perhaps I am not wording my question correctly.

Can you confirm that the connection-pool exhaustion appears to be
happening on the AJP client (httpd/mod_proxy_ajp) and NOT on the
server (Tomcat/AJP)?

If so, the problem will likely not improve by switching-over to an
NIO-based connector on the Tomcat side.

Having said that, the real problem is likely to be simple arithmetic.
Remember this expression:

Ctc = Nhttpd * Cworkers

Ctc = Connections Tomcat should be prepared to accept (e.g. Connector
maxConnections)

Nhttpd = # of httpd servers
Cworkers = total # of connections in httpd connection pool for all
workers(!!)

Imagine the following scenario:

Nhttpd = 2
Cworker = 200
Ntomcat = 2

On httpd server A, we have a connection pool with 200 connections. If
Tomcat A goes down, all 200 connections will go to Tomcat B. If that
happens to both proxies (Tomcat A stops responding), then both proxies
will send all 200 connections to Tomcat B. That means that Tomcat B
needs to be able to support 400 connections, not 200.

Let's say you now have 5 workers (1 for each application). Each worker
gets its own connection pool, and each connection pool has 200 workers
in it. Now, we have a situation where each httpd instance actually has
1000 (potential) connections in the connection pool, and if Tomcat A
goes down, Tomcat B must be able to handle 2000 connections (1000 from
httpd A and 1000 from httpd B).

At some point, you can't provision enough threads to handle all of
those connections.

The solution (bringing this back around again) is to use NIO, because
you can handle a LOT more connections with a lower number of threads.
NIO doesn't allow you to handle more *concurrent* traffic (in fact, it
makes performance a tiny bit worse than BIO), but it will allow you to
have TONS of idle connections that aren't "wasting" request-processing
threads that are just waiting for another actual request to come
across the wire.

> As a test I changed the following line in one of the many tomcat
> instances running on the server and bounced it. Old  New  protocol="org.apache.coyote.ajp.AjpNioProtocol" redirectPort="8443"
> maxThreads="300" />

Yep, that's how to do it.

> As the docs state I am able to verify that it did in fact switch
> over to NIO.
> 
> INFO: Starting ProtocolHandler ["ajp-nio-9335"]

Good. Now you can handle many idle connections with the same number of
threads.

> Will running NIO and BIO on the same box have a negative impact?

No.

> I am thinking they should all be switched to NIO, this was just a 
> test to see if I was understanding what I was reading.
I would recommend NIO in all cases.

> That being said I suspect there are going to be far more tweaks
> that needs to be applied as there are none to date.

Hopefully not. A recent Tomcat (which you don't actually have) with a
stock configuration should be fairly well-configured to handle a great
deal of traffic without falling-over.

> I also know that the HTTPD server is running in prefork mode.
That will pose some other issues for you, mostly the ability to handle
bursts of high concurrency from your clients. You can consider it
out-of-scope for this discussion, though. What we want to do for you
is stop httpd+Tomcat from freaking out and getting stopped-up with
even a small number of users.

> Which I think leaves me with no control over how many connections
> can be handed back from apache on a site by site basis.

Probably not on a site-by-site basis, but you can adjust the
connection-pool size on a per-worker basis. For prefork it MUST BE
connection_pool_size=1 (the default for prefork httpd) and for
"worker" and similarly-threaded MPMs the default should be fine to use.

> Really having hard time explaining to others how BIO could have 
> caused the connection pool for another use to become exhausted.
Well...

If one of your Tomcats locks-up (database is dead; might want to check
to see how the application is accessing that... infinite timeouts can
be a real killer, here), it can tie-up connections from
mod_proxy_ajp's connection pool. But those connections should be
per-worker and shouldn't interfere with each other. Unless you have an
uber-worker that handles everything for all those various Tomcats.

Can you give us a peek at your worker configuration? You explained it
a bit in your first post, but it might be time for some more details...

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnVTB0dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjbSw/9EyMkmQHZicehVjGg
tueSx+0mgVPEAmrVK/ZFVM2W0zlh4xPjh+O2SS7h3ppfOEB8cMrz3qcmAYEIK8QV
vgBieXP7CPo80/TIklJXFz50fl/T4xEGSwtJ91+U9O10Py/0QzJVRqT8ac+EinQH
fiCmkJKpxwCHxvUyziTGyT/H9xkb885ElXxG/KnoTwJ/r4Fph18I4kEj+KPA/2Gd

Re: TomcatCon London slides and recordings

[Mark Thomas]

On 4 October 2017 21:28:24 BST, Stefan Mayr  wrote:
>Hi
>
>Am 04.10.2017 um 19:27 schrieb Mark Thomas:
>> ... are now (mostly) available:
>> 
>> http://tomcat.apache.org/presentations.html
>> 
>> I thought Jean-Frederic sent me his slides but I can't find the
>e-mail.
>> I'm sure one of us will update that page shortly.
>
>Reverse Proxies, Load-Balancing & Clustering - Part 1 and Part 2 link
>the same slides.

Correct. The deck covers both.

Mark


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