Re: Tomcat 9 M22 doesn't stop
This workaround is working well. Thanks all for your answers. A.T. 2017-07-23 0:18 GMT+02:00 Mark Eggers : > Rainer, > > On 7/22/2017 2:37 PM, Rainer Jung wrote: > > Am 22.07.2017 um 22:48 schrieb Mark Eggers: > >> On 7/22/2017 12:50 AM, Aurélien Terrestris wrote: > >>> Hello, > >>> > >>> I'm trying the latest Tomcat (9.0.0.M22) with all the default > >>> settings and > >>> applications. When shutting down, it doesn't stop and I'm staying with > a > >>> java process which cannot handle any request. > >>> When setting the CATALINA_PID and trying a shutdown -force, it ends in > >>> killing the process. > >>> > >>> > >>> > >>> Here is the catalina.out, with a thread-dump done 20 minutes after the > >>> shutdown : > >>> > >>> 18-Jul-2017 08:49:50.110 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Server > >>> version:Apache Tomcat/9.0.0.M22 > >>> 18-Jul-2017 08:49:50.112 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Server > >>> built: Jun 21 2017 09:44:18 UTC > >>> 18-Jul-2017 08:49:50.112 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Server > >>> number: 9.0.0.0 > >>> 18-Jul-2017 08:49:50.112 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log OS > >>> Name: Linux > >>> 18-Jul-2017 08:49:50.112 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log OS > >>> Version:3.10.0-514.el7.x86_64 > >>> 18-Jul-2017 08:49:50.112 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log > >>> Architecture: amd64 > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Java > >>> Home: > >>> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log JVM > >>> Version: 1.8.0_131-b12 > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log JVM > >>> Vendor:Oracle Corporation > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log > >>> CATALINA_BASE: /home/testusr/cluster/apache-tomcat-9.0.0.M22 > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log > >>> CATALINA_HOME: /home/testusr/cluster/apache-tomcat-9.0.0.M22 > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: > >>> -Djava.util.logging.config.file=/home/testusr/cluster/9/ > conf/logging.properties > >>> > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: > >>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: -Djdk.tls.ephemeralDHKeySize=2048 > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: -Djava.protocol.handler.pkgs=org.apache.catalina. > webresources > >>> 18-Jul-2017 08:49:50.113 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: -Dcatalina.base=/home/testusr/cluster/9 > >>> 18-Jul-2017 08:49:50.114 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: -Dcatalina.home=/home/testusr/cluster/9 > >>> 18-Jul-2017 08:49:50.114 INFO [main] > >>> org.apache.catalina.startup.VersionLoggerListener.log Command line > >>> argument: -Djava.io.tmpdir=/home/testusr/cluster/9/temp > >>> 18-Jul-2017 08:49:50.114 INFO [main] > >>> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR > >>> based > >>> Apache Tomcat Native library which allows optimal performance in > >>> production > >>> environments w
Tomcat 9 M22 doesn't stop
Hello, I'm trying the latest Tomcat (9.0.0.M22) with all the default settings and applications. When shutting down, it doesn't stop and I'm staying with a java process which cannot handle any request. When setting the CATALINA_PID and trying a shutdown -force, it ends in killing the process. Here is the catalina.out, with a thread-dump done 20 minutes after the shutdown : 18-Jul-2017 08:49:50.110 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version:Apache Tomcat/9.0.0.M22 18-Jul-2017 08:49:50.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Jun 21 2017 09:44:18 UTC 18-Jul-2017 08:49:50.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 9.0.0.0 18-Jul-2017 08:49:50.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 18-Jul-2017 08:49:50.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:3.10.0-514.el7.x86_64 18-Jul-2017 08:49:50.112 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_131-b12 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:Oracle Corporation 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /home/testusr/cluster/apache-tomcat-9.0.0.M22 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /home/testusr/cluster/apache-tomcat-9.0.0.M22 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/home/testusr/cluster/9/conf/logging.properties 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 18-Jul-2017 08:49:50.113 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/home/testusr/cluster/9 18-Jul-2017 08:49:50.114 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/home/testusr/cluster/9 18-Jul-2017 08:49:50.114 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/home/testusr/cluster/9/temp 18-Jul-2017 08:49:50.114 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib] 18-Jul-2017 08:49:50.191 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-127.0.0.1-8080"] 18-Jul-2017 08:49:50.210 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read 18-Jul-2017 08:49:50.213 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 18-Jul-2017 08:49:50.215 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read 18-Jul-2017 08:49:50.218 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 495 ms 18-Jul-2017 08:49:50.239 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] 18-Jul-2017 08:49:50.239 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/9.0.0.M22 18-Jul-2017 08:49:50.248 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/home/testusr/cluster/apache-tomcat-9.0.0.M22/webapps/ROOT] 18-Jul-2017 08:52:23.690 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [153,172] milliseconds. 18-Jul-2017 08:52:23.705 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/home/testusr/cluster/apache-tomcat-9.0.0.M22/webapps/ROOT] has finished in [153,457] ms 18-Jul-2017 08:52:23.705 INFO [main] org.apache.catalina.startup.HostCo
Re: Custom Webapp loading..
hi what are you trying to do exactly ? If you just need to start one webapp after another one in a precise order, you need as many Services (+Connector on a different port, + Host) as webapps. A.T. 2017-05-31 22:48 GMT+02:00 Hassan Khan : > Hi, > > We have the following structure for webapps in tomcat 6. > > Tomcat > Webapp > Application 1 >WEB-INF >lib > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib > > > The Tomcat > Webapp > Application 1 >WEB-INF >lib gets loaded with > addwebapp() function.. > but for Tomcat > Webapp > Application 1 > Application >WEB-INF> lib , we > wrote a custom webapploader that extended WebappLoader. > > Now we are upgrading to tomcat 8.5 > > Wanted to know if any other way to accomplish the same task. > > Was working on using the same extended loader .. but the start() function > has changed to InternalStart() and getting a exception as below: > Caused by: org.apache.catalina.LifecycleException: An invalid Lifecycle > transition was attempted ([after_start]) for component > [WebappLoader[/SandBox/Primar]] in state [STARTING_PREP] > > Any pointer are appreciated.. not that familiar with extending apache > classes. > > Thanks > Hassan > > > > > On Wed, May 31, 2017 at 4:42 PM, Hassan Khan > wrote: > > > Hi, > > > > We have the following structure for webapp in tomcat 6. > > > > Tomcat > Webapp > Application 1 > Application >WEB-INF> lib > > > > T > > he Alpp > > > > -- > > Hassan Khan > > > > > > -- > Hassan Khan >
Re: Tomcat 8/Redhat Linux 6.6 /Kernal 2.6.32 - Memory Won't Release
"I think you are chasing a ghost that isn't actually there."
I agree with Chris. You should try to clean the caches and I believe that
you will see your memory back "free". Have a look at how to do it here :
http://unix.stackexchange.com/questions/87908/how-do-you-empty-the-buffers-and-cache-on-a-linux-system
2017-03-20 20:27 GMT+01:00 Eric Chua :
> blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px
> #715FFA solid !important; padding-left:1ex !important;
> background-color:white !important; } When I run my application in a windows
> environment I use a few hundred megabytes. When I use RHL, it takes up the
> entire 16gb of memory in QA with one user within minutes. The memory is
> also unaccounted for. My user says I am using a few gigabytes and root
> doesn't own hardly anything.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, March 20, 2017, 2:11 PM, Thomas Meyer wrote:
>
>
>
>
> With kind regards
> Thomas
> > Am 17.03.2017 um 14:54 schrieb Christopher Schultz <
> ch...@christopherschultz.net>:
> >> Note that Java *never* gives any memory back to the OS, even when the
> > heap-usage goes down. This is a Java thing, not a Tomcat thing.
> >
>
> Are you sure about this? I think I've read otherwise somewhere. A quick
> google showed up this: http://stackoverflow.com/a/30464183
>
> With kind regards
> Thomas
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
Re: Tomcat JDBC Connection Pool - Stand Alone Logging
What database are you connecting to ? Oracle ? MySQL ? If Oracle, then you're probably using its specific driver, and there is a debug version (the "_g" version) that logs. According to you, what kind of log the Tomcat driver should write ? 2017-02-16 19:08 GMT+01:00 Chris Keilitz : > I'm assuming, once configured properly, the Tomcat JDBC connection pool > would output log messages. Unfortunately, I currently get no console or > file output...even after trying numerous logging.properties changes. > > I'm hoping for a little help to understand the proper way to configure a > stand alone usage of Tomcat JDBC. > > On Thu, Feb 16, 2017 at 12:58 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Chris, > > > > On 2/16/17 12:26 PM, Chris Keilitz wrote: > > > I've implemented Tomcat JDBC connection pool stand-alone, outside > > > of Tomcat or any app server or container and cannot get the Juli > > > logging working - console or file. The connection pool works > > > great, but I cannot get the logging going. I've added > > > CATALINA_HOME to the local directory and have added > > > logging.properties file to the local lib and .conf directories, > > > but still cannot get it to work. > > > > > > I know I'm missing somethinghoping one of you can me understand > > > what I'm doing wrong, could try. > > > > When you say that the logging doesn't work, what exactly do you mean? > > > > "Adding CATALINA_HOME to the local directory" doesn't clarify anything. > > > > - -chris > > -BEGIN PGP SIGNATURE- > > Comment: GPGTools - http://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQIcBAEBCAAGBQJYpehVAAoJEBzwKT+lPKRYRIIQAL252B1PA+RdmD0kvxi4XGQw > > 1nkfbUpLy3qnZlejj4AMxNZCmNsgxzSVKsuseZXSltiCvsidbuS1VJb+aZ6qI/mC > > FaDdrORqA5MJ5JQxCBKF0KHNvm4/P8+7XLW7S0m+CCSUsJ6S4yUfq8soV+giM6vD > > I3tEMfQscMnkj3wTzWqKKwY4rs6YJ+ILerwclGmMB1rtpO9lwGFBTj2p2M0NwPav > > 9P7LESiUtZGaJMxlS+QFJW+u8xPqQTkQV2xf5ZVbeMZfKqtD14FWrgMzrlRyo27P > > 0IhK1qs2I1EdWzPT7O2xEWpcKC9b6P2+su5YIjS4xwDOF9dsSBZfBLgKXhrm8gDf > > JI+d0xgC80PzDZfQwv/Spo0J9U4sGPUp9+tTRjI4Ub8M8z4xG/gssNw7eG8RCOfU > > NYIK/POB9QPTukUKyEPMXr/DYC7W3b0RP0yjH/yk+hcp3H3Iok/4GVoey8ydhYlT > > fI5P7oq1FNXFVoupMEv77eqlzCc6V7CU0idMhjnSjM5Zoio9r+kbONg5oHDBlSDA > > yXbPcDPORr+qux6hf73HK8kNH5ae059aF9T8lGC+uW5EyY4YAgQfrhle/3xk+Jub > > sGeM8gpVt9eozlNFyZ4LqTXXNtBHzpw5LCTQa1TWS8UQm703+/0DxZmf0EgZwEn5 > > pN0ov1UkJ4tcT7DA7E0w > > =Xqes > > -END PGP SIGNATURE- > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > >
Re: Mapping Multiple LDAP Groups to a J2EE Role
hi
The JSR 315 ( = Servlet 3.0 , Tomcat 7 ) and JSR 340 ( = Servlet 3.1,
Tomcat 8.0 / 8.5 ) are saying the same thing about multiple names for a
very same role. It's done with a security-role-ref tag, as explained by
these JSR :
**For example, to map the security role reference "FOO" to the security
role with role-name "manager" the syntax would be
FOO
manager
In this case, if a servlet called by a user belonging to the "manager"
security role were to call isUserInRole("FOO") the result would be true**
Of course you still need a Realm in the conf/server.xml, a security
constraint and a login-config in the webapp's web.xml
I didn't try myself, but you can ask if you're still in trouble.
best regards
A.T.
2017-01-26 23:01 GMT+01:00 John Trump :
> Thi is what the product specifies:
>
> In many cases, you can map multiple LDAP groups to a Jazz role in a Jazz
> Team Server environment. However, if your Jazz Team Server runs on Apache
> Tomcat application server and Tomcat does not support mapping multiple LDAP
> groups to a J2EE role, you cannot map multiple groups to one role.
>
> In this case, I am guessing it would mean I I have 3 LDAP groups (group1,
> group2, group3) and I would need to map those LDAP groups to 1 single role,
> o.e. jazzuser or jazzadmin.
>
> On Thu, Jan 26, 2017 at 4:18 PM, Aurélien Terrestris <
> aterrest...@gmail.com>
> wrote:
>
> > Hi John
> >
> > do you mean that a same user would be found in different groups ? Or do
> you
> > have different roles, with each role being in its own group ?
> >
> >
> >
> >
> >
> >
> >
> > 2017-01-26 18:39 GMT+01:00 John Trump :
> >
> > > I am installing IBM's DOORS NG with Tomcat 8.0.41. I would like to use
> > LDAP
> > > for authentication but need to confirm that tomcat supports mapping
> > > multiple LDAP groups to a J2EE role.
> > >
> > > I have looked through the documentation but am still not sure if this
> is
> > > supported. Any help or insight would be greatly appreciated.
> > >
> >
>
Re: Apache Tomcat/7.0.39 crashed with fatal error
Hello maybe you're just sending cookies with non-compliant characters. Please check what you're sending if you can reproduce this problem yourself RFC 6265 says : cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E ; US-ASCII characters excluding CTLs, ; whitespace DQUOTE, comma, semicolon, ; and backslash 2017-01-26 22:22 GMT+01:00 Satish Chhatpar 02 : > Yes all of them failed in the same way. > > > # Problematic frame: > # J org.apache.http.impl.cookie.BestMatchSpec.formatCookies( > Ljava/util/List;)Ljava/util/List; > > > > Regards > > Satish Chhatpar > > > > From: Christopher Schultz > Sent: Friday, January 27, 2017 2:44:54 AM > To: Tomcat Users List > Subject: Re: Apache Tomcat/7.0.39 crashed with fatal error > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Satish, > > On 1/26/17 3:42 PM, Satish Chhatpar 02 wrote: > > Thanks Chris. I appreciate your help. > > > > All 4 tomcats are on diff machines. One on each, with same tomcat > > version, same java version and same OS for all. > > Did they all fail in the same way (JVM crash @ > org.apache.http.impl.cookie.BestMatchSpec.formatCookies)? > > > Tomcats are not in cluster. > > I would highly recommend upgrading the JVM on one of those servers to > 1.7.latest to see if everything still works. If things go well, > upgrade all of them. > > Then deploy the 1.8.latest to one of them. Tomcat shouldn't have any > compatibility issues with Java 8, but you will definitely want to test > everything in your application of course. > > - -chris > > > From: Christopher Schultz > > Sent: Friday, January 27, 2017 > > 1:52:47 AM To: Tomcat Users List Subject: Re: Apache Tomcat/7.0.39 > > crashed with fatal error > > > > Satish, > > > > On 1/26/17 2:28 PM, Satish Chhatpar 02 wrote: > >> we are using Apache Tomcat/7.0.39 for our java application. > > > > I highly recommend an upgrade for both Tomcat and Java. There are > > published vulnerabilities for both product versions you are using. > > > >> There are 4 tomcat instances using same tomcat version and java > >> version. yesterday all 4 tomcats crashed with below error in > >> hs_err_pid log file. > > > > All on the same hardware? Or separate machines? > > > >> This log file was created for all 4 tomcats. > > > >> Its very peculiar behaviour that all 4 crashed around same time. > > > > If they are in a cluster, one going down could cause the load on > > the others to go up, increasing the chances of a problem. > > > >> Any information can help us to mitigate this incident. > > > >> Apache Tomcat/7.0.39 > > > > Unless this is a package-managed version of Tomcat with an > > unfortunately inaccurate version number, that version of Tomcat is > > nearly 3 years old. The current version in the 7.0.x line is > > 7.0.75 (released yesterday). > > > >> java version "1.7.0_21" Java(TM) SE Runtime Environment (build > >> 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build > >> 23.21-b01, mixed mode) > > > > That version of Java is also nearly 3 years old. Latest 1.7 build > > is 1.7.0_80 release nearly 3 years ago. Note that Java 7 is no > > longer supported unless you have a long-term support contract with > > Oracle, in which case the latest version is 1.7.0_131, released > > earlier this month. > > > >> OS used > > > > > >> Red Hat Enterprise Linux Server release 6.3 (Santiago) > > > > Ouch! 5 years old! > > > >> # # A fatal error has been detected by the Java Runtime > >> Environment: # # SIGSEGV (0xb) at pc=0x7fed24ecfe9e, > >> pid=21352, tid=140656275650304 # # JRE version: 7.0_21-b11 # > >> Java VM: Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode > >> linux-amd64 compressed oops) # Problematic frame: # J > >> org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/Li > s > > > >> > t;)Ljava/util/List; > > > > > > # > >> # Failed to write core dump. Core dumps have been disabled. To > >> enable core dumping, try "ulimit -c unlimited" before starting > >> Java again # # If you would like to submit a bug report, please > >> visit: # http://bugreport.sun.com/bugreport/crash.jsp # > > > > This is either a JVM bug is a hardware error. Given that the OS if > > 5 years old, I'm guessing the hardware is at least that old. I'd > > expect 5-year old hardware to be fairly trustworthy, but it may not > > have been properly-tested before going into production. > > > > If it's all on a single piece of hardware (all 4 Tomcats), I'd > > blame the hardware and look for a speedy replacement > > (properly-tested this time). If it was on different machines, I'd > > suspect a JVM bug. > > > > -chris > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: user
Re: Mapping Multiple LDAP Groups to a J2EE Role
Hi John do you mean that a same user would be found in different groups ? Or do you have different roles, with each role being in its own group ? 2017-01-26 18:39 GMT+01:00 John Trump : > I am installing IBM's DOORS NG with Tomcat 8.0.41. I would like to use LDAP > for authentication but need to confirm that tomcat supports mapping > multiple LDAP groups to a J2EE role. > > I have looked through the documentation but am still not sure if this is > supported. Any help or insight would be greatly appreciated. >
Re: Stopping any Tomcat thread running more than an amount of time
Hello, if it is possible to know which servlet is involved in this problem, maybe could you update the web.xml and deactivate this servlet by commenting its servlet mapping. You would then get 404 errors, but maybe it's better than your problem now. regards A.T. 2017-01-23 12:01 GMT+01:00 Abdessamed Mansouri : > Hello all, > > We have an application which turns on Tomcat and suffer from bad > performance (we are trying to find a solution by reimplementing it), so > there's many many many simple functionnalities which take too much time > (bad implementation) sometimes up to 30mins (and to hours), so our client's > employees dont use these functionnalities but sometimes by mistake they run > some of it which make all the entire server slow for all other employees > because the tomcat request handler threads still turning in background, so > temporarily we are seeking for a way (through config or code hacking) to > let Tomcat stops it's threads after some amout of time if they didn't > completed, for exemple : Tomcat will stop any of its running thread after 5 > mins if the thread doesn't completed. > > Tomcat version : 7.0.35 > > Thanks > > -- > Abdessamed MANSOURI > Consultant développeur en nouvelles technologies - ALTI Algérie > Lot N° 30 – Lotissement 20 août 1955 – Oued Romane – EL Achour – 16106 – > Alger > Tél 1 : 06 73 37 72 58 > Tél 2 : 05 56 66 57 56 > Email : amanso...@alti-dz.com >
Re: Tomcat7 / Axis2
Christopher, "For dev/test, we sometimes have weeks with no activity, and I've never seen any problems." Let's suppose that during this no-activity period, you're restarting once or twice the database. Or that a firewall silently dropped the connection. Is the first request lost, Tomcat returning a 500 ? "If you have to bounce Tomcat every day to keep your applications running smoothly, it's the fault of your application, not of Tomcat." Not only "my" applications, but many among the thousands that I had to deal with in different large companies. Maybe there is a wrong understanding of JDBC and how to use it, but if so many are failing to understand, this means the poor documentation is somewhat responsible. Another point is that developers like to copy/paste their old code which they believe is fail-safe, bringing the same bugs again and again. best regards 2016-08-23 22:33 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 8/22/16 3:36 PM, Aurélien Terrestris wrote: > > "We have a Tomcat 7 and Axis 2 for our Java SOAP web service over > > https on our Ubuntu server. We also use C3PO connection pooling > > (also in other web services which is working fine). However, I´m > > not sure if this is related to the topic." > > > > I believe it is. Is the faulty web service getting requests all the > > time, or there are some long time without requests ? I can't speak > > for all the mailing list, but myself I do a daily restart of my > > Tomcats to prevent such problem. > > I only restart my Tomcats for application upgrades. We use Tomcat's > DBCP2-based connection pool. We don't have very many periods of > inactivity in production. > > For dev/test, we sometimes have weeks with no activity, and I've never > seen any problems. > > If you have to bounce Tomcat every day to keep your applications > running smoothly, it's the fault of your application, not of Tomcat. > > - -chris > > > 2016-08-22 17:32 GMT+02:00 Matthias Schmitt > > : > > > >> Hello everybody, > >> > >> We have a Tomcat 7 and Axis 2 for our Java SOAP web service over > >> https on our Ubuntu server. We also use C3PO connection pooling > >> (also in other web services which is working fine). However, I´m > >> not sure if this is related to the topic. > >> > >> The web service is working for about two/three days and after > >> that time period it´s not working anymore. Then our consuming > >> customer receives a Read Timeout Exception. After restarting the > >> Tomcat servlet everything is working fine again. Processing the > >> request has a duration of about 3 seconds. The Axis 2 has a > >> default socket timeout of 30 seconds. Our customer has a wait > >> timeout of 60 seconds. The strange thing about the problem is > >> that it´s working for amount of time and then the problem occurs. > >> Even if we increase the client timeout it seems like the request > >> will be not processed. Also increasing the socket timeout value > >> in axis configuration does not take effect. There is no exception > >> message in the log that could help us to reproduce the problem. > >> > >> Thanks for your help, > >> > >> Mit besten Grüßen/with best regards > >> > >> Matthias Schmitt > >> > >> > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXvLMWAAoJEBzwKT+lPKRYwsgQAJKGwx+rRl8L/PM/rQKX/3Mz > ml0aYb+9rHeALymvzqy7Q+AcrYZOUqxCnyl9JtYbjIw12QHqUa5KKt2aAS2Uha8B > H3yOs7cVCW/ZIdYEtyFwDGKvbexM5nXEeE8ZeNn184Qdb+r9bSAZs3mrM3QWxfG3 > aw51J2h0dCEG2sHE7P/N4U/IvbthoI5OSVWsSEB7AJs8GOrHhX9ZJ/KRiY/i5bna > 5I9BlzOHgCUBDUaD7p2BTBiMSAolB0SA5wT9sm5ITJRUvvBCs/kg1kA6EMJBTX1A > RNBGlPJus91DthG/a39dcb/PbrXwGpTc4E1g4QtdpVAQEKrmZK7hOrhD9EeYiSOr > ADyPM7WRNdemdmrJhMmS9gbGfbCSFhFnxKHxeRUBC/lSPCsVFX89CDfCRoqpya6L > 1scIt0eOC68I40Z6ME/0vVSevtcjvESXBRhPquIKviHYKlEeLpqZ+/0V8wC3sCmG > 9E3OAPmY5C5EuMtV5XMTT4iojojR0dt73/CZFvvhrc1e2GY0bdgFaXf5/+nGDUcr > TYuGzPwyQTnJRnBOXfF8i6KiG77OnQ8vE8TtS6CEcVXNusSK2mjf8zxvGcs9Ietw > 8eqLPPLyWYrnqyXUMBZXa/XJeH8qHZYmBpv4O6xgeYRTcnERC1EJof5KzsXtjDJT > mueggk9xS2aBwMGgk04M > =II6y > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat7 / Axis2
"We have a Tomcat 7 and Axis 2 for our Java SOAP web service over https on our Ubuntu server. We also use C3PO connection pooling (also in other web services which is working fine). However, I´m not sure if this is related to the topic." I believe it is. Is the faulty web service getting requests all the time, or there are some long time without requests ? I can't speak for all the mailing list, but myself I do a daily restart of my Tomcats to prevent such problem. 2016-08-22 17:32 GMT+02:00 Matthias Schmitt : > Hello everybody, > > We have a Tomcat 7 and Axis 2 for our Java SOAP web service over https on > our Ubuntu server. We also use C3PO connection pooling (also in other web > services which is working fine). However, I´m not sure if this is related > to the topic. > > The web service is working for about two/three days and after that time > period it´s not working anymore. Then our consuming customer receives a > Read Timeout Exception. After restarting the Tomcat servlet everything is > working fine again. Processing the request has a duration of about 3 > seconds. The Axis 2 has a default socket timeout of 30 seconds. Our > customer has a wait timeout of 60 seconds. The strange thing about the > problem is that it´s working for amount of time and then the problem > occurs. Even if we increase the client timeout it seems like the request > will be not processed. Also increasing the socket timeout value in axis > configuration does not take effect. There is no exception message in the > log that could help us to reproduce the problem. > > Thanks for your help, > > Mit besten Grüßen/with best regards > > Matthias Schmitt > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: setting jvm parameters to optimize production performance
Hi Stefan I think that tuning should be considered for one application, not for "production" or "development". First, you need to check how your JVM is working with its memory parameters. You can either learn its behaviour by checking the logs ( add this to the setenv : -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc ) or with the jstat command (example for 60 seconds checking jstat -gcutil -h 60 31220 60s 60) With that you know if it is garbaging often, and on which part of the JVM. You can send us your results, I suppose we not have the same ideas here on the mailing list. Second, it is needed to know your application well. For example, does it cache objects ? Or does it only calculates data and send it to the client ? regards A.T. 2016-05-06 14:11 GMT+02:00 Stefan Frei : > Tomcat 8.0.33 > Debain jessie > java 8 > > Hello > > i cannot find any resources how to set configure the setenv.sh for a > production environment. > > Does somebody have some tips? > > Best regards > > Stefan > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Performance regression from 7 to 8
Christopher, thanks for this information, but Tullio said that his problem only occurs with the NIO connector (it seems weird and I don't have sufficient knowledge on how it is coded in Tomcat anyway). The post was already quite long before I suggested him to try both connectors to identify a possible problem there. I'm just being pragmatic here. 2016-03-09 16:41 GMT+01:00 Christopher Schultz : > Aurélien, > > On 3/9/16 8:50 AM, Aurélien Terrestris wrote: > > The doc ( > > > http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#NIO2_specific_configuration > > ) doesn't say which one is the best, but we may think that the > non-blocking > > will work better under heavy load. > > NIO2 is newer and has had less testing in the wild. Between the two I'd > stick to NIO. > > > If not servicing hundreds of clients at the same moment, I would use the > > blocking connector ( http11.Http11Protocol ) > > Note that the blocking connector doesn't work well with asynchronous > protocols like websocket, etc. It is being removed from Tomcat in Tomcat > 9. (RIP BIO) > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Performance regression from 7 to 8
The doc ( http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#NIO2_specific_configuration ) doesn't say which one is the best, but we may think that the non-blocking will work better under heavy load. If not servicing hundreds of clients at the same moment, I would use the blocking connector ( http11.Http11Protocol ) regards 2016-03-09 10:12 GMT+01:00 Tullio Bettinazzi : > I tested with http11.Http11Protocol, http11.Http11NioProtocol and > http11.Http11Nio2Protocol and the problem reproduces only with > http11.Http11NioProtocol. > It seems to be a bug of the Nio protocol. > It's better to use Nio2 or standard ? What's the difference ? > Tks > Tullio > > > > Date: Mon, 7 Mar 2016 16:26:24 +0100 > > Subject: Re: Performance regression from 7 to 8 > > From: aterrest...@gmail.com > > To: users@tomcat.apache.org > > > > Tullio, > > > > as suggested before by Felix, maybe you should try different connector > > configurations (defaults for HTTP connector are different between T7 > > (blocking) and T8 (non-blocking)) and see if this changes anything. > > > > For example in the server.xml file : > > > > > protocol="org.apache.coyote.http11.Http11Protocol" address="YOURSERVER" > >connectionTimeout="2" > >disableUploadTimeout="false" > >connectionUploadTimeout="360" > >redirectPort="8843" /> > > > > and > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > address="YOURSERVER" > >connectionTimeout="2" > >disableUploadTimeout="false" > >connectionUploadTimeout="360" > >redirectPort="8843" /> > > > > > > Your code is simple, only buffering and writing to an OutputStream. Don't > > know how, but I believe that only the buffering can introduce some delay. > > > > best regards > > > > > > > > > > > > > > 2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi : > > > > > As I already explained is not a reproductable problem. > > > I tested the testcase in my environment and I reproduced the problem on > > > some clients but not on all clients : the same clients where I noticed > the > > > problem in the real application. > > > I'm not able to understand what's the relevant difference among them > (not > > > OS version, not network, not browser). > > > The problem disappears using tomcat 7. > > > Tks > > > Tullio > > > > > > > Subject: Re: Performance regression from 7 to 8 > > > > To: users@tomcat.apache.org > > > > From: ma...@apache.org > > > > Date: Mon, 7 Mar 2016 11:52:40 + > > > > > > > > On 06/03/2016 08:45, Tullio Bettinazzi wrote: > > > > > I tested with 8.20 and 8.32 > > > > > With nothing changed I meant simply that results didn't change. > > > > > > > > I can't repeat the problem you are describing with your provided test > > > case. > > > > > > > > I ran: > > > > - ab -k -n 1000 -c 1 localhost:8080/user002/Test > > > > - latest 8.0.x code > > > > - your test case with and without setting the content length (as an > > > > HTTP/1.0 client ab needs the content length to use keep-alive with > > > > large response bodies > > > > > > > > I saw average response times of 6ms with a maximum of 9ms. > > > > The content length header made no difference (apart from keep-alive > > > > being used as expected). > > > > > > > > If the problem you are describing was widespread I'd expect to see > other > > > > users reporting this on the mailing list. > > > > > > > > Given that: > > > > - I can't repeat this > > > > - Other users aren't reporting it > > > > - Only you are seeing the issue > > > > > > > > this looks like an issue with your environment rather than with > Tomcat. > > > > I'd recommend using tools like Wireshark and YourKit to find out > exactly > > > > what is going on. > > > > > > > > Mark > > > > > > > > > > > > > Tks > > > > > Tullio > > > > > > > > > >> Subject: Re: Performance regression from 7 to 8 > > > > >> To: users@tomcat.apache.org > > > > >> From: ma...@apache.org > > > > >> Date: Sat, 5 Mar 2016 18:40:36 + > > > > >> > > > > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote: > > > > >>> Done and nothing changed. > > > > >> > > > > >> What has changed is that you have now provided a test case that > > > someone > > > > >> else can run easily and confirm, or not, your findings. > > > > >> > > > > >>> Any suggestion ? > > > > >> > > > > >> Before anyone spends time looking at this the other question I > don't > > > see > > > > >> answered in this thread is "Exactly which Tomcat 8 version were > you > > > > >> testing?". If it isn't the the latest then you'll need to retest > to > > > > >> confirm the issue hasn't already been fixed. > > > > >> > > > > >> Mark > > > > >> > > > > >>> Here the code. > > > > >>> > > > > >>> package axioma.rubik.engine.web.servlet; > > > > >>> > > > > >>> import java.io.*; > > > > >>> import javax.servlet.ServletException; > > > > >>> import javax.servlet.annotation.WebServlet; > > > > >>> import javax.
Re: Performance regression from 7 to 8
Tullio,
as suggested before by Felix, maybe you should try different connector
configurations (defaults for HTTP connector are different between T7
(blocking) and T8 (non-blocking)) and see if this changes anything.
For example in the server.xml file :
and
Your code is simple, only buffering and writing to an OutputStream. Don't
know how, but I believe that only the buffering can introduce some delay.
best regards
2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi :
> As I already explained is not a reproductable problem.
> I tested the testcase in my environment and I reproduced the problem on
> some clients but not on all clients : the same clients where I noticed the
> problem in the real application.
> I'm not able to understand what's the relevant difference among them (not
> OS version, not network, not browser).
> The problem disappears using tomcat 7.
> Tks
> Tullio
>
> > Subject: Re: Performance regression from 7 to 8
> > To: users@tomcat.apache.org
> > From: ma...@apache.org
> > Date: Mon, 7 Mar 2016 11:52:40 +
> >
> > On 06/03/2016 08:45, Tullio Bettinazzi wrote:
> > > I tested with 8.20 and 8.32
> > > With nothing changed I meant simply that results didn't change.
> >
> > I can't repeat the problem you are describing with your provided test
> case.
> >
> > I ran:
> > - ab -k -n 1000 -c 1 localhost:8080/user002/Test
> > - latest 8.0.x code
> > - your test case with and without setting the content length (as an
> > HTTP/1.0 client ab needs the content length to use keep-alive with
> > large response bodies
> >
> > I saw average response times of 6ms with a maximum of 9ms.
> > The content length header made no difference (apart from keep-alive
> > being used as expected).
> >
> > If the problem you are describing was widespread I'd expect to see other
> > users reporting this on the mailing list.
> >
> > Given that:
> > - I can't repeat this
> > - Other users aren't reporting it
> > - Only you are seeing the issue
> >
> > this looks like an issue with your environment rather than with Tomcat.
> > I'd recommend using tools like Wireshark and YourKit to find out exactly
> > what is going on.
> >
> > Mark
> >
> >
> > > Tks
> > > Tullio
> > >
> > >> Subject: Re: Performance regression from 7 to 8
> > >> To: users@tomcat.apache.org
> > >> From: ma...@apache.org
> > >> Date: Sat, 5 Mar 2016 18:40:36 +
> > >>
> > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote:
> > >>> Done and nothing changed.
> > >>
> > >> What has changed is that you have now provided a test case that
> someone
> > >> else can run easily and confirm, or not, your findings.
> > >>
> > >>> Any suggestion ?
> > >>
> > >> Before anyone spends time looking at this the other question I don't
> see
> > >> answered in this thread is "Exactly which Tomcat 8 version were you
> > >> testing?". If it isn't the the latest then you'll need to retest to
> > >> confirm the issue hasn't already been fixed.
> > >>
> > >> Mark
> > >>
> > >>> Here the code.
> > >>>
> > >>> package axioma.rubik.engine.web.servlet;
> > >>>
> > >>> import java.io.*;
> > >>> import javax.servlet.ServletException;
> > >>> import javax.servlet.annotation.WebServlet;
> > >>> import javax.servlet.http.*;
> > >>>
> > >>> @WebServlet(name="Test8", description="Direct update of data",
> urlPatterns={"/Test8"})
> > >>> public class Test8Servlet extends HttpServlet {
> > >>>
> > >>> private static final long serialVersionUID = 1L;
> > >>>
> > >>> @Override
> > >>> protected void doGet(HttpServletRequest request,
> HttpServletResponse response) throws ServletException, IOException {
> > >>> try {
> > >>> fai(response);
> > >>> } catch (Exception ex) {
> > >>> ex.printStackTrace();
> > >>> }
> > >>> }
> > >>>
> > >>> public void fai(HttpServletResponse response) throws IOException
> {
> > >>> ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> > >>> BufferedOutputStream bos = new BufferedOutputStream(bbs);
> > >>> for(int i = 0; i < 40; i++) {
> > >>> bos.write(96);
> > >>> }
> > >>> bos.flush();
> > >>> bbs.writeTo(response.getOutputStream());
> > >>> }
> > >>> }
> > >>
> > >>
> > >> -
> > >> 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: Enabling SSLv2 on Tomcat 7 !
Hello, there are many reasons not to use SSLv2 and this is why JDK6 doesn't support it. If you're really talking about SSLv2 and not SSLv2 Client-Hello, so you need to use the IBM JSSE implementation. But, I am unsure that you need this. best regards 2016-02-19 13:05 GMT+01:00 Utkarsh Dave : > I upgraded my tomcat from 7.0.53 ( that was having SSL protocols enable) to > 7.0.67 (that has by default SSL protocols disable). > > To re enable support for SSLv3 and SSLv2, i modified the server.xml inside > $TOMCAT_HOME/conf to replace sslProtocol="TLS" with > sslEnabledProtocols="SSLv2,SSLv3,TLSv1" > > I can test the SSLv3 requests successfully now , but SSLv2 requests still > fails. > They were processing through success before the upgrade of Tomcat. > > I am using the JDK1.6 and Redhat platform and openssl version 0.9.8h. > > Please let me know if i can enable SSLv2 on the newer Tomcat. > > -Thanks > Utkarsh >
Re: I need expert to solve problem(pay)
Edwin, we're not expecting money here. Please tell us what your problem is. 2016-02-04 20:37 GMT+01:00 Edwin Quijada : > Hi! > I dont know if I must put this message here but I am exhaust about this. I > need a tomcat expert about configuration to solve a problem with my > installation of course I will pay for your service. > > The problem is just configuration but I dont want stuck anymore. > > > Sorry if the rigth place is not here >
Re: troughput difference
Hi probably this won't solve your problem but I notice that the random seems slow : Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [9,870] milliseconds. Maybe should you then start by fixing this, it has been discussed many times on the mailing list ( securerandom.source=file:/dev/./urandom ) Maybe are there some tests to do to understand if your Tomcat 6 seems fast because it uses some caching somewhere, or on the contrary if your Tomcat 8 is slow because there is a bottleneck. I would try one scenario with one small HTML page requested thousands of times, and one very big file requested just 2 or 3 times, and compare results. One thing which could help in understanding, have a look at the status servlet which gives statistics ( http://tomcat.apache.org/tomcat-7.0-doc/apr.html ) best regards 2015-12-23 21:29 GMT+01:00 Christopher Schultz : > Rafael, > > On 12/23/15 2:12 PM, Rafael Oliveira de Mattos wrote: > > Christopher, > > > > Tomcat 6: boot.log > > INFORMA합ES: Loaded APR based Apache Tomcat Native library 1.1.33 using > APR version 1.5.2. > > dez 14, 2015 5:32:14 PM org.apache.catalina.core.AprLifecycleListener > init > > INFORMA합ES: APR capabilities: IPv6 [true], sendfile [true], accept > filters [false], random [true]. > > dez 14, 2015 5:32:15 PM org.apache.coyote.http11.Http11AprProtocol init > > INFORMA합ES: Initializing Coyote HTTP/1.1 on http-8180 > > dez 14, 2015 5:32:15 PM org.apache.coyote.ajp.AjpAprProtocol init > > INFORMA합ES: Initializing Coyote AJP/1.3 on ajp-8109 > > dez 14, 2015 5:32:15 PM org.apache.catalina.startup.Catalina load > > INFORMA합ES: Initialization processed in 1155 ms > > dez 14, 2015 5:32:15 PM org.apache.catalina.core.StandardService start > > INFORMA합ES: Starting service Catalina > > dez 14, 2015 5:32:15 PM org.apache.catalina.core.StandardEngine start > > INFORMA합ES: Starting Servlet Engine: Apache Tomcat/6.0.36 > > dez 14, 2015 5:32:18 PM org.apache.catalina.core.ApplicationContext log > > INFORMA합ES: Initializing Spring root WebApplicationContext > > dez 14, 2015 5:32:25 PM org.apache.catalina.startup.HostConfig > deployDescriptor > > INFORMA합ES: Deploying configuration descriptor manager.xml > > dez 14, 2015 5:32:26 PM org.apache.catalina.startup.HostConfig > deployDescriptor > > INFORMA합ES: Deploying configuration descriptor host-manager.xml > > dez 14, 2015 5:32:26 PM org.apache.catalina.startup.HostConfig > deployDirectory > > INFORMA합ES: Deploying web application directory ROOT > > dez 14, 2015 5:32:27 PM org.apache.coyote.http11.Http11AprProtocol start > > INFORMA합ES: Starting Coyote HTTP/1.1 on http-8180 > > dez 14, 2015 5:32:27 PM org.apache.coyote.ajp.AjpAprProtocol start > > INFORMA합ES: Starting Coyote AJP/1.3 on ajp-8109 > > dez 14, 2015 5:32:27 PM org.apache.catalina.startup.Catalina start > > INFORMA합ES: Server startup in 11791 ms > > > > > > tomcat 8: boot_tomcat8.log > > Dez 23, 2015 7:48:16 AM org.apache.catalina.core.AprLifecycleListener > lifecycleEvent > > INFORMAÇÕES: Loaded APR based Apache Tomcat Native library 1.1.33 using > APR version 1.5.2. > > Dez 23, 2015 7:48:16 AM org.apache.catalina.core.AprLifecycleListener > lifecycleEvent > > INFORMAÇÕES: APR capabilities: IPv6 [true], sendfile [true], accept > filters [false], random [true]. > > Dez 23, 2015 7:48:16 AM org.apache.coyote.AbstractProtocol init > > INFORMAÇÕES: Initializing ProtocolHandler ["http-apr-8180"] > > Dez 23, 2015 7:48:16 AM org.apache.coyote.AbstractProtocol init > > INFORMAÇÕES: Initializing ProtocolHandler ["ajp-apr-8109"] > > Dez 23, 2015 7:48:16 AM org.apache.catalina.startup.Catalina load > > INFORMAÇÕES: Initialization processed in 2341 ms > > Dez 23, 2015 7:48:23 AM org.apache.jasper.servlet.TldScanner scanJars > > INFORMAÇÕES: At least one JAR was scanned for TLDs yet contained no > TLDs. Enable debug logging for this logger for a complete list of JARs that > were scanned but no TLDs were found in them. Skipping unneeded JARs during > scanning can improve startup time and JSP compilation time. > > Dez 23, 2015 7:48:43 AM org.apache.catalina.util.SessionIdGeneratorBase > createSecureRandom > > INFORMAÇÕES: Creation of SecureRandom instance for session ID generation > using [SHA1PRNG] took [9,870] milliseconds. > > > > > > The apr loader configuration in both setup > > > > className="org.apache.catalina.core.AprLifecycleListener"/> > > Thanks for confirming that: often, we have people with two radically > different setups wanting to know why things are behaving differently. > > There have been many changes to the connector code between Tomcat 6 and > Tomcat 8, mostly to make sure that as many code paths are shared between > connectors (BIO, NIO, APR) as possible. I wouldn't have been surprised > to see a measurable performance difference, but I figured it would be on > the order of 10%-25%. Instead, you are seeing a 100%-150% difference. > > Someone with more knowledge of the connector code would have to comment > on what
Re: Tomcat unresponsive
"Form tomcat log i can say that request has been received from client side" What is saying the Tomcat access log ? Are there lines with response size = 0 ? 2015-12-04 19:13 GMT+01:00 Christopher Schultz : > Yogesh, > > On 12/4/15 9:26 AM, Yogesh Patel wrote: > > Hi, > > > > We have a Apache and tomcat : > > > > Form tomcat log i can say that request has been received from client side > > but some how response could not deliver to Apache. > > > > And in apache log we found following log: > > > > "AH00992: ajp_read_header: ajp_ilink_receive failed" > > > > What makes tomcat unresponsive to apache. in tomcat log there is no logs > > for max thread busy. > > Can you turn-up the log level on mod_jk? (or are you using mod_proxy_ajp?) > > Sanity check: make sure that your max_packet_size (in httpd/mod_jk) > matches the related setting in your in Tomcat. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Apache httpd / mod_proxy_ajp logging
That is right, Chris. On 2.2, maybe LogLevel debug would give information about proxy traffic but I did not try. 2.2 is legacy anyway, and less efficient from I what see on my hosting platform. 2015-12-04 19:21 GMT+01:00 Christopher Schultz : > Aurélien, > > On 12/4/15 10:36 AM, Aurélien Terrestris wrote: > > "Would anyone here know what is available in that respect with > > mod_proxy_ajp ?" > > > > You could try this : > > > > LogLevel proxy:trace8 > > That only works for httpd 2.4+, right? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Apache httpd / mod_proxy_ajp logging
"Would anyone here know what is available in that respect with mod_proxy_ajp ?" You could try this : LogLevel proxy:trace8 2015-12-03 22:41 GMT+01:00 André Warnier (tomcat) : > Hi. > > Although the above module is a httpd-level, this might still be the right > place to ask : > > I am usually using mod_jk as an Apache httpd / Tomcat connector. > With mod_jk, there is a separate JkLogLevel directive to set the log > level, and also a separate logfile. > > Would anyone here know what is available in that respect with > mod_proxy_ajp ? > Can I trace at the httpd level what is actually being proxied to Tomcat ? > > Thanks. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Monitoring Connections
Hi Chris I still recommend SNMP, maybe I expressed myself incorrectly but Java SNMP support is made for monitoring. I also provided a bad link, here is the good one : http://docs.oracle.com/javase/7/docs/technotes/guides/management/snmp.html When using the right server, the SNMP will also provide alerting, both for counters and deltas. This is the critical point for large scale teams with N1 support, although developers often want something else and need more (logs, instrumentation). In "Effective Monitoring and Alerting, O'Reilly" we find these definitions that we already agree, I believe : "The main purpose of monitoring is to gain near real-time insight into the current state of the system, in the context of its recent performance" "The core functionality of an alarm is to trigger on detection of abnormal timeseries behavior, but the alerting system should also support the aggregation and conditional suppression of alarms." In my opinion, SNMP could be more used, and I notice that nobody is talking about this technology for years on the mailing-list. It's a pity to ignore solutions. best regards 2015-11-03 16:05 GMT+01:00 Christopher Schultz : > Aurelien, > > On 11/2/15 5:54 PM, Aurélien Terrestris wrote: > > Either my reply was not read, or I'm surprised nobody is answering here. > > > > "1. Java doesn't directly support SNMP;" > > > > It does, officially : > http://docs.oracle.com/javase/7/docs/technotes/guides/ > > management/snmp.html and it's working pretty well with Tomcat besides > being > > easy to set up. > > I meant there was no client API > > > "2. If the JVM is braindead, the SNMP agent can't announce any state to > > the managers." > > > > Agent ? This is the SNMP server which is polling the Tomcat here. When > > Tomcat is dead, the server cannot poll anymore and raises an alert. > > You were recommending the use of SNMP as an "alerting" alternative to > "monitoring". I assumed you had meant that more passive "alerting" (e.g. > only take action when a problem is occurring) was more efficient than > "monitoring" (which I took to mean polling a service to check its status). > > So polling is less efficient but more reliable. Whether you use SNMP, > JMX, HTTP, or whatever, *polling* a component is better than having a > component try to report that it's failing, because part of the failure > could be its inability to report the failure state. > > This isn't about SNMP versus some other technology. It's about probing > versus ... not doing so, I guess. > > > You see how alerting is even easier without instrumenting, but maybe you > > want to go deeper. But then, you probably start mixing what's necessary > for > > N1 support with what's helpful for developers. They have different jobs. > > What is your definition of "instrumentation"? What about "probing" or > "alerting"? I'm certainly confused with your use of terms, especially > when you equate one of them with a particular technology. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Monitoring Connections
Either my reply was not read, or I'm surprised nobody is answering here. "1. Java doesn't directly support SNMP;" It does, officially : http://docs.oracle.com/javase/7/docs/technotes/guides/ management/snmp.html and it's working pretty well with Tomcat besides being easy to set up. "2. If the JVM is braindead, the SNMP agent can't announce any state to the managers." Agent ? This is the SNMP server which is polling the Tomcat here. When Tomcat is dead, the server cannot poll anymore and raises an alert. You see how alerting is even easier without instrumenting, but maybe you want to go deeper. But then, you probably start mixing what's necessary for N1 support with what's helpful for developers. They have different jobs. best regards A.T. 2015-10-24 14:18 GMT+02:00 Christopher Schultz : > Aurélien, > > On 10/23/15 6:47 PM, Aurélien Terrestris wrote: > > "Live monitoring is the only way to go, unless you want your customers > > to surprise you with performance problems on your own site. :)" > > > > Monitoring, ok, but alerting is critical for large scale production > > environments. > > Apologies... I already considered "alerting" to be a critical component > of "monitoring", so I didn't mention it specifically. Instrumentation is > the hard part; alerting is relatively easy once instrumentation has been > done. > > > You mention JMX callbacks for alerting, but it would be worth > > that you mention SNMP since it's very easy to set up and efficient. > > SNMP is great, but there are a few problems with using it with Java: > > 1. Java doesn't directly support SNMP; instead, you have to use >a 3rd-party library (which isn't difficult to find). This may be >a barrier for certain organizations who only want to use their >own code in their own applications. > > 2. If the JVM is braindead, the SNMP agent can't announce any state >to the managers. This requires the use of probe-based instrumentation >(active probing from the outside of the application), unless you want >to have an agent send a heartbeat for every status change. > > > We also can raise alerts on deltas with this method, and see a > > problem before the CPU says something bad is going to happen. > > There's nothing stopping you from doing deltas with other techniques. My > presentation even includes a tool that allows you to do deltas. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: AW: Suppress or replace WWW-Authorization header
You can choose between a pop-up or an HTML FORM This one looks like this in web.xml : FORM webapp global realm /login.jsp /error_login.jsp 2015-10-28 16:28 GMT+01:00 Torsten Rieger : > -Ursprüngliche Nachricht- > Von: Christopher Schultz [mailto:ch...@christopherschultz.net] > Gesendet: Mittwoch, 28. Oktober 2015 15:39 > An: Tomcat Users List > Betreff: Re: AW: Suppress or replace WWW-Authorization header > > Torsten, > > On 10/28/15 8:19 AM, Torsten Rieger wrote: > > I have a legacy java-SOAP-client that only supports BASIC > > authentication (send the Authorization: Basic... header) and a > > AngularJS application that consumes a REST-service (also sending the > > Authorization: Basic header). > > > > The server supports two kinds of deployment: Standalone with an > > embedded Jetty-server and as war-file for app-servers (most of them > > are tomcat-server). I try to suppress the browser BASIC-login-dialog > > for the REST-service-calls from AngularJS. > > On Jetty I modify the 401-responses and replace the "WWW-Authenticate" > > header by anything else than "BASIC" and that works, now I try to find > > a solution for the deployment on tomcat servers. > > > > Rewrite (unset header in responses) with an apache proxy in front of > > the tomcat is unfortunately not a solution I can implement. > > > > So I'm looking for a solution to remove or modify the headers in 401 > > responses on application server level. > > So you just want to disable HTTP BASIC authentication? Why not just remove > the from web.xml and disable authentication entirely? > > Are you saying that when you connect using a REST client, the client shows > a > login dialog in a web browser? That sounds ... weird. The REST client > should > see the WWW-Authenticate header and either (a) fail or (b) re-try with > credentials you have provided to it. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > No, container BASIC authentication should be enabled, the container should > handle the authentication, but the browser should not show his ugly default > login dialog when I request resources from the REST-service with wrong > credentials. > When the REST-client (web-application in the browser) receives a failed > login with a WWW-Authenticate header, the default dialog of the browser > will > be shown... that’s what I want to suppress. > > When I remove the (a) or (b) sending requests > with credentials will not work anymore (a: 403 forbidden; b: deployment > fails). But that's not a solution because the rest-service should be still > protected and I need to authenticate via "Authentication: Basic ." > header send credentials, but I don't want to show the ugly browser-dialog > to > the users. > > Using a AngularJS Client with REST-services based on tomcat should be a > common use-case, it could not be that I'm the first one who wants a custom > login-screen. :-/ > > -torsten > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Monitoring Connections
Chris, I disagree in some way with you ;) Instrumentation is difficult because you (as a developer ?) want to go deep, but it is not necessary for a production team to go that deep to know when something is going wrong. It's a developer challenge, and he could choose to rely only on good logging. Whatever happens, there should be at least some logs for the production team, then they can 'grep' for SEVERE or Exceptions before asking more help to the N2 or N3 team. "1. Java doesn't directly support SNMP;" Sorry, but it does ( http://docs.oracle.com/javase/7/docs/technotes/guides/management/snmp.html ) and we use it with good results (deltas on GCs for example). Maybe are you confusing with the fact that Java has no built-in API for SNMP software developers. "2. If the JVM is braindead, the SNMP agent can't announce any state to the managers." The SNMP server will be unable to check the JVM, it will raise an alert. Easy, cheap, and in most cases enough ;) best regards A.T. 2015-10-24 14:18 GMT+02:00 Christopher Schultz : > Aurélien, > > On 10/23/15 6:47 PM, Aurélien Terrestris wrote: > > "Live monitoring is the only way to go, unless you want your customers > > to surprise you with performance problems on your own site. :)" > > > > Monitoring, ok, but alerting is critical for large scale production > > environments. > > Apologies... I already considered "alerting" to be a critical component > of "monitoring", so I didn't mention it specifically. Instrumentation is > the hard part; alerting is relatively easy once instrumentation has been > done. > > > You mention JMX callbacks for alerting, but it would be worth > > that you mention SNMP since it's very easy to set up and efficient. > > SNMP is great, but there are a few problems with using it with Java: > > 1. Java doesn't directly support SNMP; instead, you have to use >a 3rd-party library (which isn't difficult to find). This may be >a barrier for certain organizations who only want to use their >own code in their own applications. > > 2. If the JVM is braindead, the SNMP agent can't announce any state >to the managers. This requires the use of probe-based instrumentation >(active probing from the outside of the application), unless you want >to have an agent send a heartbeat for every status change. > > > We also can raise alerts on deltas with this method, and see a > > problem before the CPU says something bad is going to happen. > > There's nothing stopping you from doing deltas with other techniques. My > presentation even includes a tool that allows you to do deltas. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Monitoring Connections
Chris, "Live monitoring is the only way to go, unless you want your customers to surprise you with performance problems on your own site. :)" Monitoring, ok, but alerting is critical for large scale production environments. You mention JMX callbacks for alerting, but it would be worth that you mention SNMP since it's very easy to set up and efficient. We also can raise alerts on deltas with this method, and see a problem before the CPU says something bad is going to happen. Just my feedback ;) regards 2015-10-08 19:27 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 10/7/15 5:59 PM, Aurélien Terrestris wrote: > > when this happens you can do a thread-dump (kill -3 pid on Linux > > platforms) and you would see if there is a lock on JDBC objects, or > > anything else synchronized (from the Collections like Hashtable). > > Not easy for beginners to understand a dump, but worth learning. > > +1 > > This is the only way to find out what's going on. All other monitoring > solutions will just tell you that *something* is wrong, but this will > give you details. > > > Very often an application will slow down because Garbage > > Collection, and the GC thread will be the only one working at that > > time. Please use the verbose settings to have all your Tomcats log > > GC activity. This is useful for both live and after time analysis. > > This is pretty unlikely for the reported observations, since Tomcat > slows down and stops responding (presumably until restarted). That is > more likely to be something like database connection pool being > exhausted due to poor resource management rather than out-of-control > GC activity. > > > You won't monitor mod_proxy, this has no sense. > > I disagree. The connection can go down for various reasons. But I > suspect that's not the problem in this case. > > > If you suspect a network flood, do a 'netstat -an' to see how many > > connections are used by your Apache (both ESTABLISHED and > > TIME_WAIT). However, you might need to set timeout and flushpacket > > on your proxypass directive when your application has such > > requirements (see HTTPD doc for this settings). To know if you're > > flooded, you can do a 'ps -eaf | grep [h]ttp' and you would see > > many httpd process, it is similar to the netstat result more or > > less. > > +1 > > > If you enjoy live monitoring, you need to have a look on > > Christopher's presentation ( > > http://events.linuxfoundation.org/sites/events/files/slides/Monitoring > %20Apache%20Tomcat%20with%20JMX.pdf > > > > > ) who posts many answers to this mailing list. > > Live monitoring is the only way to go, unless you want your customers > to surprise you with performance problems on your own site. :) > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJWFqd5AAoJEBzwKT+lPKRYi9AQAIpHkOgXoz2Ntfdf8aH1mjTB > gdKDu1B5fEgpTYRhV+mQ5rEegkszJ0jUEQdCVjwp2ZjldgsLPP6wXaBw6LdUG3UB > l63K4tCkDwIiVI8rB0syAeQQ/4uUS7SmiJaLZAwLHl08mDZHs9e/LiKJ47rJjh3+ > 4pkejtbHhobF2fcH61ZM7M5qxPKlzP49dDzXyppbvEG/kk7T9FkIl2TVOT349zkP > c1jrtC19fKDhbz72c/03/Z1V/clZ+Q3BScYHddlRw0ZXuOEu8LQJRD0VPmEY4pM5 > DTPH+z5spnYUO0hH0FHx/WGHgQ5iCrQHYG8pdkfhDEqSaDnqm4qIFxC4fChIFSuh > c9eqor7axyOcacHvTCwPudXGuWBxK0LCnigikd83OM/EaKdRwR0ahMqXKEQkRdTn > QW3vfsOQXXuy0vAFz6fphOkWXCr4SJWVOsAG3f1vlStMs2to4q66hpNQpLFJpcdN > ectoRaCRvQMLdw9UhdG3z5wTCvPPj9RP8IA/Lxi48QisYOMZwABgh7mMh2+mE7pH > tTHun4fE2HhdVPqORonHhTWldvu4xYqWav9FNBgg2ywyekAWVcrcFZRLgYhG+T37 > 0neZbSdwd/iLdsZ+sKhGY04CSwAsUZdTh87pZ+8NWH7tvi71JIt7nlI0JgRI5ipw > Jdty982ew2WiaY0rhspW > =Ra47 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Wireshark support for Tomcat clusters
For those interested, the Wireshark 2.0 which is now running the RC process, has a built-in dissector for Tomcat clusters (named ATH for Apache Tribes Heartbeat) regards
Re: Monitoring Connections
> I know mod_jk will complain if it can't > make a connection or if there is a timeout... I suspect mod_proxy_http > will do the same. They both are supposed to log 502, while Tomcat will raise a "connection reset by peer" when answering to an already closed connection. Timeouts for both are buggy until, if I remember well, Apache 2.2.17 (see : http://www.spinics.net/lists/apache-users/msg93765.html ), behaving with a timeout 4 times too short. I suppose this was hard-coded for test reasons, and just forgotten. They never replied on this anyway, and please check if you're not running this old bugged Apache. As said by Chris, your server seems quiet, and this means the problem might be out there. Uploading files ? Please check if there is any virus scanner software on the server, this might be an explanation. Have a look on the server if you can find the temporary file which is being uploaded, and what is its size (more than 100 megs ??) When the problem happens again, don't forget to do a 'netstat -an'. There, it will be important to check if there is any SYN_SENT connections, showing a network problem. Another thing more difficult if the problem is related to DNS solving which could be stalled for any reason. You can try some nslookup commands when the problem happens and compare with normal nslookup (what DNS server answered ?) ; you also can install a BIND on your server and make it log everything, this would give you logs for after crash analysis. Or let run a 'tcpdump port 53' and save its capture for later analysis. regards A.T. 2015-10-21 20:58 GMT+02:00 Christopher Schultz : > Jamie, > > On 10/21/15 2:37 PM, Jamie Jackson wrote: > > On Wed, Oct 21, 2015 at 1:03 PM, Christopher Schultz wrote: > > > >> Jamie, > >> > >> > >> > >> Your mostly-default will default to a maximum of 200 > >> incoming connections with 200 threads to handle them. You are only using > >> 12, so something else must be going on. You have no obvious limits on > >> httpd, so you are probably using the default there as well > >> (coincidentally, also in the 200-connection range). > >> > >> That's a high connection timeout: 93 seconds (why 93?). Note that the > >> connectionTimeout sets the amount of time Tomcat will wait for a client > >> to send the request line (the "GET /foo HTTP/1.1"), not the amount of > >> time the request is allowed to run -- like for an upload, etc. I usually > >> lower this setting from the default of 60 seconds to more like 5 or 10 > >> seconds. Clients shouldn't be waiting a long time between making a > >> connection and sending a request. > >> > >> This timeout also applies to subsequent requests on a keep-alive > >> connection. So if the browser opens a connection and sends 1, 2, 3 > >> requests, Tomcat will hold that thread+connection open for 93 seconds > >> after the last request (assuming the client doesn't terminate the > >> connection, which it might NOT) before allowing other clients to be > >> serviced by that thread. This is a BIO-Connector-only behavior. The > >> NIO/NIO2 and APR connectors don't hold-up the request thread waiting for > >> a follow-up keep-alive request from a client. > >> > > > > Thanks for the info. It seems as if connectionTimeout is almost > universally > > misunderstood to mean something like "request timeout," (which is why it > > had been high--to accommodate things like long responses and file > uploads). > > It seems possible that we could be using up too many threads for too long > > because of the effect of this long timeout on keep-alives. > > While that's true, you should something like 185 threads "in reserve" > and so the server shouldn't grind to a halt and not let anyone else in. > If there are other components in the mix, those could prevent more > connections (e.g. load-balancer, QOS component, etc.) or even if you are > trying to connect from a single web browser with a 4-connection limit, > you'll obviously only be able to upload 4 files at a time. > > But you didn't say anything about that kind of thing, so I assume it's > not the issue. > > > The only time I can think of that a client would be taking any kind of > time > > between connection and sending the request URI line is if someone is > > manually interacting (say, via telnet). I'm going to follow your lead and > > reduce this. > > I wouldn't reduce it past the default of 60 seconds (6ms) unless you > are observing client-starvation. > > > I doubt that this is the *sole* culprit, but it *is* something for me to > > tweak. > > I would read the whole HTTP-Connector configuration reference -- > especially the "timeout" related items -- and make sure you understand > them all before setting any of them. The defaults are reasonable, but > every environment has its own special set of requirements. > > I don't think the timeouts are the issue. What else can you tell us > about the behavior of the server when it "crashes"? I don't think you > have really described the actual problem
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
George, I'm not sure we can find any solution, but can we have a look at a pcap capture ? Esmond Pitt was posting sometimes, that would be a challenge for him. 2015-10-15 4:33 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 10/14/15 5:59 PM, Aurélien Terrestris wrote: > > Still no solutions, I suppose.. > > > > Did you enable the SSLv2 Hello as suggested by Chris, and what's > > the result ? I tested a small client with Java 8, by adding > > -Djdk.tls.client.protocols="SSLv2Hello,TLSv1.2" at the command > > line, and I get my SSLv2 Hello. > > It looks like if you add SSLv2Hello to the list of protocols you'll > accept, you'll get an SSLv2Hello in there (abridged output): > > Allow unsafe renegotiation: false > Allow legacy hello messages: true > Is initial handshake: true > Is secure renegotiation: false > ... > main, WRITE: TLSv1.2 Handshake, length = 221 > main, WRITE: SSLv2 client hello message, length = 140 > main, READ: TLSv1.2 Handshake, length = 81 > main, READ: TLSv1.2 Handshake, length = 2779 > main, READ: TLSv1.2 Handshake, length = 589 > main, READ: TLSv1.2 Handshake, length = 4 > main, WRITE: TLSv1.2 Handshake, length = 70 > main, WRITE: TLSv1.2 Change Cipher Spec, length = 1 > main, WRITE: TLSv1.2 Handshake, length = 40 > main, READ: TLSv1.2 Change Cipher Spec, length = 1 > main, READ: TLSv1.2 Handshake, length = 40 > > You just have to use a custom SSLSocketFactory that sets the protocols > you want to enable on the (client) socket. If one of the protocols you > use is "SSLv2Hello". > > Oddly enough, when *not* specifying SSLv2Hello, you'll get this > (abridged output): > > Allow unsafe renegotiation: false > Allow legacy hello messages: true > Is initial handshake: true > Is secure renegotiation: false > ... > main, WRITE: TLSv1.2 Handshake, length = 221 > main, READ: TLSv1.2 Handshake, length = 89 > main, READ: TLSv1.2 Handshake, length = 2779 > main, READ: TLSv1.2 Handshake, length = 589 > main, READ: TLSv1.2 Handshake, length = 4 > main, WRITE: TLSv1.2 Handshake, length = 70 > main, WRITE: TLSv1.2 Change Cipher Spec, length = 1 > main, WRITE: TLSv1.2 Handshake, length = 40 > main, READ: TLSv1.2 Change Cipher Spec, length = 1 > main, READ: TLSv1.2 Handshake, length = 40 > > When the SSLv2Hello "protocol" isn't enabled, you don't get the "main, > WRITE" and "main, READ" > > Note that I'm not trying anything with a client certificate, here. I > hope that helps somewhat. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJWHxCIAAoJEBzwKT+lPKRYCNQQAMJx3cHj3Rl8ieX+2cANmXfW > fHr0MPkHNIcbzpX5WWJaEqfhnYqQTk9TiY7rKxwjo3OtJtEG1bkm9tqeq4pzHJcX > oQ03/wMOKrNqqGoILcpdWgRpc0jylsx1GouJ2qmmCNvZO1fBdBhtAE49dvg4Hd+c > uOzet5CizkTIfbu/i2Rb/szC9T/mopvicOsoS7oe1EE7sJZKL4BU3ayun5KvFXvr > 0KbDRU0Btp3M0YcPP4R2MtExYROW9pwwb5UYJdmK8ZxHAsmhJsG8DzDQnywFEx3+ > cm2e0W5v5FMAAh3PBNqfl5VN/8uIlHkeLtCjDU0JCMCfguwTQbitPpyhatnRlE7z > K8FfdZUC2zBprX1HnJl5aT02u3STzRsyL5DWlVAKPC/OAUEYFO26Ira1K86ACpww > O7t6phwHfXdGIkT/GdT9i2DgGippj6/mAhgq6XUsAkVr9usK33pNP8q/jf/ORwq/ > Njf4d4vjRNw3W7UZ0w0NCgZ7dKdepC/x2sT6zugQugiLNQ+gHGQWfcOhrQsRsj8f > qHGU1E+94g5oQCqb14KWoZv8bAA2WYAqgUK3DK2icsiCEFqWd6Yb6gYcvIGsbV9t > g+Mtxfm5qjncCwHeyONd3uBWTjakZb7fIvk4di0pZcnZB7HFYx7/r0ndS+IRzUVS > LJxWiHhKQZ32QvVKtBxe > =zKZ4 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
Still no solutions, I suppose.. Did you enable the SSLv2 Hello as suggested by Chris, and what's the result ? I tested a small client with Java 8, by adding -Djdk.tls.client.protocols="SSLv2Hello,TLSv1.2" at the command line, and I get my SSLv2 Hello. >From the TLS 1.2 RFC ( https://www.ietf.org/rfc/rfc5246.txt ) we know we must expect some problems like yours (Appendix E.1 & E.2). I'm not saying it's that kind of things for sure, but this is what they suggest : "Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client." And that's what HttpUrl class does, a retry. I am not sure that we can blindly trust the JSSE Ref Guide , but it's saying that the renegotiation (for your client cert) has to happen after some data was already been sent to each other. My question is : are you sure you are not doing 2 handshakes without sending data between them ? See : https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization *"Encrypted data* The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated during the client hello and server hello, and using the secret key that the client sent to the server during the client key exchange. The handshake can be renegotiated at this time. See the next section for details." 2015-10-14 4:56 GMT+02:00 George Stanchev : > So this time I spoke too soon. I was relying on Java to dump in its debug > trace. Running rawcap/wireshark does reveal that Java indeed wraps the > TLSv1.2 hello payload in SSLv2Hello record envelope which that legacy > protocol enables. The Java piece of code that I quoted was for the content > of the ClientHello record, not how it is wrapped which happens later when > the record is being serialized to the socket... > > Anyways, thanks to all for the tip but it doesn't make a > difference...still bad mac record... > > George > > -Original Message- > From: George Stanchev [mailto:gstanc...@serena.com] > Sent: Tuesday, October 13, 2015 3:56 PM > To: Tomcat Users List > Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > May be I am mistaken. I will give jtouch a try, thanks for the > pointers...at this point I am grasping at straws :) > > Thanks Aurelien! > > -Original Message- > From: Aurélien Terrestris [mailto:aterrest...@gmail.com] > Sent: Tuesday, October 13, 2015 3:52 PM > To: Tomcat Users List > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > "Another route to try the SSLv2Hello is to hack and recompile the JSSE. > It's on my agenda to learn to do that if possible without rebuilding the > whole JRE since for some obscure reason Oracle compiles JSSE with no debug > info (and it is not included in the srcs distributed with the JRE) on it > which makes debugging and inspecting local vars really hard..." > > No, it's not needed. I use jtouch.sourceforge.net and it's working well > for trying SSLv2 hello's. From the network captures, I see that it's > working. > Not making advertisement for my software here, but,.. ;) > > > > > > > > 2015-10-13 23:20 GMT+02:00 George Stanchev : > > > Just as a side note, https.protocols is read by HttpsUrlConnection > > which feeds it down through setEnabledProtocols() on the SSL socket. " > > jdk.tls.client.protocols" is read directly by JSSE and does the same > > thing... > > > > Another route to try the SSLv2Hello is to hack and recompile the JSSE. > > It's on my agenda to learn to do that if possible without rebuilding > > the whole JRE since for some obscure reason Oracle compiles JSSE with > > no debug info (and it is not included in the srcs distributed with the > > JRE) on it which makes debugging and inspecting local vars really hard... > > > > George > > > > -Original Message- > > From: Aurélien Terrestris [mailto:aterrest...@gmail.com] > > Sent: Tuesday, October 13, 2015 3:13 PM > > To: Tomcat Users List > > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > > description = bad_record_mac > > > > Maybe writing too fast.. > > > > "How do you force Java 8 to use SSLv2Hello?" > > > > As suggested before, by writing your own client OR by trying this hack. > > From the JSSE Ref Guide 5, we know how to the customize the protocol ( > > https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefG > > uide.ht
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
"Another route to try the SSLv2Hello is to hack and recompile the JSSE. It's on my agenda to learn to do that if possible without rebuilding the whole JRE since for some obscure reason Oracle compiles JSSE with no debug info (and it is not included in the srcs distributed with the JRE) on it which makes debugging and inspecting local vars really hard..." No, it's not needed. I use jtouch.sourceforge.net and it's working well for trying SSLv2 hello's. From the network captures, I see that it's working. Not making advertisement for my software here, but,.. ;) 2015-10-13 23:20 GMT+02:00 George Stanchev : > Just as a side note, https.protocols is read by HttpsUrlConnection which > feeds it down through setEnabledProtocols() on the SSL socket. " > jdk.tls.client.protocols" is read directly by JSSE and does the same > thing... > > Another route to try the SSLv2Hello is to hack and recompile the JSSE. > It's on my agenda to learn to do that if possible without rebuilding the > whole JRE since for some obscure reason Oracle compiles JSSE with no debug > info (and it is not included in the srcs distributed with the JRE) on it > which makes debugging and inspecting local vars really hard... > > George > > -Original Message- > From: Aurélien Terrestris [mailto:aterrest...@gmail.com] > Sent: Tuesday, October 13, 2015 3:13 PM > To: Tomcat Users List > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > Maybe writing too fast.. > > "How do you force Java 8 to use SSLv2Hello?" > > As suggested before, by writing your own client OR by trying this hack. > From the JSSE Ref Guide 5, we know how to the customize the protocol ( > https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization > ) by setting a system property (https.protocol). Although they are no more > talking about this in the Ref Guide 8 ( > https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider > ) I would give it a try as I know that the documentation is poorly written. > I suggested 10 years ago a change in the API doc about the enabled > protocols, and they didn't change anything although they said they would. > > > > "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only. (Will > not send, but will accept SSLv2Hellos)"" > > I believe they mean "by default" as for the client side. Poorly written, > probably. > > > > 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris : > > > "How do you force Java 8 to use SSLv2Hello?" > > > > You can do this when writing your own Java client : calling the > > SSLSocketFactory to create an SSLSocket and configure with > > setEnabledProtocols ( > > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html > > #setEnabledProtocols-java.lang.String:A- > > ) > > > > If you have some IIS server on internet which reproduces the problem, > > I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client. > > > > > > > > > > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris : > > > >> George, > >> > >> do you have any network capture that we can see ? > >> > >> 2015-10-13 22:10 GMT+02:00 George Stanchev : > >> > >>> >> It might be doable with OpenSSL s_client or something. Tough to > >>> replicate Java's behavior with a non-Java tool, though. > >>> > >>> I tried hard with the s_client but it can limit the protocols to one > >>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) > >>> like Java > >>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which > >>> is also on top of openssl. > >>> > >>> Today, I spent 2.5 hours with a lemming from MS getting basically > >>> nowhere. I really need an engineer, but they give me those clueless > >>> support people that is wasting mine and their time. If someone knows > >>> how to escalate or a forum where MS developers hang out, I would > appreciate it. > >>> The support person I got today was clueless, went over a script and > >>> any attempt to explain a little more technical details led to total > >>> confusion and rebooting the script to beginning. Totally > >>> frustrating. At least with Oracle I got to talk with an actual > engineer... > >>> > >>> George > >>> > >>> > >>> -Original Message
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
"Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to
my understanding does the same as the system property
"jdk.tls.client.protocols". It gives the JSSE a pool of protocols to choose
from but it will be up to JSSE to select the ClientHello version. I might
have missed something but I spent quite a bit of time in the Handshaker and
related classes in the JDK and couldn't see anything that can change
that..."
Sorry, but I believe that no. To understand, you need to look to the old
Ref Guide (
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) which in "Annex A" says that you context.getInstance() takes one argument
called "protocol" while sslsocket.setEnabledProtocols() takes a list of
protocols including the SSLv2Hello.
If you are about to write a TLS client using a SSLv2Hello, you will call
getInstance("TLS") and setEnabledProtocols("SSLv2").
I hope things are more understandable :)
2015-10-13 23:12 GMT+02:00 George Stanchev :
> Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to
> my understanding does the same as the system property
> "jdk.tls.client.protocols". It gives the JSSE a pool of protocols to choose
> from but it will be up to JSSE to select the ClientHello version. I might
> have missed something but I spent quite a bit of time in the Handshaker and
> related classes in the JDK and couldn't see anything that can change that...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 2:55 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> description = bad_record_mac
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the
> SSLSocketFactory to create an SSLSocket and configure with
> setEnabledProtocols (
>
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, I'll
> try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
>
> > George,
> >
> > do you have any network capture that we can see ?
> >
> > 2015-10-13 22:10 GMT+02:00 George Stanchev :
> >
> >> >> It might be doable with OpenSSL s_client or something. Tough to
> >> replicate Java's behavior with a non-Java tool, though.
> >>
> >> I tried hard with the s_client but it can limit the protocols to one
> >> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0)
> >> like Java
> >> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which
> >> is also on top of openssl.
> >>
> >> Today, I spent 2.5 hours with a lemming from MS getting basically
> >> nowhere. I really need an engineer, but they give me those clueless
> >> support people that is wasting mine and their time. If someone knows
> >> how to escalate or a forum where MS developers hang out, I would
> appreciate it.
> >> The support person I got today was clueless, went over a script and
> >> any attempt to explain a little more technical details led to total
> >> confusion and rebooting the script to beginning. Totally frustrating.
> >> At least with Oracle I got to talk with an actual engineer...
> >>
> >> George
> >>
> >>
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Tuesday, October 13, 2015 2:03 PM
> >> To: Tomcat Users List
> >> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> >> description = bad_record_mac
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> George,
> >>
> >> On 10/13/15 12:35 PM, George Stanchev wrote:
> >> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
> >> > (Will not send, but will accept SSLv2Hellos)"
> >>
> >> Interesting. This absolutely makes sense, though, since SSL should
> >> just die. :)
> >>
> >> > I've opened support case both MS and already there is a bug filed
> >> > with Oracle on this and really, to be absolutely certain if the
> >> > issue is in Java or SChannel, one would have to write a non-Java
> >> > client that that mimics the
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
Maybe writing too fast.. "How do you force Java 8 to use SSLv2Hello?" As suggested before, by writing your own client OR by trying this hack. >From the JSSE Ref Guide 5, we know how to the customize the protocol ( https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization ) by setting a system property (https.protocol). Although they are no more talking about this in the Ref Guide 8 ( https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider ) I would give it a try as I know that the documentation is poorly written. I suggested 10 years ago a change in the API doc about the enabled protocols, and they didn't change anything although they said they would. "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only. (Will not send, but will accept SSLv2Hellos)"" I believe they mean "by default" as for the client side. Poorly written, probably. 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris : > "How do you force Java 8 to use SSLv2Hello?" > > You can do this when writing your own Java client : calling the > SSLSocketFactory to create an SSLSocket and configure with > setEnabledProtocols ( > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A- > ) > > If you have some IIS server on internet which reproduces the problem, I'll > try with JTouch ( jtouch.sourceforge.net ) or write a small client. > > > > > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris : > >> George, >> >> do you have any network capture that we can see ? >> >> 2015-10-13 22:10 GMT+02:00 George Stanchev : >> >>> >> It might be doable with OpenSSL s_client or something. Tough to >>> replicate Java's behavior with a non-Java tool, though. >>> >>> I tried hard with the s_client but it can limit the protocols to one or >>> another but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java >>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which is >>> also on top of openssl. >>> >>> Today, I spent 2.5 hours with a lemming from MS getting basically >>> nowhere. I really need an engineer, but they give me those clueless support >>> people that is wasting mine and their time. If someone knows how to >>> escalate or a forum where MS developers hang out, I would appreciate it. >>> The support person I got today was clueless, went over a script and any >>> attempt to explain a little more technical details led to total confusion >>> and rebooting the script to beginning. Totally frustrating. At least with >>> Oracle I got to talk with an actual engineer... >>> >>> George >>> >>> >>> -Original Message- >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >>> Sent: Tuesday, October 13, 2015 2:03 PM >>> To: Tomcat Users List >>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, >>> description = bad_record_mac >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> George, >>> >>> On 10/13/15 12:35 PM, George Stanchev wrote: >>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. >>> > (Will not send, but will accept SSLv2Hellos)" >>> >>> Interesting. This absolutely makes sense, though, since SSL should just >>> die. :) >>> >>> > I've opened support case both MS and already there is a bug filed with >>> > Oracle on this and really, to be absolutely certain if the issue is in >>> > Java or SChannel, one would have to write a non-Java client that that >>> > mimics the handshake messages send from Java with something like >>> > OpenSSL or NSS or whatever and see if the bug replicates. >>> >>> It might be doable with OpenSSL s_client or something. Tough to >>> replicate Java's behavior with a non-Java tool, though. >>> >>> > Writing a Java/Java server client could still leave some doubts as one >>> > can argue the code reuse could mask the problem - it works but the bug >>> > on the client side is hidden by the server containing similar/same bug >>> > so the MACs check out... >>> > >>> > Unfortunately I don't have the time to invest in this more than I >>> > already had. And if MS support engineers can pass it on to someone >>> > from the windows core team may
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
"How do you force Java 8 to use SSLv2Hello?" You can do this when writing your own Java client : calling the SSLSocketFactory to create an SSLSocket and configure with setEnabledProtocols ( https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A- ) If you have some IIS server on internet which reproduces the problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client. 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris : > George, > > do you have any network capture that we can see ? > > 2015-10-13 22:10 GMT+02:00 George Stanchev : > >> >> It might be doable with OpenSSL s_client or something. Tough to >> replicate Java's behavior with a non-Java tool, though. >> >> I tried hard with the s_client but it can limit the protocols to one or >> another but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java >> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which is >> also on top of openssl. >> >> Today, I spent 2.5 hours with a lemming from MS getting basically >> nowhere. I really need an engineer, but they give me those clueless support >> people that is wasting mine and their time. If someone knows how to >> escalate or a forum where MS developers hang out, I would appreciate it. >> The support person I got today was clueless, went over a script and any >> attempt to explain a little more technical details led to total confusion >> and rebooting the script to beginning. Totally frustrating. At least with >> Oracle I got to talk with an actual engineer... >> >> George >> >> >> -Original Message- >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Sent: Tuesday, October 13, 2015 2:03 PM >> To: Tomcat Users List >> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, >> description = bad_record_mac >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> George, >> >> On 10/13/15 12:35 PM, George Stanchev wrote: >> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. >> > (Will not send, but will accept SSLv2Hellos)" >> >> Interesting. This absolutely makes sense, though, since SSL should just >> die. :) >> >> > I've opened support case both MS and already there is a bug filed with >> > Oracle on this and really, to be absolutely certain if the issue is in >> > Java or SChannel, one would have to write a non-Java client that that >> > mimics the handshake messages send from Java with something like >> > OpenSSL or NSS or whatever and see if the bug replicates. >> >> It might be doable with OpenSSL s_client or something. Tough to replicate >> Java's behavior with a non-Java tool, though. >> >> > Writing a Java/Java server client could still leave some doubts as one >> > can argue the code reuse could mask the problem - it works but the bug >> > on the client side is hidden by the server containing similar/same bug >> > so the MACs check out... >> > >> > Unfortunately I don't have the time to invest in this more than I >> > already had. And if MS support engineers can pass it on to someone >> > from the windows core team may be we can have some movement forward. >> >> Okay. Thanks for your work so far. >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0 >> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5 >> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ >> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1 >> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ >> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT >> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ >> PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE >> P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML >> Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3 >> O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF >> WGDHUsSBZIYTFq5mc7VO >> =eyUN >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac
George, do you have any network capture that we can see ? 2015-10-13 22:10 GMT+02:00 George Stanchev : > >> It might be doable with OpenSSL s_client or something. Tough to > replicate Java's behavior with a non-Java tool, though. > > I tried hard with the s_client but it can limit the protocols to one or > another but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java > 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which is > also on top of openssl. > > Today, I spent 2.5 hours with a lemming from MS getting basically nowhere. > I really need an engineer, but they give me those clueless support people > that is wasting mine and their time. If someone knows how to escalate or a > forum where MS developers hang out, I would appreciate it. The support > person I got today was clueless, went over a script and any attempt to > explain a little more technical details led to total confusion and > rebooting the script to beginning. Totally frustrating. At least with > Oracle I got to talk with an actual engineer... > > George > > > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Tuesday, October 13, 2015 2:03 PM > To: Tomcat Users List > Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, > description = bad_record_mac > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > George, > > On 10/13/15 12:35 PM, George Stanchev wrote: > > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. > > (Will not send, but will accept SSLv2Hellos)" > > Interesting. This absolutely makes sense, though, since SSL should just > die. :) > > > I've opened support case both MS and already there is a bug filed with > > Oracle on this and really, to be absolutely certain if the issue is in > > Java or SChannel, one would have to write a non-Java client that that > > mimics the handshake messages send from Java with something like > > OpenSSL or NSS or whatever and see if the bug replicates. > > It might be doable with OpenSSL s_client or something. Tough to replicate > Java's behavior with a non-Java tool, though. > > > Writing a Java/Java server client could still leave some doubts as one > > can argue the code reuse could mask the problem - it works but the bug > > on the client side is hidden by the server containing similar/same bug > > so the MACs check out... > > > > Unfortunately I don't have the time to invest in this more than I > > already had. And if MS support engineers can pass it on to someone > > from the windows core team may be we can have some movement forward. > > Okay. Thanks for your work so far. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0 > 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5 > t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ > XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1 > E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ > +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT > EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ > PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE > P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML > Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3 > O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF > WGDHUsSBZIYTFq5mc7VO > =eyUN > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: AW: Problems to configure tomcat as windows service
OK good that it's finally working. There is a weakness in the documentation since it duplicates a big part of the original procrun doc, and it would more readable to just give a short explanation and give a link as you suggest. You can ask for an improvement in the bug database ( http://tomcat.apache.org/bugreport.html) but I'm not sure they will spend time on it as there is no "real" mistake in the doc. regards 2015-10-09 9:15 GMT+02:00 Arno Schäfer : > Aurélien, > > > still investigating for you in the documentation ( > http://commons.apache.org/proper/commons-daemon/procrun.html ), can you > try again with --ServiceUser & --ServicePassword instead of --User & > --Password ? > > thanks for that hint. I try it and it works now. :-) > I miss the point, that my start mode 'jvm' was excluded, but no > alternative is described in the tomcat documentation. > Perhaps it will be a good idea to integrate a link to the original procrun > documentation, when it is more up to date and complete. I didn't recognize > til today, that this is a separate project. > > Thanks for your patience, > best regards > Arno > >
Re: AW: Problems to configure tomcat as windows service
Arno, still investigating for you in the documentation ( http://commons.apache.org/proper/commons-daemon/procrun.html ), can you try again with --ServiceUser & --ServicePassword instead of --User & --Password ? regards 2015-10-08 17:35 GMT+02:00 Arno Schäfer : > Hi Aurélien, > > > Arno, can you try with these parameters : --StdOutput out.txt --StdError > err.txt > > and check if this writes anything to these files (I don't bet a pence on > this but let's try) ? > > That isn't the point. My problem is, that I can't configure a different > service user as the local system account with this utility. 'tomcat7.exe' > configure all other parameter as you can see afterwards in the > 'serverconsole' utility except the '--User' and '--Password' on Windows 8.1 > 64 bit with no error message. It only ignores these both values. > The service is running in all cases under the local system account and I > can manualy change to an other user and it still works. > So, do you know, what is the normal process to report a bug to the > development? > > I have to revert my statement from the mail before: It didn't work also > with tomcat6 on Windows 8.1 64 Bit > > > Taken from the doc : > > http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html > > I know this document very well ;-) > > regards > Arno > >
Re: AW: Problems to configure tomcat as windows service
Arno, can you try with these parameters : --StdOutput out.txt --StdError err.txt and check if this writes anything to these files (I don't bet a pence on this but let's try) ? Taken from the doc : http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html 2015-10-02 17:52 GMT+02:00 Arno Schäfer : > André, > > > Maybe it is not only the version of Tomcat that has changed, but also > the machine/OS on which > > you do this ? Maybe the user under which you execute this command does > not have the > > required > > privileges, at OS level on this machine, to do this ? > > On the same machine/OS it work's with tomcat 6. > > > > Maybe the user-id *to* which you are trying to set the Tomcat service, > does not have enough > > privileges to "run as a Service" ? > > (In the services.msc applet, it would ask you interactively to grant > these privileges first, but > > maybe the command-line tool cannot do that). > > Like I said in my first mail, I install it as an local administrator and > the service was registered and I am able to run it under the local system > account. > And also if I fill in the user data manually, what I used in the > tomcat7.exe call, I am able to start and run the tomcat server, so missing > privileges shouldn't be the problem. > > Regards > Arno > >
Re: Monitoring Connections
Hi Jamie, when this happens you can do a thread-dump (kill -3 pid on Linux platforms) and you would see if there is a lock on JDBC objects, or anything else synchronized (from the Collections like Hashtable). Not easy for beginners to understand a dump, but worth learning. Very often an application will slow down because Garbage Collection, and the GC thread will be the only one working at that time. Please use the verbose settings to have all your Tomcats log GC activity. This is useful for both live and after time analysis. You won't monitor mod_proxy, this has no sense. If you suspect a network flood, do a 'netstat -an' to see how many connections are used by your Apache (both ESTABLISHED and TIME_WAIT). However, you might need to set timeout and flushpacket on your proxypass directive when your application has such requirements (see HTTPD doc for this settings). To know if you're flooded, you can do a 'ps -eaf | grep [h]ttp' and you would see many httpd process, it is similar to the netstat result more or less. If you enjoy live monitoring, you need to have a look on Christopher's presentation ( http://events.linuxfoundation.org/sites/events/files/slides/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf ) who posts many answers to this mailing list. regards 2015-10-07 22:20 GMT+02:00 Jamie Jackson : > Hi Folks, > > I had a server crash on Friday, and I had the following symptoms: > > Response time worsened, and when I looked at my real-time monitoring (an > app called FusionReactor), I saw that the app *seemed* to be > single-threading (I only saw one request process at a time), then after a > few minutes, even though resources still looked good, the app no longer > seemed to receive any requests. > > My first guess was that somehow, connections were slowly getting clogged > until there were none left, then my server was completely unresponsive. > > I front Tomcat (7.0.59) with Apache HTTPD, and connect with mod_proxy. (The > end app is built in Lucee, and is running on RHEL 6.7 and Oracle Java > 1.7.0_76.) > > My instinct is to monitor the connection (pools?) in, I guess, Tomcat and > mod_proxy, but: > > >1. I don't know if that's sane. >2. I have no clue how one would go about that. > > I could use some input. > > Thanks, > Jamie >
Re: Problems to configure tomcat as windows service
Arno, there *maybe is* documentation about this, see question & comments from Konstantin Kolinko in http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html 2015-10-02 16:36 GMT+02:00 Arno Schäfer : > Hi all, > > using tomcat 7.0.54 on Windows 8.1 64 Bit system, I encounter the problem, > that I can not configure a user/password > with the tomcat7.exe utility. I run this as a local administrator in a DOS > box with a valid user and password it returned > with errorlevel 0, but the user was not set in the service settings. > > What can be the reason for this? The same solution run before in a tomcat > 6 environment with no problems and I > recognize no changes in the documentation in this area. > > best regard > Arno > > _ > > > > Vorsitzender des Aufsichtsrats: David Bellin > Vorstand: Diederik Vos (CEO) ? Ralph Gillessen (COO) ? René Gawron (CFO) > SQS AG ? Stollwerckstraße 11 ? 51149 Köln > Sitz der Gesellschaft: Köln ? Amtsgericht Köln, HRB 12764 > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient > (or have received this e-mail in error) please notify the sender > immediately and destroy this e-mail. > Any unauthorised copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. >
Re: Parallel deployment URL issue
Hello
maybe the Java documentation is badly written, because it is saying (
http://docs.oracle.com/javase/7/docs/api/java/io/File.html#toURL%28%29
) : "This method does not automatically escape characters that are
illegal in URLs."
# character is not illegal, but reserved (see gen-delims definition in
RFC 3986). It means the character is quite legal, and really, it is
widely used for anchoring.
As a quick-and-dirty, did you try renaming your file yourWar##12345 to
yourWar%23%2312345 ?
regards
A.T.
2015-10-01 17:51 GMT+02:00 Chris Gamache :
> Hi all,
>
> I'm stuck using axis2-1.5.4.
>
> Here's what I think is happening:
>
> Axis2 does this sort of container-in-a-container thing. It creates its own
> classloader and pulls in all of its jar libraries dynamically. The problem
> is that it uses a java.net.URL to target the files. This would be fine
> except for the problem that the folder name, when using parallel
> deployment, is
>
> /path/to/yourWar##12345
>
> So (from org.apache.axis2.deployment.util.Utils)
>
> public static URL[] getURLsForAllJars(URL url, File tmpDir) {
> FileInputStream fin = null;
> InputStream in = null;
> ZipInputStream zin = null;
> try {
> ArrayList array = new ArrayList();
> in = url.openStream();
>
> The problem is that URL was constructed from a File object in the
> org.apache.axis2.deployment.repository.util.DeploymentFileData.setClassLoader(boolean,
> ClassLoader, File) method using the toURL() method. The toURL() method is
> deprecated because it doesn't escape special characters, namely the "##" in
> the path.
>
> When it hits url.openStream() it is discarding everything after the ##n
> part of the path (think hash value in a web URL). It throws a
> "java.io.FileNotFoundException: /path/to/yourWar (No such file or
> directory)"
>
> Getting in there and patching axis2-1.5.4 is less-than-desirable. So many
> things to go wrong.
>
> Is there a way to alter the way tomcat unpacks the warfile? Is there a way
> to configure the version delimiters from ## to perhaps ~~ or $$ ?
>
> CG
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 reliability/performance on Windows 2008 R2 Server vs. RHEL/CentOS
Howard, I didn't say this was not running well on Windows, but that it seems easier (less work) on Linux for the same result. If you're expecting "secured" Tomcats, you'll run your windows service with a service account. This means that you will have to set up properly the rights for this account to TOMCAT_BASE, TOMCAT_HOME, and even (if I remember well) giving write access to the conf folder (EVIL !) because the context deploying creates a temporary file and then needs write access. You need to break rights inheritance, and if you're unsure of your XCACLS script, you're going to break your server security. Setting up these rights take less than 5 minutes on Linux, and I would like know how much time for writing a correct XCACLS script. Every time you will right-clic to check the rights, you will be warned that inheritance was broken and you will have more doubt every day about what was done. Most of Tomcat admins need to search GOOGLE to know how to make a thread-dump. On Linux, kill -3 pid, it takes 5 seconds to learn :) When dealing with uploaded files (particularly Office), I would take no risk to get my server infected by a virus. A Linux running an antivirus sounds better to me. What you're saying sounds good, but I have been deploying Tomcat since version 3 and it has brought me to Linux choice. best regards, A.T. 2015-10-01 19:22 GMT+02:00 Howard W. Smith, Jr. : > On Thu, Oct 1, 2015 at 11:46 AM, Aurélien Terrestris > wrote: > >> I recommend Linux for 2 reasons : >> - easier to install and maintain a secured Tomcat (especially when >> using different TOMCAT_HOME & TOMCAT_BASE, on Windows it's pretty >> difficult to know how to secure all directories correctly) ; if you >> have to deal with file uploading, you don't want a system which could >> launch any exe,.. >> - doesn't need to reboot every 3 days because of the memory >> fragmentation or anything else >> > > Multiple tomcat/tomee instances are running well on Windows 2008 R2 Server > for me. > > - does 'not' reboot every 3 days at all > - only reboots automatically at 3am when there is a Windows update for the > Windows 2008 R2 Server > - my apps shut down with no issues and restart (via Windows Service for > each tomcat/tomee instance) with no issues > - the embedded Apache Derby database is/has never corrupted due to loss of > power or restart (for Windows update) > - never had to set or maintain TOMCAT_HOME and/or TOMCAT_BASE environment > variables > - i only set/maintain JAVA_HOME and JRE_HOME environment variables > (whenever there is a Java version update) > - my 2 apps (and/or tomee instances) run under 500MB and 1GB of RAM, > respectively, and CPU seem to max out between 4 to 10% (on average) > - Java EE 6 full blown stack (JPA, JSF, JMS) running on main tomee instance > using under 1 GB of RAM > - Java EE 6 RESTful + JMS running on 2nd tomee instance using under 500MB > of RAM > - use tomcat7w.exe and tomee4restw.exe to start, stop, edit the Windows > Services for the tomcat/tomee instances > - Windows = piece of cake (for me) > - as Andre' mentioned, use Remote Desktop connection to connect to the > Windows 2008 R2 Server > - i remove default tomcat/tomee web app (ROOT folder, etc...) and deploy my > WAR to webapps folder > - i'm loving tomcat/tomee on Windows Server > - have 32 GB of RAM available, only using (approximately) 4GB because of my > java heap settings for both tomcat/tomee settings - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Conditional logging
Hello, I was just trying to answer to this question asked last year, since some of my customers are also asking the same now and then. I admit that sometimes there are really many health-check logs (1 or 2 monitoring tools + load-balancers checks,..). But, considering my customers ideas, they're wrong and you're right, because logs give an additional information about the monitoring tools if we're unsure of the health-check itself, or about a temporary network hanging. About the log format, I've been replacing almost everywhere the default Valve config by one which logs the processing time, and it is very useful for later debugging. Not that I don't like the live JMX or JMETER scripts, but the more tools we have, the more likely we are to explain what's happening or what happened at 5AM during the asian market opening hours while we're sleeping deep. A.T. 2015-10-01 20:47 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 10/1/15 10:40 AM, Aurélien Terrestris wrote: >> A late reply to this topic... Without the conditional test provided >> by the Rewrite (native Tomcat 8 Rewrite or url-rewrite), it is >> possible to use an Apache in front of the Tomcat which will have >> two ProxyPass, and two virtual hosts on the Tomcat itself (one >> servicing anything but the healtheck, the other one for the >> healthcheck without logging valve). As the wildcard is not >> supported by ProxyPass, we can use ProxyPassMatch for this >> purpose. > > That seems reasonable. Are you just trying to avoid filling your logs > with health-check requests? I would personally rather have those > requests showing in the log; they can be filtered-out later before > logfile analysis if you want to ignore them then. > > But Tomcat *is* handling the requests, so I'd want them logged. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJWDX+9AAoJEBzwKT+lPKRYe20QAI3sXL57X7tFoB9P+OKAgwEv > tmj7/f89oZwY+K85eqntQWIQgxHAFOh4NjASjOBmeeXaB39+KoBLjegRlaOPssmi > ynukIUhSnUHfgOBQj9o4MgHjYRLoE5aeZ7obkZDoEj3uQ9hdCruNNMW4X+i2Fu24 > 8GawKVlUUrgQK3U25RRtBhGFcGY6oXpgvRoiii6KKha+NPs//RPH82weG+nK4uHA > lh9OQ3oV0AVwsyPGoewvHYX/LOoqTMMBu2t/Wpo43NEAr9giWt38vz9d62/1PvfV > 3jDau8U1N0GS37SOj3cdLT0RcAieofNIJcwUaiZ0lsZckfPhZ3k/vW7zf0lm/oRI > o8wzWcaXelJjMoaEbdfPZLHoKxP0cNi7S6dZv/fVe8foflsHfwc20Wo7cYBVaVuO > a/NpwI5etQvRRHIyfLhveERi0bMV+S3g7Bfmo6PGYH3hLRQtr+s+zqbCgT9PT0oN > NNvsI6wV92gH8FDvRQlFSFbA80uiWsUed6GtuX3TInOxrEf9JzpBESgPuaam6xu7 > 9Q5miy2ZFyOaaMmfYuXveeCzlnXZviCMisbLrZJ43oDKhC4FftmVPZhuFBDzNWZF > Q3MeOHYgrCdyh/Ro5l/w930nuOIRQlWoVWGWqvLLyfgKPx/JXGccGV6MK6PmCl1h > ddQCXfD0A8Q8je9o/de0 > =0nOi > -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: Tomcat 8 reliability/performance on Windows 2008 R2 Server vs. RHEL/CentOS
I recommend Linux for 2 reasons : - easier to install and maintain a secured Tomcat (especially when using different TOMCAT_HOME & TOMCAT_BASE, on Windows it's pretty difficult to know how to secure all directories correctly) ; if you have to deal with file uploading, you don't want a system which could launch any exe,.. - doesn't need to reboot every 3 days because of the memory fragmentation or anything else 2015-10-01 17:31 GMT+02:00 Mark H. Wood : > On Wed, Sep 30, 2015 at 01:23:14PM -0700, Jason Britton wrote: >> Hello Good People - >> We currently have multiple Tomcat instances deployed on RHEL in production >> with no issues but I am getting asked why we shouldn't migrate everything >> to run on Windows 2008 R2 Server instead. My stomach churns at the thought >> but I am looking for more concrete information about why this could be >> problematic vs. running Tomcat on RHEL/CentOS. My gut says far more Tomcat >> deployments in production are done on top of Linux based OS's vs. Windows. >> Any thoughts on making an argument for one OS vs another in deploying >> Tomcat 8? Thanks for your thoughts, > > I think it's going to boil down to: how well do the people who will > operate and maintain Tomcat get along with each environment? I go > with Linux because throughout a long association with Windows I found > it frequently getting in my way, embodying invalid assumptions, and > generally resistant to being used in the way I want to operate a host. > Others will have the opposite experience. So, which kind do you have? > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Conditional logging
A late reply to this topic...
Without the conditional test provided by the Rewrite (native Tomcat 8
Rewrite or url-rewrite), it is possible to use an Apache in front of
the Tomcat which will have two ProxyPass, and two virtual hosts on the
Tomcat itself (one servicing anything but the healtheck, the other one
for the healthcheck without logging valve). As the wildcard is not
supported by ProxyPass, we can use ProxyPassMatch for this purpose.
Apache :
ProxyPassMatch ^/(.*)/iaahb http://localhost:8081/$1/iaahb
ProxyPassMatch ^/.*$ http://localhost:8080/
Tomcat server.xml :
Chris,
Quick question, I upgraded to 7.0.54 with new user/pass. My issue is
that these credentials
will not log me in to ANY management function going through the GUI???
If I append the WEBAPP
Tho the url http://localhost\web app name this launches the app - but
still I need to access
all CmcApps via the GUI. Any ideas?
Thanks,
Keith Pendergrass (CIV) MS/ MBA/ Network+
IT Specialist (APPSW) Software/Data Engineer
Space & Naval Warfare Systems Command-Atlantic
2251 Lakeshore Drive
New Orleans, La 70122
Work: (504) 697-5549
DSN: 647-5549
Fax: (504) 697-5628
keith.pendergr...@navy.mil
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, July 22, 2014 9:09 AM
To: Tomcat Users List
Subject: Re: Conditional logging
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kris,
On 7/21/14, 6:43 PM, Dames, Kristopher J wrote:
> Can anyone point me to an example of conditional logging in Tomcat 6?
> Here is what I have tried to no avail. I want requests that match
> /*/iaahb to not be logged.
>
> In my server.xml:
>
> condition="DoNotLog" directory="logs" fileDateFormat="-MM-dd"
> pattern="%{X-Forwarded-For}i %h %l %u %t "%r" %s %b
> "%{Referer}i" "%{User-Agent}i""
>
> prefix="access_log"/>
>
> in my web.xml:
>
>
> Set Do Not Log Attribute
> SetDoNotLogFilter
> DoNotLog true
>Set Do
Not Log
> Attribute /*/iaahb
>
On the face of it, this looks like it should work. What does your
"SetDoNoLogFilter" code
look like?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTznCUAAoJEBzwKT+lPKRYlKQQAKFrkhuDlohUc71mm0iBQXRl
jOcU4LD1Coq2m+dtQscGdgbwJ7vvr3wCGLFjJ+k6SPGkDDon1N0xQ/RsXApFFvme
KqR3B851de9TtZlAiCgRJsWnvoXNMsSp8aeQxcwV1hSj/s9agDd8hHQj9ffw+Hnu
E9wcw4uFlM0+cDvqc6lMlP2P1lgj9F0UWmzcQFw1p3iUxUiiOsXXXBls5KlLtT7D
Si/69y/Ul0FOy9kvNl/W1EPVZcKEE6c3r4/UAYaLoZmxtKFIa6FkKVJGW3oK16PH
F2mTPnYLwNN3fSEwaJEMlmAUg58UfSkTdMtIaARbMD0SC34zeHqipVOMJ5mwtSuJ
XYAgD1euYzGmwewQL1Xi/pqdWngplFuJNnBeMgxUaQdw3p6WwWgdl2CN/FPfYkjo
R/VW01flR+UlkavQjcKi/uv9fDy0Y2Hn+q1wFtOVqwxcDIa8bdKm00KllYNRClhz
Ddu+xMg55LkZi/qeMUan8YNidNH1RiXa74A5i4BR7VLf5jtO+j0FHxx9H1WDbkNp
O887mfSrU75zgr1ACg8yoPpw5lVfqBYfhkfa2Clf6eNQWgBs3Ki6KZzH/f1dEM4S
YVo7T+1yESMvLTb2fK5J5wJv/WIuZWUfNY6n7r9vOjxj61lo7q6UjutYeNO746N1
hSIMjlfwoc0IeqGMB0M3
=k8cT
-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: Tomcat deployment from public_html user folder of a war application is not working
As said by Konstantin, the listener doesn't do what you are trying to achieve (I tested on my side, it doesn't work). You can do virtual hosting, but this means that you need either one different host name or port for each user. I think it is easier to deal with ports, and then you can hide them by using an Apache in front of the Tomcat, with some RewriteRules to proxify to the good user (guessing the port by the uid, you can automatically build your httpd.conf) A.T. 2015-09-24 18:28 GMT+02:00 Manuel Parra : > Do you recommend one HOST for each user with especifically appBase ? > > Thanks. > > On Thu, Sep 24, 2015 at 6:18 PM, Manuel Parra wrote: > >> Well Im using localhost and myserver.com as a server from I connect (URL). >> May be this a problem with HOST in server.xml? >> >> Regards. >> >> On Thu, Sep 24, 2015 at 6:02 PM, Manuel Parra wrote: >> >>> Yes. >>> This is my Configuration for the hosts in server.xml: >>> >>> >> "true"> >>> >>> ... >>> >>> >> directoryName="public_html" userClass= >>> "org.apache.catalina.startup.PasswdUserDatabase" /> >>> >>> >>> >>> Then at user's homes I have: >>> >>> /home/usertest/public_html/app.war >>> >>> But in http://localhost:8080/~usertest/ --> >>> HTTP Status 404 - /~usertest/ >>> >>> Thanks in advance. >>> >>> >>> >>> >>> On Thu, Sep 24, 2015 at 3:41 PM, Aurélien Terrestris < >>> aterrest...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> first, you should check that the Host is configured with >>>> autoDeploy="true" >>>> >>>> 2015-09-24 14:07 GMT+02:00 Manuel Parra : >>>> > Hello I'm trying to deploy .war application from the public_html >>>> folder at >>>> > user homes. >>>> > >>>> > I've added directive to server.xml : >>>> > >>>> > >>> > directoryName="public_html" >>>> > userClass="org.apache.catalina.startup.PasswdUserDatabase"/> >>>> > >>>> > And I try : >>>> > >>>> > http://localhost:8080/~usertest/app >>>> > >>>> > And it return : >>>> > >>>> > 404 error >>>> > >>>> > Then I try : >>>> > >>>> > http://localhost:8080/~usertest/app.war >>>> > >>>> > It download app.war but it doesn't serve the app. >>>> > >>>> > User home contains folder : >>>> > >>>> > public_html/app.war >>>> > >>>> > So, what is the problem? >>>> > >>>> > I'm using tomcat 7 >>>> > >>>> > Thanks in advance. >>>> >>>> - >>>> 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: Tomcat deployment from public_html user folder of a war application is not working
Hi, first, you should check that the Host is configured with autoDeploy="true" 2015-09-24 14:07 GMT+02:00 Manuel Parra : > Hello I'm trying to deploy .war application from the public_html folder at > user homes. > > I've added directive to server.xml : > > directoryName="public_html" > userClass="org.apache.catalina.startup.PasswdUserDatabase"/> > > And I try : > > http://localhost:8080/~usertest/app > > And it return : > > 404 error > > Then I try : > > http://localhost:8080/~usertest/app.war > > It download app.war but it doesn't serve the app. > > User home contains folder : > > public_html/app.war > > So, what is the problem? > > I'm using tomcat 7 > > Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
Thanks Christopher, I believe this was working by the time of Tomcat 4.. but not completely sure, it was a long time ago :) 2015-03-30 16:14 GMT+02:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 3/30/15 4:24 AM, Aurélien Terrestris wrote: >>> If you write a Valve (which would be Tomcat-specific, and not >>> work under other servlet containers), you could change the way >>> Tomcat reads session identifiers from the request (and use a >>> request parameter instead of a path parameter). >> >> Maybe could you also have a look on Filters since they're made for >> modifying the request before it reaches the servlet (or modifying >> the response after it leaves the servlet) : >> >> http://www.oracle.com/technetwork/java/filters-137243.html > > This won't work well with Tomcat's authorization checks, since they > occur before the filter chain in invoked. > > - -chris > >> 2015-03-30 9:57 GMT+02:00 Wesley Acheson >> : >>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> >> Wesley, >> >> On 3/29/15 1:15 PM, Wesley Acheson wrote: >>>>>> A team I am working with use tomcat 7 as their web >>>>>> container. The application cannot use url session tracking >>>>>> due to compliance reasons. >>>>>> >>>>>> One of the requirements we are facing is that the >>>>>> application should work in an iframe on the safari web >>>>>> browser, which blocks all cookies. >> >> Do you mean that Safari has been configured to block all cookies? >> Because Safari won't block cookies just because you are using an >> >>>>> . >> >>>> >>>> Should have said its a third party domain name. That can't >>>> change easily. Should have wrote Safari blocks all third party >>>> cookies. >>>> >>>> >> >>>> >> For this purpose I'd like to post some value around that acts as a >>>>>> session Id. However I'm not sure if this is possible? >> >> If you write a Valve (which would be Tomcat-specific, and not work >> under other servlet containers), you could change the way Tomcat >> reads session identifiers from the request (and use a request >> parameter instead of a path parameter). >> >>>> >>>> I understand that the solution at the moment would be container >>>> specific. >>>> >>>> >> >> Or you could handle session-management yourself and not use >> servlet-spec-style session-tracking (which would be WAY more >> invasive to your application). >> >>>> >>>> In the longer term this is probably better. For the immediate >>>> term I just need the lease invasive approach for the >>>> application. >>>> >>>> >> >>>>>> *I'm aware that this won't work for common paradigms such >>>>>> as POST-REDIRECT-GET.* >>>>>> >>>>>> Looking at CoyoteAdaptor.java seems to suggest that session >>>>>> Id can only be retrieved using SSL COOKIE and URL. >>>>>> >>>>>> COOKIE is out because of third party issues. URL is out >>>>>> because of compliance. SSL may be a possiblity but only if >>>>>> it doesn't involve custom client certificates. >>>>>> >>>>>> Is there any good place to hook in a post parameter for >>>>>> retrieving and reattaching the session? >> >> I've not done this before. CoyoteAdapter calls >> request.setRequestedSessionId in a few places, and I don't believe >> CoyoteAdapter can be overridden or replaced directly. >> >> If you had a Valve that ran before anything else, you might be able >> to capture the request, read a request parameter, and then call >> setRequestedSessionId yourself with that replacement value. >> >>>> >>>> Thanks very much I'm going to read up on valves now. >>>> >> >> YMMV >> >> -chris >>>> >>>> > - - >>>> >>>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.
Re: Post Session Id
> If you write a Valve (which would be Tomcat-specific, and not work > under other servlet containers), you could change the way Tomcat reads > session identifiers from the request (and use a request parameter > instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html 2015-03-30 9:57 GMT+02:00 Wesley Acheson : > On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Wesley, >> >> On 3/29/15 1:15 PM, Wesley Acheson wrote: >> > A team I am working with use tomcat 7 as their web container. The >> > application cannot use url session tracking due to compliance >> > reasons. >> > >> > One of the requirements we are facing is that the application >> > should work in an iframe on the safari web browser, which blocks >> > all cookies. >> >> Do you mean that Safari has been configured to block all cookies? >> Because Safari won't block cookies just because you are using an > >. >> > > Should have said its a third party domain name. That can't change easily. > Should have wrote Safari blocks all third party cookies. > > >> > >> For this purpose I'd like to post some value around that acts as a >> > session Id. However I'm not sure if this is possible? >> >> If you write a Valve (which would be Tomcat-specific, and not work >> under other servlet containers), you could change the way Tomcat reads >> session identifiers from the request (and use a request parameter >> instead of a path parameter). >> > > I understand that the solution at the moment would be container specific. > > >> >> Or you could handle session-management yourself and not use >> servlet-spec-style session-tracking (which would be WAY more invasive >> to your application). >> > > In the longer term this is probably better. For the immediate term I just > need the > lease invasive approach for the application. > > >> >> > *I'm aware that this won't work for common paradigms such as >> > POST-REDIRECT-GET.* >> > >> > Looking at CoyoteAdaptor.java seems to suggest that session Id can >> > only be retrieved using SSL COOKIE and URL. >> > >> > COOKIE is out because of third party issues. URL is out because of >> > compliance. SSL may be a possiblity but only if it doesn't involve >> > custom client certificates. >> > >> > Is there any good place to hook in a post parameter for retrieving >> > and reattaching the session? >> >> I've not done this before. CoyoteAdapter calls >> request.setRequestedSessionId in a few places, and I don't believe >> CoyoteAdapter can be overridden or replaced directly. >> >> If you had a Valve that ran before anything else, you might be able to >> capture the request, read a request parameter, and then call >> setRequestedSessionId yourself with that replacement value. >> > > Thanks very much I'm going to read up on valves now. > >> >> YMMV >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2 >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBCAAGBQJVGJYFAAoJEBzwKT+lPKRYn8oP/0LIWZKl5Nf/bYdN1BeosGFF >> 6hLS/mEDZ+XUD/NMpGpTHjoin3+32m7kGKEGCCApQDc4GAUlIwJGzLeLPsGfFaoo >> QXXyM6XUfpHWmJaEPtAySe0CZ/fwOKvL/DKuuO7UbtjFmNc8Pm/e87p5lmprsaQ1 >> C+4pfXsV5ltdDO8eZU0ofOHAXA0qkDuizeixwEcG3sXnNqF4Hr7Oq4gF0TKwCAU9 >> 6Hce0NYVY61YY64U0m+dCCsH5a9hMUlu48YGDA9JemKmeNLexR3TrxFC8LT8iqUW >> jXNygDD7GBfFBhIiYujUo3HwSCNW091OMy6Vb0DhcSOlL11LVpK2+eNLZ1aM3kHI >> 881Onen2evMjzZ3PcALw2SqN3Cmr8dqMp0YhrJc2jsZ6OXBrYSuSCYCw4A0tDlN7 >> GTusoqFobmipgXu+sksZh5A6h5uyThVTLikG3CQ72wvTDMzRBh1YrNPc027BLuKN >> k/KOoBv3Lkyan+pSEbzQCCchB2IQ/CSFHoD8jgfzcHehJ5qB1Mrwo97kwsh1qbvk >> IjGssbqyDrTmfrKVyl1ypeCi18l7pn9GrTzJwFoNUxmfd+42elwCrRPUdCYYZuR8 >> 9Ne8uYegBwnvRQpDN5RCK73Bqpyi2lgyP10Ph20TvnQ3ACDNbb6247TOTPGnItGr >> G5g/FyojfAtvlnhe7+r4 >> =0axs >> -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: Tomcat 8 on Solaris 10/11
As suggested by Rainer, I would try with the blocking connector and compare. Otherwise, it could be that your file is using very long lines (only 5 lines for more than 800k of data). Maybe a tomcat-dev could have a look on this. $ wc ext-datadownload-20150323_1157.js 5 7634 838044 ext-datadownload-20150323_1157.js 2015-03-26 12:12 GMT+01:00 Rainer Jung : > Am 26.03.2015 um 10:54 schrieb Andrew Seales: > >> Hi, >> >> We are having a problem on our production servers where downloads of >> certain files are getting randomly truncated. This includes static >> Javascript files, file downloads via servlets, etc, where the file is >> more than about 100K. Most of the time the file downloads successfully, >> but some randomly get truncated. The truncation doesn't happen in >> exactly the same place every time. >> >> I've been able to recreate the issue on our development servers using >> Tomcat 8.0.20 with Java 1.8.20 and 1.8.40. I've tried Solaris 10, 11, >> SPARC and x64 CPUs and the same issue occurs. I've tested on a fresh >> install of Tomcat 8 and dropped in one of our larger Javascript files >> into the webapps/ROOT directory and made no other changes. I'm using a >> Perl script to continuously download the file and test an md5 hash >> against a known good value to test if the download breaks. It also seems >> to only occur when the network speed isn't very good. I use the >> following command to limit the speed of my network interface: >> >> sudo tc qdisc add dev eth0 root handle 1:0 netem rate 128kbit >> >> I've also tested the same Tomcat on a Redhat 6 server but that appears >> to work fine. >> >> If I revert to Tomcat 7.0.59, then Solaris works fine. The problem >> appears to only occur with Tomcat 8 on Solaris. I've tried v8.0.14 and >> 8.0.20 and they both have the problem. >> >> The Perl script is available from >> http://dlib-bauer.ucs.ed.ac.uk/testdata.pl >> The Javascript file is available from >> http://dlib-bauer.ucs.ed.ac.uk/ext-datadownload-20150323_1157.js >> >> Is anyone else running Tomcat 8 on Solaris 10 or 11 with Java 8, or know >> of any problems on the platform? > > > Yes, we do, on Solaris 10. I don't know of any such problems, but I can't > introduce the slow network condition here to test. > > Is the file really truncated, i.e. too short, or is it corrupt? Can the > truncation also be seen in the Tomcat access log? If so, could you replace > the curl/md5sum based test with another HTTP client like LWP::Simple in perl > or "ab" coming with Apache httpd. Just to rule out the client side of the > picture. > > Is truncation always happening at the same byte? Any pattern? > > Which connector are you using? NIO? APR? > > I personally would try the following to provide additional analysis data: > Find a setup, where you can log the client port. Use this setup and snoop > network traffic during the test on the client and server side. Once the > problem happens, use the local port number and timestamp to extract the > communication pattern on the server and client side. That way you can see, > which side closed/aborted the connection - or whether it is something in > between client and server. > > Unfortunately logging the client port often is not trivial to achieve. On > the Tomcat side (access log), currently there is only the server port > available, not the remote port, although this would be very simple to add. > On the short hand it would maybe work to switch to perl plus LWP and try to > get the local port from LWP. > > Regards, > > Rainer > > > > > > > - > 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: Slow http denial of service
Christopher, there are several questions in the same thread.. The first one about SlowLoris was answered a long ago ( http://tomcat.10.x6.nabble.com/is-tomcat-6-0-35-vulnerable-to-CVE-2007-6750-td585.html ). On the contrary, for fast connections opening (DOS), we can configure the firewall in order to temporarily ban an IP if it has reached something like 20 connections/second. The problem becomes more difficult if we're facing a DDOS : if the trafic is good old HTTP then we must challenge our clients (catpcha, javascript) then we know who we have to ban (F5 products can do that, or use Cloudflare/AKAMAI). If it's not HTTP (IP spoofing, DNS recursive requests,..) we need to configure the router or the entrance firewall. I believe there is no cheap solution to fight against a 300G/s flood. >What about non-users? Blocked by router/firewall if they were sending something really stupid so I don't have any idea about how many of them. Google bots and others, even not 1% of trafic. We had several crash because of too much trafic when thousands of people were connecting at the same time to get a special news from the company. This doesn't happen anymore after buying servers 20 times more powerfull, but I'm not working there anymore. 2015-03-16 21:09 GMT+01:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 3/16/15 9:16 AM, Aurélien Terrestris wrote: >> As browsers (at least the ones I know) open 2 connections to >> browse websites > > That number has been bigger than 2 for quite a while, now: > > http://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser > > We aren't talking about nice clients, here, though, but clients that > are intentionally trying to bring-down a site. The maximum number of > connections a legit web browser will open to a single host/IP is not > relevant. > >> we could have a look on the hourly stats and estimate this (under >> 100 without problem). I never met such problem anyway, the highest >> traffic being 120 000 different users/day. > > What about non-users? > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVBzhjAAoJEBzwKT+lPKRYyiMQAMoied29A55351fkrU5HHdkR > nILbSHhxH0UGiCAw+Fcp8SNdP7lD5mLiRH8+Mn9Vlp7TkK8AfQIRPWTwj605RRME > c9e0VWFnNmMvDbKL+DhyMHKTK/c7LgVABh9l7v5JbiSUBtnyQNeQDBtep4Q5oxuz > +P6t7PbDWILLntVHdcUxNMJQFiQkI1VRQ3dYPGu2kRxXTOk7OpHSqZkNhq2XCpH5 > /isZlTJtU02l9GqFb3cNFWc2vM94Lp2ATVfUs6vZdYnUQ1oSrUdsWAy76CKdNjII > HY5KUiRmyNtxY2JDHlqbcjA7rmOOTcb+68T1qy4ZSmQmDLaBuBR0ajWHOgJ4Btp8 > bUgk+4yB32Af8IZ3sr4Asa8aMf1LTNx+1x6TVO0en5VD4WwFbGZ5EdZmW/SZdvWY > 0Bu/RNgaydK/Jac5A4RKlEFfP4VJz/r0ST4Cxqq3t1UC0OHS46SFDg0gwXAnEuSt > Qsk71YeuWJG8zolL05pXqSehr836H1s7FjG2rych1mwa53T+Agx8+5Cp/zd3fv59 > zJ2ivJ7Cr2JAm4CInx7ic0cTuqmjOneRJIKb9WYSzHMoGLw+IVyx3v3Ykru/XlM9 > AOfi5zENQ2tVDKCUBgNSdYd/amS6VNliFzbhkw0/cDYvw7HffxNw6Xd43wg388wG > VrSu31Roqi3bRVr15Mwl > =/YWE > -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: Slow http denial of service
As browsers (at least the ones I know) open 2 connections to browse websites, we could have a look on the hourly stats and estimate this (under 100 without problem). I never met such problem anyway, the highest trafic being 120 000 different users/day. If you really have to face DDOS as said by Christopher, you would have to use something like cloudflare. For very big sites, AKAMAI,.. 2015-03-16 13:50 GMT+01:00 David kerber : > On 3/16/2015 8:41 AM, Robert Klemme wrote: >> >> On Sun, Mar 15, 2015 at 10:07 AM, Aurélien Terrestris >> >> >>> wrote: >> >> >>> I agree with the NIO connector which gives good results to this >>> problem. Also, on Linux you can configure iptables firewall to limit >>> the number of connections from one IP ( >>> >>> >>> http://unix.stackexchange.com/questions/139285/limit-max-connections-per-ip-address-and-new-connections-per-second-with-iptable >>> ) >>> >> >> What I find difficult about this approach is that because of NAT the >> number >> of individual machines (and hence connections that are reasonable) behind >> a >> single IP can vary vastly. What value will you pick to not discriminate >> large organizations? > > > That is a reasonable question, but the owner of a web site should have some > idea of who their clients are, and have a feel for a reasonable number to > allow. Obviously a site with a large clientele will be able to handle a > larger number of connections, whether they're legit or not. > > > > > > - > 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: Slow http denial of service
I agree with the NIO connector which gives good results to this problem. Also, on Linux you can configure iptables firewall to limit the number of connections from one IP ( http://unix.stackexchange.com/questions/139285/limit-max-connections-per-ip-address-and-new-connections-per-second-with-iptable ) I would not rely on Apache for this, since Apache has also its own similar problems on some versions (with proxypass or mod-jk..) 2015-03-15 0:15 GMT+01:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Petr, > > On 3/14/15 3:32 PM, Petr Nemecek wrote: >> Hello, >> >> our webapp, that is deployed in Tomcat 8.0.18, was tested positive >> as vulnerable to the slow http denial of service: "By using a >> single computer, it is possible to establish thousands of >> simultaneous connections and keep them open for a long time. During >> the attack, the server was rendered unavailable." >> >> Any idea what to do with this? > > Using the NIO connector is the best you can do, here. Or, front Tomcat > with a web server that has its own mitigation techniques. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVBMEoAAoJEBzwKT+lPKRYKMwP/iKY9W1YkBQ+qgdYWdcjhD55 > q7T8ssN2ChzU2xkVgiHh2ISZSchoOF3KcPNOnYomRn6/KPYaiSb/PWUmJ4WL0n/i > csSizG6PKV0fj3ZZk6j19QHKvdDNC7ntP6TC2XsK3bxdCG0LGMeZCKJEEihoKO5L > AbgWc9n0DVlKR5s9rMgGzNwjfL9aXva5ZWUY6O0bPb4uay0CcdFrouJLOOHMqjG9 > U8aVZ6Zpf7zYc8C0CYaKp6J9yRxM+RkHFszBuVuRKXB1FWQpFssLK3FugTP7+9Cp > blshbfpmaw6XSLlQcIMpO4uOgdCOg/KX4Dj5nNaXyR64qa4TleHcLy4b21Usaqwb > yVO0tnDlZA9qRGNsN3Djt9ABm5GIiJNsMOUsA7cjfGyaLr+NGKq8sLzXff8Nre4F > TKMIAgtpUp3RhMM6dRtJ/sFpLdtggNWWA0+zYlMDp20f5N4e3qtUAq2orIK3A7lM > FxcUMgajLZKlDoN4NiO26n97MWP0SzkQYj9/IkI5R2Mi9ijsZ+kSSj54pDFnV81C > OEzh7Xxb+8UrPLxLPZBttu1uT7hMZUvJwHJZM/nOLOr+J+vemrbFIg9UGFS1qcIR > pgWQEvANR1TFku6HhcgktQugfI4bEYzYxUsRvmX+CwlouzErIxkDq3S1qCFvMCwJ > jBy234U/r7X4a+P1p8HW > =v4ph > -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: AW: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest Authentication problem
Sascha, you can configure source address stickyness as well as
destination address stickyness, both will provide the same result
which will work for you.
2015-03-12 18:13 GMT+01:00 Mark Thomas :
> On 12/03/2015 15:20, Sascha Skorupa wrote:
>> Hi,
>>
>> here:
>>
>> http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
>>
>> the same problem is described and the recommended solution is to use sticky
>> load balancing. But, the problem in a tomcat cluster is that the session ID
>> is generated after a successful authentication. The first http response (401
>> with Authentication Header) does not contain a session ID.
>>
>> How should sticky load balancing be configured or how to enforce session id
>> generation before authentication?
>
> Most load-balancers have various options for doing this that don't
> depend on the back-end server at all.
>
> Mark
>
>
>>
>> Regards
>>
>> Olschi
>>
>>
>> Von: Sascha Skorupa
>> Gesendet: Mittwoch, 4. März 2015 16:21
>> An: 'users@tomcat.apache.org'
>> Cc: Sebastian Olscher
>> Betreff: Migration from Tomcat6-Cluster to Tomcat7-Cluster: Digest
>> Authentication problem
>>
>> Hi,
>>
>> because of changes in the HTTP digest implementation within the JDK 8
>> (https://bugs.openjdk.java.net/browse/JDK-8010505), we are forced to migrate
>> from tomcat 6 to 7.
>>
>> The problem is that we have a tomcat cluster (several tomcats behind an
>> apache/modjk server) and we cannot guarantee that both HTTP requests
>> resulting from the digest authentication are sent to the same tomcat
>> instance. In Tomcat 6 it was no problem because nonces were not cached or
>> rather unknown nonces did not force a re-authentication like it is done in
>> the DigestAuthenticator of Tomcat 7:
>>
>> if (info == null) {
>> // Nonce is valid but not in cache. It must have dropped
>> out
>> // of the cache - force a re-authentication
>> nonceStale = true;
>> }
>>
>> Some clients have the problem that the second 401 response to the request
>> with authorization header leads to an authentication failure although the
>> credentials are correct. Other clients like e.g. JMeter keep trying to send
>> authorisation header, if stale is true, until a HTTP 200 is responded.
>>
>> So, what is the recommendation here? How to use Digest authentication within
>> tomcat clusters if nonces are cached in a map within DigestAuthenticator?
>>
>> Best regards
>>
>> Sascha
>>
>>
>
>
> -
> 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: Getting javax.net.ssl.SSLHandshakeException
"I'm not sure how (or even if) you can have Java attempt to connect
with SSLv3 and then re-try with TLS."
I think it is possible, have a look on JSSE Reference Guide for
sun.security.ssl.allowUnsafeRenegotiation and
sun.security.ssl.allowLegacyHelloMessages, they're explaining how to
catch the SSLHandshakeException and launch one more startHandshake
method.
I admit I have not tried this, by the way..
"I don't believe Java 6 for example supports TLSv1.1 and TLSv1.2."
It doesn't, as said in the JSSE Reference Guide
(http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)
=> " Provides API support for SSL versions 2.0 and 3.0, TLS 1.0 and
later; and an implementation of SSL 3.0 and TLS 1.0"
A.T.
2015-02-26 17:37 GMT+01:00 Christopher Schultz :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Deepak,
>
> On 2/25/15 1:49 AM, dku...@ccilindia.co.in wrote:
>>> Perhaps you disabled SSLv3 and a client is trying to connect
>>> using SSLv3?
>>
>> We agree with your above statement. We have disabled SSLv3 on
>> Tomcat server and our client is an exe which sends request using
>> below code.
>
> (What's an "exe"?)
>
>> URL server = new URL(url); jprogress.setValue(11); final String
>> hostvar = ip; HttpsURLConnection.setDefaultHostnameVerifier(new
>> HostnameVerifier() { public boolean verify(String hostname,
>> SSLSession session) { if (hostname.equals(hostvar)) { return true;
>> } else { return false; } } });
>
> Note that the above is roughly equivalent to the default hostname
> verifier. Why are you bothering with that?
>
>> try{ HttpsURLConnection con = (HttpsURLConnection)
>> server.openConnection(); jprogress.setValue(14);
>> con.setConnectTimeout(9000);
>
> That is a *very* long timeout. Why?
>
>> con.setDoOutput(true); con.setUseCaches(false);
>> con.setReadTimeout(6);
>
> That's a pretty long timeout, too. Who wants to wait 60 seconds for a
> byte of data?
>
>> jprogress.setValue(16);
>>
>> We are unable to find at which point the client exe uses either TLS
>> or SSLv3 to send request to the server.
>
> It will depend upon the URL being passed-into the URL constructor:
> URL.openConnection will determine which protocol to use.
>
>> Also we find that client exe works fine in other machines. We want
>> to know if this is system specific or java specific.
>
> This is a combination of the two.
>
> If you want to force the client to use a different protocol (e.g.
> TLSv1 versus SSLv3), you need to tell HttpsURLConnection to use a
> different socket factory. Something like this:
>
> String protocol = ...; // "SSL" or "TLS"
> String[] sslEnabledProtocols = ...; // whatever specific protocols you
> want to support, like SSLv3, SSLv2hello, TLSv1.1, etc.
> String[] sslCipherSuites = ...; // Whatever SSL cipher suites you want
> to support
>
> TrustManager[] tms = ...; // Whatever trust managers you want to use
> Random random = new SecureRandom();
> SSLContext sc = SSLContext.getInstance(protocol);
>
> sc.init(null, tms, random);
>
> SSLSocketFactory sf = sc.getSocketFactory();
>
> if(null != sslEnabledProtocols
>|| null != sslCipherSuites)
> sf = new CustomSSLSocketFactory(sf,
> sslEnabledProtocols,
> sslCipherSuites);
>
> HttpsURLConnection.setDefaultSSLSocketFactory(sf);
>
> You'll also need this:
>
> public static class CustomSSLSocketFactory
> extends javax.net.ssl.SSLSocketFactory
> {
> private final String[] _sslEnabledProtocols;
> private final String[] _sslCipherSuites;
> private final SSLSocketFactory _base;
>
> public CustomSSLSocketFactory(SSLSocketFactory base,
> String[] sslEnabledProtocols,
> String[] sslCipherSuites)
> {
> _base = base;
> if(null == sslEnabledProtocols)
> _sslEnabledProtocols = null;
> else
> _sslEnabledProtocols = sslEnabledProtocols.clone();
> if(null == sslCipherSuites || 0 == sslCipherSuites.length)
> _sslCipherSuites = getDefaultCipherSuites();
> else if(1 == sslCipherSuites.length &&
> "ALL".equalsIgnoreCase(sslCipherSuites[0]))
> _sslCipherSuites = getSupportedCipherSuites();
> else
> _sslCipherSuites = sslCipherSuites.clone();
> }
>
> public String[] getDefaultCipherSuites() {
> return _base.getDefaultCipherSuites();
> }
> public String[] getSupportedCipherSuites() {
> return _base.getSupportedCipherSuites();
> }
>
> private SSLSocket customize(Socket s)
> {
> SSLSocket socket = (SSLSocket)s;
>
> if(null != _sslEnabledProtocols)
> socket.setEnabledProtocols(_sslEnabledProtocols);
>
> socket.setEnabledCipherSuites(_sslC
Re: [Hardening] Running tomcat under a specific account
Good post Christopher ;) It makes me remember this doc which is not bad for securing Tomcat : https://www.owasp.org/index.php/Securing_tomcat But it lacks some important information on Windows rights which could be more restricted (I'll try to post something about it one day). And others like : -disabling deploy-on-startup / auto-deployment then a hacker cannot push its own war file (but more work to push your own, trusted wars, never seen such config in production till now but it makes sense) -disabling Jasper for existing JSPs then a hacker cannot modify a JSP ( http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html#Production_Configuration ), but this has no effect on a newly hacker-created JSP which still can be browsed/compiled/executed. However this last one problem can be addressed by the Security Manager for disabling file creation (example : http://blog.river-tiger.com/tomcat-against-hacking) A.T. 2015-02-26 14:43 GMT+01:00 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Aurélien, > > On 2/26/15 5:23 AM, Aurélien Terrestris wrote: >> I agree with Leon. > > As do I. Apache httpd can change the attack surface somewhat, but if > requests can still come from an untrusted remote client through to the > application server, then you still have to protect the application server. > >> That said, a service account with low privileges only gives >> filesystem protection ; interesting data is usually stored in the >> database and you won't be more protected against SQL injections or >> even against a modified jsp stored by the hacker (like in some old >> STRUTS vulnerabilities). > > Absolutely. SQL injections /should not/ be a problem with > properly-written Java programs given how easy parameterized queries > are with JDBC, but of course it's also easy to do it the wrong way > and open yourself up. In this situation, it's the application that > needs to be audited and not the container. > >> If you can't buy a real WAF, you still can configure Apache with >> ModSecurity or even try the LUA experimental module ( >> http://blog.river-tiger.com/cheapest-application-firewall ) but >> don't expect high performance with it. > > I had never heard of the LUA hack. I'll have to look into it. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJU7yLsAAoJEBzwKT+lPKRYgpMQALkhWLIO1r78d/jY/VixmTVI > dNCszRrUl8JTwPMEmrr/Wk3aeq23850XxxmugHMss/bOXk1yh12OFh0i8isMWKsV > l/KOLL11x7ToNBknVwHKh+OEU2TcMjXEHtc65a9komC90BDGHAsgT12xFOrRcJ4k > mL8GEDW7xJbZocHHrfqc2Q0ZU3rw2eR8+gTgtf/y8YlCzrwlHvULEjfgtdD/h3fq > 9uKn9Rp7Ebn4pmW1iarWXVsKf0l7buayMNBksshcJppSLLXaklefyas6fYC1LyuP > /6TDpAIMWZuzDVZtDU4dzNpDy6F+DZEa0ErOK/1+CrfU0/t6uMJ9iJpM9PUs4p3g > VXOWR1Bs6NG+mgGJLL3VYrUiww0CbhtllAX7CbZpYrFBERXA++xkhQPOZRP5bhcg > 0DfUhS07JNYC8qmPPyXyeiuYYYhtjxanRBU+JxNa5hBlYqUklBHdMFNKhjaOe7+y > scEEraNBw5x0KyfS3B+lVlmUX5iku0fgyQnxSGwR3Mt604qLn4ZXR04Tb9K282ve > uhLa9F14qBGoGe5RIvs0MkvMEG9UpO9de6HuddE0CWa49Km5QCloEmM4WcwuDJNC > Loc9RnHBTQEfQQuRHctKzCVgPRsNBcwSCKz9G12man7EBK9fkvve1L/ItKrt7V/T > 1rKQjsU1kX1yAH+f7Epy > =UPaz > -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: [Hardening] Running tomcat under a specific account
I agree with Leon. That said, a service account with low privileges only gives filesystem protection ; interesting data is usually stored in the database and you won't be more protected against SQL injections or even against a modified jsp stored by the hacker (like in some old STRUTS vulnerabilities). If you can't buy a real WAF, you still can configure Apache with ModSecurity or even try the LUA experimental module ( http://blog.river-tiger.com/cheapest-application-firewall ) but don't expect high performance with it. 2015-02-25 23:32 GMT+01:00 Leon Rosenberg : > Hello Jan, > > that would be better yes. For example some time ago, there were a virus > that would place a modified jsp in a webapp and try to access further data > from it. If the user, the tomcat runs under, would have limited permission, > such a malware would have less chances to actually do something harmful. > As for my personal opinion and 10++ years of experience with different > tomcat version in production environment, (attention, flame war can start > here), an apache httpd in front of tomcat does _not_ increase the security > _at_all_. > In fact I would argue that it adds its buffer overflows and bugs to the > bugs that could exists in tomcats code. > > regards > Leon > > > On Wed, Feb 25, 2015 at 11:13 PM, Jan Tosovsky wrote: > >> Dear All, >> >> there are plenty resources mentioning it is a must to run tomcat as a >> dedicated user with limited permissions. >> >> Is it still true when tomcat doesn't run standalone, but via Apache web >> server connected via AJP? That webserver already runs in the restrictive >> mode. >> >> Thanks, Jan >> >> >> >> >> >> - >> 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: Tomcat 8 + mod_jk + apache 2.2x on FreeBSD
>I get Tomcat default home page, but images and CSS are not loaded: All resources are not available and all links are broken. This happens because you're proxyfying to /dspace but Tomcat "ROOT" webapp is written for the "/" context http://www.cs.ait.ac.th/dspace/docs/manager-howto.html then works correctly Maybe, try renaming the ROOT folder (tomcat/webapps/ROOT) to dspace, and update your proxypass to ProxyPass /dspace ajp://localhost:8809/dspace ProxyPassReverse /dspace ajp://localhost:8809/dspace If renaming the folder, the ROOT.war will recreate it.. maybe necessary to rename it also. regards 2014-12-15 9:16 GMT+01:00 Olivier Nicole : > Aurélien, > >> if Apache and Tomcat are running on the same machine, the tcpdump >> won't capture the trafic because the proxy requests are using the >> loopback interface and not the ethernet port. > > tcpdump -i lo0 ;) > >> Instead of using the "workers" properties and the mod-jk section, you >> could try with the ProxyPass syntax (easier, faster for your need) >> >> >> LoadModule proxy_module modules/mod_proxy.so >> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so >> >> ProxyPass / ajp://localhost:8009/ >> ProxyPassReverse / ajp://localhost:8009/ > > That work, I get Tomcat default home page, but images and CSS are not > loaded: see http://www.cs.ait.ac.th/dspace > > Thank you, > > Olivier > > >> Then, try a ' netstat -an ' to see the ESTABLISHED, it should look >> like this with at least one ESTABLISHED line >> >> tcp0 0 :::8009 :::* >> LISTEN >> tcp0 0 :::127.0.0.1:8009 :::127.0.0.1:39908 >> ESTABLISHED >> >> >> regards >> >> 2014-12-15 8:13 GMT+01:00 Olivier Nicole : >>> Hi, >>> >>> I am completely new to Tomcat and/or java, but I have been assigned the >>> task to get it running. >>> >>> Right now, tomcat is running on port 8090 and I can access the pages in >>> a satisfactory way. >>> >>> I am also running what I expect to be the ajp13 connector with: >>> >>enableLookups="false" >>>redirectPort="8443" /> >>> and I can see that the port 8009 is listening. >>> >>> Now I would like to have Tomcat behind my Apache (2.2.27) server. >>> >>> I setup a worker.properties file that is like: >>> >>> workers.tomcat_home=/usr/local/apache-tomcat-8.0 >>> workers.java_home=/usr/local/openjdk7 >>> ps=/ >>> worker.list=localhost-worker >>> worker.localhost-worker.port=8009 >>> worker.localhost-worker.host=localhost >>> worker.localhost-worker.type=ajp13 >>> worker.localhost-worker.lbfactor=1 >>> >>> and in httpd.conf I have: >>> >>> LoadModule jk_module libexec/apache22/mod_jk.so >>> >>> JkWorkersFile /usr/local/etc/apache22/workers.properties >>> JkLogFile /var/log/jk.log >>> JkShmFile /var/run/httpd/mod_jk.shm >>> JkLogLevel info >>> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " >>> JkRequestLogFormat "%w %V %T" >>> >>> # Sample JkMounts. Replace these with the paths you would >>> # like to mount from your JSP server. >>> #JkMount /*.jsp jsp-hostname >>> #JkMount /servlet/* jsp-hostname >>> #JkMount /examples/* jsp-hostname >>> >>> >>> And the proper JkMount >>> >>> I see that Apache is connecting to tomcat on port 8009, but I cannot get >>> much information from the tcpdump trace. >>> >>> I have no idea where to look for log file (beside the >>> tomcat-home/logs/catalina.out that I don't understand >>> >>> I have been looking at many how-to, but all of them are incomplete, >>> outdated, and refeer to tens of things that I don't understand either. >>> >>> Is there an comprehensive how-to interface Apache to Tomcat? Something >>> with example I can simply copy to make it work? >>> >>> I am using FreeBSD 9.2 >>> >>> Thanks in advance, >>> >>> Olivier >>> >>> -- >>> >>> - >>> 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 >> >> > > -- > > - > 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: Tomcat 8 + mod_jk + apache 2.2x on FreeBSD
Olivier, if Apache and Tomcat are running on the same machine, the tcpdump won't capture the trafic because the proxy requests are using the loopback interface and not the ethernet port. Instead of using the "workers" properties and the mod-jk section, you could try with the ProxyPass syntax (easier, faster for your need) LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/ Then, try a ' netstat -an ' to see the ESTABLISHED, it should look like this with at least one ESTABLISHED line tcp0 0 :::8009 :::* LISTEN tcp0 0 :::127.0.0.1:8009 :::127.0.0.1:39908 ESTABLISHED regards 2014-12-15 8:13 GMT+01:00 Olivier Nicole : > Hi, > > I am completely new to Tomcat and/or java, but I have been assigned the > task to get it running. > > Right now, tomcat is running on port 8090 and I can access the pages in > a satisfactory way. > > I am also running what I expect to be the ajp13 connector with: > enableLookups="false" >redirectPort="8443" /> > and I can see that the port 8009 is listening. > > Now I would like to have Tomcat behind my Apache (2.2.27) server. > > I setup a worker.properties file that is like: > > workers.tomcat_home=/usr/local/apache-tomcat-8.0 > workers.java_home=/usr/local/openjdk7 > ps=/ > worker.list=localhost-worker > worker.localhost-worker.port=8009 > worker.localhost-worker.host=localhost > worker.localhost-worker.type=ajp13 > worker.localhost-worker.lbfactor=1 > > and in httpd.conf I have: > > LoadModule jk_module libexec/apache22/mod_jk.so > > JkWorkersFile /usr/local/etc/apache22/workers.properties > JkLogFile /var/log/jk.log > JkShmFile /var/run/httpd/mod_jk.shm > JkLogLevel info > JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " > JkRequestLogFormat "%w %V %T" > > # Sample JkMounts. Replace these with the paths you would > # like to mount from your JSP server. > #JkMount /*.jsp jsp-hostname > #JkMount /servlet/* jsp-hostname > #JkMount /examples/* jsp-hostname > > > And the proper JkMount > > I see that Apache is connecting to tomcat on port 8009, but I cannot get > much information from the tcpdump trace. > > I have no idea where to look for log file (beside the > tomcat-home/logs/catalina.out that I don't understand > > I have been looking at many how-to, but all of them are incomplete, > outdated, and refeer to tens of things that I don't understand either. > > Is there an comprehensive how-to interface Apache to Tomcat? Something > with example I can simply copy to make it work? > > I am using FreeBSD 9.2 > > Thanks in advance, > > Olivier > > -- > > - > 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 Best Practices on Windows Service
>In my previous employment, we did that. Create a local user account and set permissions to the Tomcat installation directory and optional CATALINA_BASE (if you separated them). I agree with this (done hundreds of times), and you can set rights with xcacls. However this reminds us that usually the webapps directory must be writable for auto-deployment, as are temp, work and even conf (uploading of META-INF/context.xml to conf/Catalina) directories. This is good but not sufficient for complete security. For example, one still could exploit a vulnerability and introduce jsps of his own. Of course this jsp could not write outside anything of TOMCAT_BASE, but your website could be defaced or give a backdoor to a database. 2014-11-05 21:19 GMT+01:00 Leo Donahue : > On Wed, Nov 5, 2014 at 1:34 PM, Igal @ getRailo.org > wrote: > >> hi, >> >> what are the security best practices for running Tomcat as a Windows >> Service? >> >> is the local system account safe > > > Define safe. LocalSystem has too many privs that a Tomcat service account > doesn't need in my opinion. > > or am I better off creating a new user >> and giving it write permissions only to the Tomcat runtime folders and >> read permissions to the web contents folder? >> >> > In my previous employment, we did that. Create a local user account and > set permissions to the Tomcat installation directory and optional > CATALINA_BASE (if you separated them). We did not use domain accounts for > the Tomcat service account because the Tomcat service account did not need > access to network resources in our setup. Create a strong password. > > Leo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security Best Practices on Windows Service
>In my previous employment, we did that. Create a local user account and set permissions to the Tomcat installation directory and optional CATALINA_BASE (if you separated them). I agree with this (done hundreds of times), and you can set rights with xcacls. However this reminds us that usually the webapps directory must be writable for auto-deployment, as are temp, work and even conf (uploading of META-INF/context.xml to conf/Catalina) directories. This is good but not sufficient for complete security. For example, one still could exploit a vulnerability and introduce jsps of his own. Of course this jsp could not write outside anything of TOMCAT_BASE, but your website could be defaced or give a backdoor to a database. A.T. 2014-11-05 21:19 GMT+01:00 Leo Donahue : > On Wed, Nov 5, 2014 at 1:34 PM, Igal @ getRailo.org > wrote: > >> hi, >> >> what are the security best practices for running Tomcat as a Windows >> Service? >> >> is the local system account safe > > > Define safe. LocalSystem has too many privs that a Tomcat service account > doesn't need in my opinion. > > or am I better off creating a new user >> and giving it write permissions only to the Tomcat runtime folders and >> read permissions to the web contents folder? >> >> > In my previous employment, we did that. Create a local user account and > set permissions to the Tomcat installation directory and optional > CATALINA_BASE (if you separated them). We did not use domain accounts for > the Tomcat service account because the Tomcat service account did not need > access to network resources in our setup. Create a strong password. > > Leo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Remote Tomcat webapps bidirectional communication
Hello I think that application to application calls should be implemented with web services (there is much choice but maybe heavy to implement). When implementing such a solution, particularly if trafic goes through internet, you must check that you're using a firewall in order to avoid false requests that could from hackers. A.T. 2014-06-14 23:56 GMT+02:00 Lmhelp1 : > Hello, > > My question is about what code to write to allow two remote Tomcat webapps > to communicate with one another through the Internet. > > Let me explain more precisely what I would like to do. > (I'm just simplifying a bit the real situation). > > - I have a Tomcat webapp running on a server in England. > - I have another Tomcat webapp running on a server in France. > > - I have a JSP inside the England webapp. > - This JSP contains a form with two fields "First name" and "Last name". > - I would like to send these information to the France webapp. > > - After the England form has been submitted, I can collect the information > "First name" and "Last name" in a servlet. > > Can you tell me what I shall do then to send these information to the France > webapp? > Is it something like a "response.sendRedirect(..."? > How does it have to be written? > > - Meantime, the France webapp needs to be able to wait for these information > and, when they arrive, to get them and do something with them. For example > store the "First name" and "Last name" in a database, etc. > > What kind of a code has to be written in the France webapp? > Is it a servlet with a "doGet()" retrieving the information "First name" and > "Last name"? > > - Moreover, when the France webapp has finished it's job, it needs to tell > the England webapp that it has finished, send it a file and some > information. > So the communication has to be bidirectional. > > Can you please give me some indications on how to start dealing with this? > Or maybe a tutorial or an example? > > Thank you and best regards. > -- > Léa Massiot > > - > 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: Restrict the use of JDK classes Tomcat 7 or 6
>From what I understand in this doc, there is no specific resource management code anywhere and you must ensure that your application will call permission checking every time you are going to access the protected resource. Even for a web application, it must be considered as any other application, and it's in your own code to call such checking. The doc says : "Second, include these new classes with the application package." so include your class in your jar or war file. Yes, Tomcat is supposed to behave such any other JVM. However, you need to update the catalina.policy file for your own permission, and don't forget to call the security manager from the startup script ( http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html ) 2013/11/17 ANALIA DE PEDRO SANTAMARIA <100074...@alumnos.uc3m.es>: > Thank you very much. I have been working in creating my own permission and > I have some questions: > > - In the Java documentation says it is necessary to add a checkPermission > in the application's resource management code. My question is, when we are > working with web applications, which is the application's resource > management code? And where is it? > > - When I create my own permission class, where do I have to store it? In > order to the Security manager can find it. > > - I have read that it is not necessary to modify the Security Manager, when > we are creating a new permission for secure the JVM. When we are working > with Tomcat, and not with the JVM directly, is it the same? Or is it > necessary to modify the Tomcat's Security Manager? > > Thank you very much. > > > > 2013/11/12 Aurélien Terrestris > >> Hello Analia >> >> I'm glad that you could play successfully with the Security Manager as >> I advised first :D >> >> >> About permissions, here you have a doc : >> >> >> http://docs.oracle.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc3.html#20211 >> >> best regards >> >> 2013/11/11 ANALIA DE PEDRO SANTAMARIA <100074...@alumnos.uc3m.es>: >> > Hello, >> > >> > I have been working with the Security Manager and I think it is a good >> > aproximation of what I need, thank you very much for the advice. I have >> > read that it is possible to create your own Permission class, but I >> haven't >> > found any documentation or example. Could anybody tell me where I can >> find >> > information about create a Permission class? >> > >> > Thank you very much. >> > >> > >> > 2013/10/23 Caldarale, Charles R >> > >> >> > From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> >> > Subject: Re: Restrict the use of JDK classes Tomcat 7 or 6 >> >> >> >> > When you say "Java classes", are you talking about re-defining >> >> > something like java.lang.String? If so, then the servlet spec (3.0: >> >> > 10.7.2) prohibits web applications from loading classes from any of >> >> > these packages from a web application class loader. >> >> > java.* >> >> > javax.* >> >> > Looking at current trunk, Tomcat appears to take a lazy view and just >> >> > look for these two classes: >> >> > javax.servlet.Servlet >> >> > javax.el.Expression >> >> > So it looks like you might be able to redefine java.lang.String if you >> >> > want. >> >> >> >> As I recall, the JVM itself prevents loading of java.* classes from >> >> anywhere other than the registered JRE jar locations. Not sure about >> >> javax.* classes. >> >> >> >> - Chuck >> >> >> >> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> >> MATERIAL and is thus for use only by the intended recipient. If you >> >> received this in error, please contact the sender and delete the e-mail >> and >> >> its attachments from all computers. >> >> >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> >> >> >> - >> 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
Fwd: Restrict the use of JDK classes Tomcat 7 or 6
Hello Analia I'm glad that you could play successfully with the Security Manager as I advised first :D About permissions, here you have a doc : http://docs.oracle.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc3.html#20211 best regards 2013/11/11 ANALIA DE PEDRO SANTAMARIA <100074...@alumnos.uc3m.es>: > Hello, > > I have been working with the Security Manager and I think it is a good > aproximation of what I need, thank you very much for the advice. I have > read that it is possible to create your own Permission class, but I haven't > found any documentation or example. Could anybody tell me where I can find > information about create a Permission class? > > Thank you very much. > > > 2013/10/23 Caldarale, Charles R > >> > From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> > Subject: Re: Restrict the use of JDK classes Tomcat 7 or 6 >> >> > When you say "Java classes", are you talking about re-defining >> > something like java.lang.String? If so, then the servlet spec (3.0: >> > 10.7.2) prohibits web applications from loading classes from any of >> > these packages from a web application class loader. >> > java.* >> > javax.* >> > Looking at current trunk, Tomcat appears to take a lazy view and just >> > look for these two classes: >> > javax.servlet.Servlet >> > javax.el.Expression >> > So it looks like you might be able to redefine java.lang.String if you >> > want. >> >> As I recall, the JVM itself prevents loading of java.* classes from >> anywhere other than the registered JRE jar locations. Not sure about >> javax.* classes. >> >> - Chuck >> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you >> received this in error, please contact the sender and delete the e-mail and >> its attachments from all computers. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restrict the use of JDK classes Tomcat 7 or 6
Hello Analia I'm glad that you could play successfully with the Security Manager as I advised first :D About permissions, here you have a doc : http://docs.oracle.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc3.html#20211 best regards 2013/11/11 ANALIA DE PEDRO SANTAMARIA <100074...@alumnos.uc3m.es>: > Hello, > > I have been working with the Security Manager and I think it is a good > aproximation of what I need, thank you very much for the advice. I have > read that it is possible to create your own Permission class, but I haven't > found any documentation or example. Could anybody tell me where I can find > information about create a Permission class? > > Thank you very much. > > > 2013/10/23 Caldarale, Charles R > >> > From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> > Subject: Re: Restrict the use of JDK classes Tomcat 7 or 6 >> >> > When you say "Java classes", are you talking about re-defining >> > something like java.lang.String? If so, then the servlet spec (3.0: >> > 10.7.2) prohibits web applications from loading classes from any of >> > these packages from a web application class loader. >> > java.* >> > javax.* >> > Looking at current trunk, Tomcat appears to take a lazy view and just >> > look for these two classes: >> > javax.servlet.Servlet >> > javax.el.Expression >> > So it looks like you might be able to redefine java.lang.String if you >> > want. >> >> As I recall, the JVM itself prevents loading of java.* classes from >> anywhere other than the registered JRE jar locations. Not sure about >> javax.* classes. >> >> - Chuck >> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you >> received this in error, please contact the sender and delete the e-mail and >> its attachments from all computers. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restrict the use of JDK classes Tomcat 7 or 6
You can run Tomcat with its Security Manager, then you can setup which jar has which rights have a look here : http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html 2013/10/22 ANALIA DE PEDRO SANTAMARIA <100074...@alumnos.uc3m.es>: > Hello, > > I would like to know if is it possible to restrict the use of JDK classes > in Tomcat according to a list given in another file. ¿Is it possible by > creating a new Add-on? If it is possible, where can I find documentation > about creating Add-ons? I have looked up and I haven't found any > information about it (I only have found AddOns in Tomcat 3.3 but there is > nothing about creating new ones). > > Another idea to do that is by modifying the source code. Could anybody tell > me where I should search to do that? > > Thank you very much. > > Analía de Pedro - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Hi
the JSSE Reference Guide defines which possibilities for anyone
implementing a JSSE provider (let's call it an API if you want).
Oracle's provider only implements a part of this API, misleading you
to believe SHA384 is available when it's unfortunately not.
About Bouncy Castle, I believe they only implement a JCE provider and
not any JSSE provider. Adding their jar to your providers in the
security file is not enough.. you would have to implement a full JSSE
provider using their JCE classes. A lot of work.
If you're looking for the best security, I would tell you to use the
available DHE and ECDHE ciphersuites which make things complicated to
decrypt. Have a look here for more information :
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
RFC 5288 is interesting, we probably have to wait some more years
before we can use all these new ciphers.
best regards
A.T.
2013/8/23 Dennis Sosnoski :
> Thanks, Aurélien. I'd seen the SHA384 versions listed in the JSSE Cipher
> Suite Names and thought they were available:
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites
>
> I was really hoping to use one of the GCM suites, but I gather those are not
> officially approved yet either: http://tools.ietf.org/html/rfc5288 It
> appears there is growing support for these in the world, even if they're not
> yet an official part of TLS 1.2.
>
> On the client side, this:
>
> SSLContext context = SSLContext.getInstance("TLS");
> context.init(null, new TrustManager[] { tm }, null);
> SSLParameters params = context.getSupportedSSLParameters();
> String[] suites = params.getCipherSuites();
> System.out.println("Connecting with " + suites.length + " cipher
> suites supported:");
> for (int i = 0; i < suites.length; i++) {
> System.out.print(' ');
> System.out.println(suites[i]);
> }
>
> gives me a list of "supported" cipher suites including:
>
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> TLS_RSA_WITH_AES_256_CBC_SHA256
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> ...
>
> but when I try to connect using the socket factory from the context I get
> the ssl debug information:
>
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> ...
>
> where all the variations using SHA256 or SHA384 are in this second list. But
> explicitly setting a suite like:
>
> System.setProperty("https.cipherSuites",
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256");
>
> works, while the SHA384 version fails with "Unsupported ciphersuite" (as
> does any version I've tried using GCM in place of CBC).
>
> I thought JSSE would use the JCE algorithms from BouncyCastle, but it looks
> like this doesn't work. I'll have to dig into the JSSE code to see what's
> going wrong on that part.
>
> - Dennis
>
>
> On 08/23/2013 03:48 AM, Aurélien Terrestris wrote:
>>
>> According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See :
>> http://www.ietf.org/rfc/rfc5246.txt
>>
>> The JSSE Reference Guide also doesn't talk about this SHA384 as an
>> implementation requirement. See :
>>
>> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
>>
>> This means you have a problem with SHA256 only. Maybe it's easier to
>> test on client-side, with one of the following ciphers (that you find
>> on the same Reference Guide ) for example :
>>
>> TLS_DH_RSA_WITH_AES_256_CBC_SHA256
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>>
>> Let me know if this works, or I will try to test by myself with my own
>> client.
>>
>>
>>
>> 2013/8/22 Dennis Sosnoski :
>>>
>>> I've already done that, though as far as I can see that doesn't effect
>>> the
>>> digest algorithms (only the encryption options).
>>>
>>>- Dennis
>>>
>>>
>>> On 08/23/2013 12:24 AM, Aurélien Terrestris wrote:
>>>>
>>>> Hello
>>>>
>>>> I suppose you need to run y
Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms
It seems incorrect to me because RFC 5246 in "1.2 Major Differences from TLS 1.1" says this : .. "All cipher suites in this document use P_SHA256." .. "Added HMAC-SHA256 cipher suites" I can't read anywhere that SHA384 and others "SHOULD" or "MUST" be implemented. Other RFCs updating this 5246 (5746, 5878, 6176 and Errata) don't talk about this either. However, in 5246 "5. HMAC and the Pseudorandom Function" we can read : "In this section, we define one PRF, based on HMAC. This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function. " This allows future usage of SHA384 and others, if defined correctly. regards A.T. 2013/8/22 Martin Gainty : > point of confusion Eric Rescorla specifically cites SHA384 in his cipher > examples for TLS 1.2 Update > > http://www.ietf.org/rfc/rfc5246.txt > http://www.ietf.org/proceedings/70/slides/tls-0.pdf > > Kuat Eshengazin used bltest as a test harness for SHA384 > > bltest -R -m prf_sha384 -k tests/prf_sha384/key0 -t > tests/prf_sha384/seed0 -h -g 148 -x > > https://bugzilla.mozilla.org/show_bug.cgi?id=480514 > > Is this incorrect? > Martin > __ > Please do not alter or disrupt this transmission..Thank You > > > > >> Date: Thu, 22 Aug 2013 14:53:55 +0100 >> Subject: Re: Tomcat 7 / Java 7 with TLS 1.2 algorithms >> From: aterrest...@gmail.com >> To: users@tomcat.apache.org >> >> According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : >> http://www.ietf.org/rfc/rfc5246.txt >> >> The JSSE Reference Guide also doesn't talk about this SHA384 as an >> implementation requirement. See : >> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl >> >> This means you have a problem with SHA256 only. Maybe it's easier to >> test on client-side, with one of the following ciphers (that you find >> on the same Reference Guide ) for example : >> >> TLS_DH_RSA_WITH_AES_256_CBC_SHA256 >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 >> >> Let me know if this works, or I will try to test by myself with my own >> client. >> >> >> >> 2013/8/22 Dennis Sosnoski : >> > I've already done that, though as far as I can see that doesn't effect the >> > digest algorithms (only the encryption options). >> > >> > - Dennis >> > >> > >> > On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: >> >> >> >> Hello >> >> >> >> I suppose you need to run your JVM with the unrestricted policy files (on >> >> b= >> >> oth client and server sides). You have to download them from Oracle >> >> website= >> >> for your java version, and replace the old. >> >> >> >> These files are : >> >> local_policy.jar >> >> US_export_policy.jar >> >> >> >> Regards >> >> >> >> 2013/8/22 : >> >>> >> >>> Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a >> >>> sslEnabledProtocols="TLSv1.2" attribute on the . But I haven't >> >>> been able to make it work with any of the SHA256/384 algorithms - they >> >>> always show up in the "Ignoring unsupported cipher suite" list. I get the >> >>> same thing happening when I try to use them from client code, so I know >> >>> it's >> >>> not a Tomcat issue, but I'm hoping someone knows a workaround. >> >>> >> >>> Any suggestions? >> >>> >> >>> Thanks, >> >>> >> >>> - Dennis >> >>> >> >>> >> >>> >> >>> - >> >>> 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 >> >> >> >> >> > >> > >> > - >> > 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 >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Tomcat 7 / Java 7 with TLS 1.2 algorithms
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : http://www.ietf.org/rfc/rfc5246.txt The JSSE Reference Guide also doesn't talk about this SHA384 as an implementation requirement. See : http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl This means you have a problem with SHA256 only. Maybe it's easier to test on client-side, with one of the following ciphers (that you find on the same Reference Guide ) for example : TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Let me know if this works, or I will try to test by myself with my own client. 2013/8/22 Dennis Sosnoski : > I've already done that, though as far as I can see that doesn't effect the > digest algorithms (only the encryption options). > > - Dennis > > > On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: >> >> Hello >> >> I suppose you need to run your JVM with the unrestricted policy files (on >> b= >> oth client and server sides). You have to download them from Oracle >> website= >> for your java version, and replace the old. >> >> These files are : >> local_policy.jar >> US_export_policy.jar >> >> Regards >> >> 2013/8/22 : >>> >>> Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a >>> sslEnabledProtocols="TLSv1.2" attribute on the . But I haven't >>> been able to make it work with any of the SHA256/384 algorithms - they >>> always show up in the "Ignoring unsupported cipher suite" list. I get the >>> same thing happening when I try to use them from client code, so I know it's >>> not a Tomcat issue, but I'm hoping someone knows a workaround. >>> >>> Any suggestions? >>> >>> Thanks, >>> >>>- Dennis >>> >>> >>> >>> - >>> 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 >> >> > > > - > 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: Tomcat 7 / Java 7 with TLS 1.2 algorithms
According to RFC 5246 Appendix C (TLS 1.2), there is no SHA384. See : http://www.ietf.org/rfc/rfc5246.txt The JSSE Reference Guide also doesn't talk about this SHA384 as an implementation requirement. See : http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl This means you have a problem with SHA256 only. Maybe it's easier to test on client-side, with one of the following ciphers (that you find on the same Reference Guide ) for example : TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Let me know if this works, or I will try to test by myself with my own client. 2013/8/22 Dennis Sosnoski : > I've already done that, though as far as I can see that doesn't effect the > digest algorithms (only the encryption options). > > - Dennis > > > On 08/23/2013 12:24 AM, Aurélien Terrestris wrote: >> >> Hello >> >> I suppose you need to run your JVM with the unrestricted policy files (on >> b= >> oth client and server sides). You have to download them from Oracle >> website= >> for your java version, and replace the old. >> >> These files are : >> local_policy.jar >> US_export_policy.jar >> >> Regards >> >> 2013/8/22 : >>> >>> Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a >>> sslEnabledProtocols="TLSv1.2" attribute on the . But I haven't >>> been able to make it work with any of the SHA256/384 algorithms - they >>> always show up in the "Ignoring unsupported cipher suite" list. I get the >>> same thing happening when I try to use them from client code, so I know it's >>> not a Tomcat issue, but I'm hoping someone knows a workaround. >>> >>> Any suggestions? >>> >>> Thanks, >>> >>>- Dennis >>> >>> >>> >>> - >>> 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 >> >> > > > - > 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: Tomcat 7 / Java 7 with TLS 1.2 algorithms
Hello I suppose you need to run your JVM with the unrestricted policy files (on b= oth client and server sides). You have to download them from Oracle website= for your java version, and replace the old. These files are : local_policy.jar US_export_policy.jar Regards 2013/8/22 : > Tomcat 7.0.40 seems to work well with TLS 1.2, forced by using a > sslEnabledProtocols="TLSv1.2" attribute on the . But I haven't > been able to make it work with any of the SHA256/384 algorithms - they always > show up in the "Ignoring unsupported cipher suite" list. I get the same thing > happening when I try to use them from client code, so I know it's not a > Tomcat issue, but I'm hoping someone knows a workaround. > > Any suggestions? > > Thanks, > > - Dennis > > > > - > 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
