Re: Need help setting up SSL on Tomcat 8
2016-06-29 9:08 GMT-04:00 Sean Son : > 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? > So, the first entry in the keystore isn't your certificate. As I told you before, if you do not specify explicitely the alias of the certificate so send, the first entry in the keystore is sent. In this case, root. The attribute to tell the connector which certificate to send, is keyAlias, however it seems your certificate has no alias in the keystore. - Daniel Savard
Re: Tomcat 7 and SHA-1
2016-06-30 23:05 GMT-04:00 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? > No. However, you can select the accepted ciphers to reject anything that doesn't meet your standards. - Daniel Savard
Viewing Tomcat DB connection statement cache size via JMX MBeans
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
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
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
> 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"
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
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?
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
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
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
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
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