Viewing Tomcat DB connection statement cache size via JMX MBeans

[Manisha Sapiah]

Hi,

I want to know, is there any way to get Tomcat DB connection statement cache 
size via JMX MBeans. Thanks in advance.

Manisha

Tomcat 7 and SHA-1

[Greg Beresnev]

Hi,

We're in the process of updating our web application to stop using SHA-1
certificates and I was wondering if there was some way to configure Tomcat
(we're on version 7.0.39 - yes, I know, we are pretty old-school and should
get with the times) to either throw errors or at least log warnings for the
cases where connection/authentication attempt is being made using SHA-1
certificate?

thanks,
Greg

Re: Need help setting up SSL on Tomcat 8

[Philip Hachey]

On 16-06-29 09:08 AM, Sean Son wrote:

Hello Daniel

Thank you for the information. Here is the output of the keytool command:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

root, Jun 16, 2016, trustedCertEntry,
Certificate fingerprint (SHA1):
27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
{b81d8607-57e9-4c35-a058-cd46099e7797}, Jun 16, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1):
6C:67:52:63:6B:EF:A2:3D:CD:A7:CB:64:99:99:4F:9C:3E:85:B9:AA


Is it possible that the error that I am seeing, is related to the fact that
I am using a wildcard certificate?


Thanks

I'm not familiar with this configuration.  My keystore -list generates this:
***
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

tomcat, 11-Apr-2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): ...
***

That's what you should have too if you're simply following the quick 
start rules here 
[https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html].  Point your 
browser to "https://localhost:8443/;


I also get a browser warning when using this keystore, but it's 
net::ERR_CERT_AUTHORITY_INVALID which I would expect because I haven't 
registered with a root authority (i.e. it's a self-signed certificate).  
I would start with that.  If you then need to use an authority-signed 
certificate, I personally don't have any immediate knowledge when it 
comes to Tomcat, but I imagine it should be only slightly more complex.




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

Re: tomcat 7 connection pool validation interval

[Phil Steitz]

> On Jun 30, 2016, at 9:32 AM, Nir Dweck  wrote:
> 
> I am using tomcat connection  pool (tomcat 7) in my application (java 
> application) to connect to a remote Oracle DB on an Azure machine. My 
> connection pool configuration is as follow:
> 
>PoolProperties p = new PoolProperties();
>p.setUrl(connString);
>p.setUsername(user);
>p.setPassword(password);
>p.setDriverClassName("oracle.jdbc.OracleDriver");
>p.setValidationQuery("SELECT 1 from dual");
>p.setValidationInterval(1 * 6/2);
>p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
>p.setTestOnBorrow(true);
>p.setTestWhileIdle(true);
>p.setMinIdle(10);
>p.setInitialSize(10);
> However looking at the capture file, I see that the connections are not 
> checked every 30 seconds as I expected. One connection is checked correctly, 
> the others are checked after 3 times the configuration (180 second). then 
> again only some of the connections are checked and after a while it seems to 
> stable on twice the configuration period (every 60 seconds).
> 
> I tested it with different configured time and different pool size, all had a 
> instability period in which each time only part of the connections were 
> checked and eventually it stabled on checks of all the connections every 
> twice the configured time.
> What am I missing?
> Thanks,

Most likely the connections not being tested are checked out to clients when 
the pool maintenance runs.  Assuming you are using the default DBCP pool, only 
idle connections (meaning waiting in the pool)  are tested by the maintenance 
thread.

Phil
> 
> Nir

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

tomcat 7.0.55 jdbc pool "Not a wrapper of oracle.jdbc.OracleConnection"

[Balana, Vishal]

I have following resource configuration for Oracle Data source Pool and trying 
to unwrap the connection object using:

OracleConnection conn = connection.unwrap(OracleConnection.class);

And getting following exception:

com.sun.proxy.$Proxy77.unwrap
exception : java.sql.SQLException: Not a wrapper of oracle.jdbc.OracleConnection

Anybody has any idea what is missing here?





Thanks,
Vishal

tomcat 7 connection pool validation interval

[Nir Dweck]

I am using tomcat connection  pool (tomcat 7) in my application (java 
application) to connect to a remote Oracle DB on an Azure machine. My 
connection pool configuration is as follow:

PoolProperties p = new PoolProperties();
p.setUrl(connString);
p.setUsername(user);
p.setPassword(password);
p.setDriverClassName("oracle.jdbc.OracleDriver");
p.setValidationQuery("SELECT 1 from dual");
p.setValidationInterval(1 * 6/2);
p.setTimeBetweenEvictionRunsMillis(1 * 6/2);
p.setTestOnBorrow(true);
p.setTestWhileIdle(true);
p.setMinIdle(10);
p.setInitialSize(10);
However looking at the capture file, I see that the connections are not checked 
every 30 seconds as I expected. One connection is checked correctly, the others 
are checked after 3 times the configuration (180 second). then again only some 
of the connections are checked and after a while it seems to stable on twice 
the configuration period (every 60 seconds).

I tested it with different configured time and different pool size, all had a 
instability period in which each time only part of the connections were checked 
and eventually it stabled on checks of all the connections every twice the 
configured time.
What am I missing?
Thanks,

Nir

Re: How to configure SPNEGO authentication with fallback to FORM auth?

[ken edward]

I did get it to work. Simply merged existing spnego and form auth valves
together, I will try to post later..

On Fri, Jun 24, 2016 at 6:21 PM, Terence M. Bandoian 
wrote:

> On 6/24/2016 10:45 AM, ken edward wrote:
>
>> On Fri, Jun 24, 2016 at 11:26 AM, Mark Thomas  wrote:
>>
>> On 24/06/2016 16:17, ken edward wrote:
>>>
 On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas  wrote:

 On 24 June 2016 14:22:32 BST, ken edward  wrote:
>
>> Hello,
>>
>> I have tomcat 8 on linux, configured with kerberos/SPNEGO
>> authentication.
>> All works well, but if the client cannot use kerberos to authenticate,
>> it
>> will not fallback to FORM authentication.
>>
>> I see some references that tomcat 8 does not do fallback negotiation
>> for
>> FORM auth. True?
>>
> Yes
>
> Any workarounds?
>>
> Nothing simple. Both SPNEGO and FORM have their complications. You'll
>
 need
>>>
 to code some form of custom solution.
>
> Have a look in the archives. This has come up before and I think there
>
 is
>>>
 some sample code that might get you most of the way there.
>
>
>
> I had already searched the mail archives, and did not see any sample

>>> code.
>>>
 If anyone has any insight, please do post some code fragments.

>>> I was thinking of this:
>>> http://wiki.apache.org/tomcat/SSLWithFORMFallback
>>>
>>> Not quite what you are looking for but it might help.
>>>
>>>
>>> I guess I need to extend the SPNEGO valve code in tomcat 8 to handle
>> fallback to FORM auth, similar to SSLWIthFORMFallback. aaarg. Such a
>> simple
>> and essential use case. Perplexing that it is not implemented.
>>
>>
>
> If you get it working, you might consider submitting a patch.  Doing so
> might save someone else from cursing under their breath.
>
> -Terence Bandoian
> http://www.tmbsw.com/
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: mod-jk (1.2.37) crashes Apache 2 (2.4.7) occasionally with a buffer overflow on Ubuntu 14.04 x64

[Michael Diener]

Thank you Rainer!

On 29 June 2016 at 14:50, Rainer Jung  wrote:

> Can you reproduce? Does it also happen on a test system?


It only happens on a live system and I'm not able to reproduce it.



> Latest we provide in the project is 1.2.41. It is pretty easy to compile
> yourself and would be an interesting check to see, whether it is just an
> old already fixed problem.



You are right, I will test and get back.


Viele Grüße,
Michael


--

Re: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service

[Mark Thomas]

On 30/06/2016 09:20, Kyohei Nakamura wrote:
> Hi,
> 
> I have a question about the maxHttpHeaderSize.
> 
> In this announcement, the recommended value is 3072 bytes.
> However, in the announcement from the Apache Commons project, the
> recommended value is 2048 bytes.
> http://mail-archives.apache.org/mod_mbox/www-announce/201606.mbox/%3c45a20804-abff-4fed-a297-69ac95ab9...@apache.org%3E
> 
> If an application uses the Apache Commons FileUpload (not use the
> Tomcat File Upload feature), which one should I use? "3072" or "2048".

Use the lowest value you can that doesn't cause your application to break.

Better still, just update the version of Commons FileUpload you are
using so you don't need this work-around.

Mark


> 
> 
> 2016-06-22 19:02 GMT+09:00 Mark Thomas :
>> Note: This announcement corrects several errors and omissions in the
>> Tomcat aspects of the announcement for CVE-2016-3092 from the Apache
>> Commons project that was recently forwarded to various Apache Tomcat
>> mailing lists.
>>
>> For the sake of clarity, the Tomcat specific corrections are as follows:
>> 1. This is a Denial of Service vulnerability, not an Information
>> Disclosure vulnerability.
>> 2. Apache Tomcat 8.5.x is also affected. The vulnerability exists in
>> 8.5.0 to 8.5.2 and affected users of 8.5.x should upgrade to 8.5.3.
>> 3. Apache Tomcat 6.x and earlier are not affected.
>> 4. Applications that do not use the File Upload feature introduced in
>> Servlet 3.0 are not vulnerable via Tomcat.
>>
>> A corrected announcement, for Tomcat only, follows.
>>
>>
>> CVE-2016-3092: Apache Tomcat Denial of Service
>>
>> Severity: Moderate
>>
>> Vendor:
>> The Apache Software Foundation
>>
>> Versions Affected:
>> Apache Tomcat 9.0.0.M1 to 9.0.0M6
>> Apache Tomcat 8.5.0 to 8.5.2
>> Apache Tomcat 8.0.0.RC1 to 8.0.35
>> Apache Tomcat 7.0.0 to 7.0.69
>> Earlier versions are not affected.
>>
>> Description:
>> CVE-2016-3092 is a denial of service vulnerability that has been
>> corrected in the Apache Commons FileUpload component. It occurred when
>> the length of the multipart boundary was just below the size of the
>> buffer (4096 bytes) used to read the uploaded file. This caused the file
>> upload process to take several orders of magnitude longer than if the
>> boundary length was the typical tens of bytes.
>>
>> Apache Tomcat uses a package renamed copy of Apache Commons FileUpload
>> to implement the file upload requirements of the Servlet specification
>> and was therefore also vulnerable to the denial of service vulnerability.
>>
>> Applications that do not use the File Upload feature introduced in
>> Servlet 3.0 are not affected by the Tomcat aspect of this vulnerability.
>> If those applications use Apache Commons FileUpload, they may still be
>> affected.
>>
>> Mitigation:
>> Users of affected versions should apply one of the following mitigations
>> - Upgrade to Apache Tomcat 9.0.0.M8 or later
>>   (9.0.0.M7 has the fix but was not released)
>> - Upgrade to Apache Tomcat 8.5.3 or later
>> - Upgrade to Apache Tomcat 8.0.36 or later
>> - Upgrade to Apache Tomcat 7.0.70 or later
>>
>> Workaround:
>> The issue may be mitigated by limiting the length of the boundary.
>> Applications could do this with a custom Filter to reject requests that
>> use large boundaries.
>> Tomcat provides the maxHttpHeaderSize attribute on the Connector that
>> can be used to limit the total HTTP header size. Users should be aware
>> that reducing this to 3072 (which should be low enough to protect
>> against this DoS) may cause other issues as applications can require
>> larger headers than this for correct operation, particularly if the
>> application uses relatively large cookie values.
>>
>> Credit:
>> This issue was identified by the TERASOLUNA Framework Development Team
>> at the Software Engineering, Research and Development Headquarters and
>> reported to the ASF via JPCERT.
>>
>> References:
>> http://tomcat.apache.org/security-9.html
>> http://tomcat.apache.org/security-8.html
>> http://tomcat.apache.org/security-7.html
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: [SECURITY][CORRECTION] CVE-2016-3092 Apache Tomcat Denial of Service

[Kyohei Nakamura]

Hi,

I have a question about the maxHttpHeaderSize.

In this announcement, the recommended value is 3072 bytes.
However, in the announcement from the Apache Commons project, the
recommended value is 2048 bytes.
http://mail-archives.apache.org/mod_mbox/www-announce/201606.mbox/%3c45a20804-abff-4fed-a297-69ac95ab9...@apache.org%3E

If an application uses the Apache Commons FileUpload (not use the
Tomcat File Upload feature), which one should I use? "3072" or "2048".


2016-06-22 19:02 GMT+09:00 Mark Thomas :
> Note: This announcement corrects several errors and omissions in the
> Tomcat aspects of the announcement for CVE-2016-3092 from the Apache
> Commons project that was recently forwarded to various Apache Tomcat
> mailing lists.
>
> For the sake of clarity, the Tomcat specific corrections are as follows:
> 1. This is a Denial of Service vulnerability, not an Information
> Disclosure vulnerability.
> 2. Apache Tomcat 8.5.x is also affected. The vulnerability exists in
> 8.5.0 to 8.5.2 and affected users of 8.5.x should upgrade to 8.5.3.
> 3. Apache Tomcat 6.x and earlier are not affected.
> 4. Applications that do not use the File Upload feature introduced in
> Servlet 3.0 are not vulnerable via Tomcat.
>
> A corrected announcement, for Tomcat only, follows.
>
>
> CVE-2016-3092: Apache Tomcat Denial of Service
>
> Severity: Moderate
>
> Vendor:
> The Apache Software Foundation
>
> Versions Affected:
> Apache Tomcat 9.0.0.M1 to 9.0.0M6
> Apache Tomcat 8.5.0 to 8.5.2
> Apache Tomcat 8.0.0.RC1 to 8.0.35
> Apache Tomcat 7.0.0 to 7.0.69
> Earlier versions are not affected.
>
> Description:
> CVE-2016-3092 is a denial of service vulnerability that has been
> corrected in the Apache Commons FileUpload component. It occurred when
> the length of the multipart boundary was just below the size of the
> buffer (4096 bytes) used to read the uploaded file. This caused the file
> upload process to take several orders of magnitude longer than if the
> boundary length was the typical tens of bytes.
>
> Apache Tomcat uses a package renamed copy of Apache Commons FileUpload
> to implement the file upload requirements of the Servlet specification
> and was therefore also vulnerable to the denial of service vulnerability.
>
> Applications that do not use the File Upload feature introduced in
> Servlet 3.0 are not affected by the Tomcat aspect of this vulnerability.
> If those applications use Apache Commons FileUpload, they may still be
> affected.
>
> Mitigation:
> Users of affected versions should apply one of the following mitigations
> - Upgrade to Apache Tomcat 9.0.0.M8 or later
>   (9.0.0.M7 has the fix but was not released)
> - Upgrade to Apache Tomcat 8.5.3 or later
> - Upgrade to Apache Tomcat 8.0.36 or later
> - Upgrade to Apache Tomcat 7.0.70 or later
>
> Workaround:
> The issue may be mitigated by limiting the length of the boundary.
> Applications could do this with a custom Filter to reject requests that
> use large boundaries.
> Tomcat provides the maxHttpHeaderSize attribute on the Connector that
> can be used to limit the total HTTP header size. Users should be aware
> that reducing this to 3072 (which should be low enough to protect
> against this DoS) may cause other issues as applications can require
> larger headers than this for correct operation, particularly if the
> application uses relatively large cookie values.
>
> Credit:
> This issue was identified by the TERASOLUNA Framework Development Team
> at the Software Engineering, Research and Development Headquarters and
> reported to the ASF via JPCERT.
>
> References:
> http://tomcat.apache.org/security-9.html
> http://tomcat.apache.org/security-8.html
> http://tomcat.apache.org/security-7.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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

Re: Updating Tomcat native requires APR update

[Ari Luoma]

On Thu, Jun 30, 2016 at 8:49 AM, Ari Luoma wrote:
> On Wed, Jun 29, 2016 at 3:04 PM, Mark Thomas wrote:
>> On 29/06/2016 12:40, Ari Luoma wrote:
>>> First I would like to thank you for the great job you do by responding
>>> to these questions people have.
>>>
>>> I am about to update Tomcat 8.0.26 -> 8.5.3.
>>>
>>> I am using AJP APR connector between Tomcat and Apache.
>>>
>>> If I update APR (by downloading and compiling it from APR website) to
>>> the newest do I also need to compile httpd or can it use 1.3.9 APR
>>> with httpd when Tomcat uses 1.5.2?
>>
>> As long as you compile APR 1.5.2 to a separate location and don't
>> overwrite your APR 1.3.9 build you should be fine.
>>
>
> But even though if someone would overwrite the previous one it should
> be fine, because compiling later version?
>
> Binary Compatibility: "Similar to source compatibility, an application
> that has been compiled against a particular version will continue to
> be linkable against later versions (unless the major number changes).
> It is possible that an application will not be able to successfully
> link against a previous minor version."
> Source: http://apr.apache.org/versioning.html
>

But if I would override the original I would also need to update
OpenSSL because apr-util needs OpenSSL-1.0.2h for SSL support.
By not overriding I can leave apr util without SSL support

>>> Below more info about the current setup:
>>>
>>> One Server with: CentOS 6.3
>>> Apache HTTP Server 2.2.15 (installed from centos repo)
>>> Tomcat 8.0.26 (Installed by downloading tar.gz...)
>>> APR 1.3.9 (installed from centos repo and this is the newest version
>>> available from repo)
>>> Tomcat-native 1.1.33 (built from Tomcat directory)
>>>
>>> Server is running multiple Tomcats instances in different ports.
>>> httpd is there at front as a proxy with configuration something like this.
>>>
>>> Listen 443
>>> NameVirtualHost *:443
>>> 
>>> ...
>>>   
>>> ProxyPass ajp://localhost:8109/myWebApp/ timeout=3600
>>> ProxyPassReverseCookiePath /myWebApp /test
>>>   
>>> 
>>>
>>>
>>> Connector on Tomcat side:
>>> 
>>>
>>>
>>> #httpd -V
>>> Server version: Apache/2.2.15 (Unix)
>>> Server built:   Aug 13 2013 17:29:28
>>> Server's Module Magic Number: 20051115:25
>>> Server loaded:  APR 1.3.9, APR-Util 1.3.9
>>> Compiled using: APR 1.3.9, APR-Util 1.3.9
>>> ...
>>>
>>> When about to build the tomcat native 1.2.7 from Tomcat 8.5.3 it says:
>>> configure: error: Found APR 1.3.9. You need version 1.4.3 or newer 
>>> installed.
>>
>> Once you fix the APR issue, OpenSSL might be your next problem since
>> tomcat native requires OpenSSL 1.0.2. There are various solutions, the
>> simplest being to build Tomcat Native without OpenSSL support if you
>> don't need it.
>
> Thanks for that!
> Luckily I don't need the SSL support on Tomcat side, because httpd
> handles it and connection to manager goes through VPN so I can
> "downgrade" https connection into http.
>

Is tomcat_native library only used on APR connectors?
So that I (or someone else who happens to read this) could use
"org.apache.coyote.http11.Http11NioProtocol" for HTTPS and AJP APR for
httpd <-> Tomcat without SSL.
Are there any downsides for having both NIO and APR in use, like much
greater memory consumption?

>>
>> 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