RE: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Chinoy Gupta]

Thanks for the info Mark.

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, June 22, 2016 11:43 AM
To: Tomcat Users List 
Subject: Re: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability

On 22/06/2016 05:51, Chinoy Gupta wrote:
> What about 8.5.x branch? Is that also affected.

Yes. 8.5.0 to 8.5.2 are affected.

> And I am not able to see this update on Tomcat security page. Any reasons for 
> that?

Oversight. I'll get it added later today unless someone beats me to it.
I'll also send out a corrected, Tomcat specific announcement for this rather 
than the forwarded one from Apache Commons below which has a number of errors 
in the Tomcat version information:
- 8.5.x is not listed (8.5.0 to 8.5.2 are affected)
- 6.0.x is listed as affected when it is not
- 5.5.x and earlier are listed as may be affected when they are not

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, June 21, 2016 3:23 PM
> To: users@tomcat.apache.org; d...@tomcat.apache.org; 
> annou...@tomcat.apache.org; annou...@apache.org; 
> secur...@tomcat.apache.org
> Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information 
> disclosure vulnerability
> 
> 
>  Original Message 
> From: Jochen Wiedmann 
> Sent: 21 June 2016 10:18:15 BST
> To: priv...@commons.apache.org, "secur...@apache.org" 
> , Tomcat Security List 
> , annou...@apache.org, Apache Commons 
> Developers List 
> Subject: CVE-2016-3092: Apache Commons Fileupload information 
> disclosure vulnerability
> 
> CVE-2016-3092: Apache Commons Fileupload information disclosure 
> vulnerability
> 
> Severity: Moderate
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> Apache Commons Fileupload 1.3 to 1.3.1 Apache Commons Fileupload 1.2 
> to 1.2.2 The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x 
> may also be affected.
> Apache Tomcat 9.x to 9.0.0M6
> Apache Tomcat 8.x to 8.0.35
> Apache Tomcat 7.x to 7.0.69
> Apache Tomcat 6.x
> Unsupported versions of Apache Tomcat, like 5.x may also be affected.
> Apache Struts 2.5.x, and previous versions, which are distributing Commons 
> FileUpload 1.3.1, or earlier versions.
> 
> Description:
> A malicious client can send file upload requests that cause the HTTP server 
> using the Apache Commons Fileupload library to become unresponsive, 
> preventing the server from servicing other requests.
> 
> This flaw is not exploitable beyond causing the code to loop expending CPU 
> resources.
> 
> 
> Mitigation:
> All users of Apache Commons Fileupload should upgrade to 1.3.2.
> All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, 
> respectively.
> All users of Apache Struts should replace the copy of Commons FileUpload 
> (which is distributed as part of Struts) with the fixed version 1.3.2.
> 
> Workaround:
> 
> System administrators should restrict the permitted maximum size of HTTP 
> request header values (For example, Apache Httpd provides a 
> LimitRequestFieldSize directive, and Apache Tomcat provides a 
> maxHttpHeaderSize attribute in their respective configuration files). A 
> maximum header value size of 2048 bytes would block all dangerous request.
> 
> Example:
> File upload requests contain a so-called boundary in the Content-Type header:
> 
> Content-Type: multipart/mixed;
>   boundary=gc0p4Jq0M2Yt08jU534c0p
> 
> The boundary may be chosen by the request sender. In the case of previous 
> versions of Apache Commons Fileupload the boundary becomes dangerous, if its 
> size is close to 4096 bytes.
> 
> Credit:
> TERASOLUNA Framework Development Team at the Software Engineering, Research 
> and Development Headquarter, for detecting this flaw, and reporting it to the 
> JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported 
> this problem to us.
> 
> References:
> https://commons.apache.org/proper/commons-fileupload/security.html
> 
> 
> 
> Note: Apache Tomcat 6.x and earlier are NOT affected.


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

Re: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Mark Thomas]

On 22/06/2016 05:51, Chinoy Gupta wrote:
> What about 8.5.x branch? Is that also affected.

Yes. 8.5.0 to 8.5.2 are affected.

> And I am not able to see this update on Tomcat security page. Any reasons for 
> that?

Oversight. I'll get it added later today unless someone beats me to it.
I'll also send out a corrected, Tomcat specific announcement for this
rather than the forwarded one from Apache Commons below which has a
number of errors in the Tomcat version information:
- 8.5.x is not listed (8.5.0 to 8.5.2 are affected)
- 6.0.x is listed as affected when it is not
- 5.5.x and earlier are listed as may be affected when they are not

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Tuesday, June 21, 2016 3:23 PM
> To: users@tomcat.apache.org; d...@tomcat.apache.org; 
> annou...@tomcat.apache.org; annou...@apache.org; secur...@tomcat.apache.org
> Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information disclosure 
> vulnerability
> 
> 
>  Original Message 
> From: Jochen Wiedmann 
> Sent: 21 June 2016 10:18:15 BST
> To: priv...@commons.apache.org, "secur...@apache.org" , 
> Tomcat Security List , annou...@apache.org, 
> Apache Commons Developers List 
> Subject: CVE-2016-3092: Apache Commons Fileupload information disclosure 
> vulnerability
> 
> CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability
> 
> Severity: Moderate
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> Apache Commons Fileupload 1.3 to 1.3.1
> Apache Commons Fileupload 1.2 to 1.2.2
> The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be 
> affected.
> Apache Tomcat 9.x to 9.0.0M6
> Apache Tomcat 8.x to 8.0.35
> Apache Tomcat 7.x to 7.0.69
> Apache Tomcat 6.x
> Unsupported versions of Apache Tomcat, like 5.x may also be affected.
> Apache Struts 2.5.x, and previous versions, which are distributing Commons 
> FileUpload 1.3.1, or earlier versions.
> 
> Description:
> A malicious client can send file upload requests that cause the HTTP server 
> using the Apache Commons Fileupload library to become unresponsive, 
> preventing the server from servicing other requests.
> 
> This flaw is not exploitable beyond causing the code to loop expending CPU 
> resources.
> 
> 
> Mitigation:
> All users of Apache Commons Fileupload should upgrade to 1.3.2.
> All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, 
> respectively.
> All users of Apache Struts should replace the copy of Commons FileUpload 
> (which is distributed as part of Struts) with the fixed version 1.3.2.
> 
> Workaround:
> 
> System administrators should restrict the permitted maximum size of HTTP 
> request header values (For example, Apache Httpd provides a 
> LimitRequestFieldSize directive, and Apache Tomcat provides a 
> maxHttpHeaderSize attribute in their respective configuration files). A 
> maximum header value size of 2048 bytes would block all dangerous request.
> 
> Example:
> File upload requests contain a so-called boundary in the Content-Type header:
> 
> Content-Type: multipart/mixed;
>   boundary=gc0p4Jq0M2Yt08jU534c0p
> 
> The boundary may be chosen by the request sender. In the case of previous 
> versions of Apache Commons Fileupload the boundary becomes dangerous, if its 
> size is close to 4096 bytes.
> 
> Credit:
> TERASOLUNA Framework Development Team at the Software Engineering, Research 
> and Development Headquarter, for detecting this flaw, and reporting it to the 
> JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported 
> this problem to us.
> 
> References:
> https://commons.apache.org/proper/commons-fileupload/security.html
> 
> 
> 
> Note: Apache Tomcat 6.x and earlier are NOT affected.


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

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-21 19:08 GMT-04:00 Joleen Barker :

> Hello Daniel,
>
> Thank you for your replies.
>
> Yes, I have the Java build 1.7.0_71 installed and I have the Unlimited
> security package installed as the application from the vendor requires it.
>
> Ok, you say never to edit the catalina,sh. I can change it back. The
> settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1"
>
>
I believe this is not from the original version of the file. I have no
longer any Tomcat 7 installed to check this, however if I am checking my
Tomcat 8 catalina.sh, there is no SSL_VERSION environment variable
anywhere. If you are having an already modified catalina.sh, it will be
difficult to provide any meaningful guidance.


> Why is it set for only one version in the catalina.sh what is having this
> set to one version limiting us to?
>
>
It seems your catalina.sh has already been modified by someone else. This
doesn't look like the vanilla version of the catalina.sh file.


> Our connector has this set in it:
>
> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"
>
> Is this all we need to allow TLSv1.2 clients to come in and for Tomcat
> acting as a client to go out as TLSv1.2?


You didn't provide enough details about your connector, so, read this page:
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

I assume you are configuring a NIO or BIO connector, then sslProtocol="TLS"
is the only needed attribute to support TLSv1, TLSv1.1 and TLSv1.2. The
sslEnabledProtocols attribute is not necessary since it overalps with
sslProtocol attribute. Note if you do not specify this attribute it
defaults to TLS anyway.

If you read the documentation page above, you will see the sslProtocol
attribute is actually passing the value to Java 7. That's why there is no
need to temper with the catalina.sh to try to set this for Java before
hand. The proper way to configure Tomcat is to modify files in the conf
directory only. Playing with files in bin and lib is not a recommended
approach.


Daniel Savard

RE: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Chinoy Gupta]

What about 8.5.x branch? Is that also affected. And I am not able to see this 
update on Tomcat security page. Any reasons for that?

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, June 21, 2016 3:23 PM
To: users@tomcat.apache.org; d...@tomcat.apache.org; 
annou...@tomcat.apache.org; annou...@apache.org; secur...@tomcat.apache.org
Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability


 Original Message 
From: Jochen Wiedmann 
Sent: 21 June 2016 10:18:15 BST
To: priv...@commons.apache.org, "secur...@apache.org" , 
Tomcat Security List , annou...@apache.org, Apache 
Commons Developers List 
Subject: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability

CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

Severity: Moderate

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Commons Fileupload 1.3 to 1.3.1
Apache Commons Fileupload 1.2 to 1.2.2
The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be affected.
Apache Tomcat 9.x to 9.0.0M6
Apache Tomcat 8.x to 8.0.35
Apache Tomcat 7.x to 7.0.69
Apache Tomcat 6.x
Unsupported versions of Apache Tomcat, like 5.x may also be affected.
Apache Struts 2.5.x, and previous versions, which are distributing Commons 
FileUpload 1.3.1, or earlier versions.

Description:
A malicious client can send file upload requests that cause the HTTP server 
using the Apache Commons Fileupload library to become unresponsive, preventing 
the server from servicing other requests.

This flaw is not exploitable beyond causing the code to loop expending CPU 
resources.


Mitigation:
All users of Apache Commons Fileupload should upgrade to 1.3.2.
All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, 
respectively.
All users of Apache Struts should replace the copy of Commons FileUpload (which 
is distributed as part of Struts) with the fixed version 1.3.2.

Workaround:

System administrators should restrict the permitted maximum size of HTTP 
request header values (For example, Apache Httpd provides a 
LimitRequestFieldSize directive, and Apache Tomcat provides a maxHttpHeaderSize 
attribute in their respective configuration files). A maximum header value size 
of 2048 bytes would block all dangerous request.

Example:
File upload requests contain a so-called boundary in the Content-Type header:

Content-Type: multipart/mixed;
  boundary=gc0p4Jq0M2Yt08jU534c0p

The boundary may be chosen by the request sender. In the case of previous 
versions of Apache Commons Fileupload the boundary becomes dangerous, if its 
size is close to 4096 bytes.

Credit:
TERASOLUNA Framework Development Team at the Software Engineering, Research and 
Development Headquarter, for detecting this flaw, and reporting it to the 
JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported this 
problem to us.

References:
https://commons.apache.org/proper/commons-fileupload/security.html

--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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


Note: Apache Tomcat 6.x and earlier are NOT affected.



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

Re: Configuring Tomcat to support TLSv1.2

[Joleen Barker]

Hello Daniel,

Thank you for your replies.

Yes, I have the Java build 1.7.0_71 installed and I have the Unlimited
security package installed as the application from the vendor requires it.

Ok, you say never to edit the catalina,sh. I can change it back. The
settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1"

Why is it set for only one version in the catalina.sh what is having this
set to one version limiting us to?

Our connector has this set in it:

sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"

Is this all we need to allow TLSv1.2 clients to come in and for Tomcat
acting as a client to go out as TLSv1.2?

-Joleen



On Tue, Jun 21, 2016 at 5:53 PM, Daniel Savard 
wrote:

> 2016-06-21 14:12 GMT-04:00 Joleen Barker :
>
> > Hello Tomcat friends,
> >
> > I am looking for some understanding on what is happening in my
> environment
> > to make sure I am not missing anything in my settings.
> >
> > Basics:
> > 1) OS is GNU/Linux
> > 2) Java is JDK v1.7
> > 3) Tomcat 7
> >
> > First, this question has come up because we needed to allow TLSv1.2
> > connections to our application. I was looking for how someone would do
> this
> > and found 2 items. The first was to set the java https protocol to allow
> > TLSv1.2 because by default java 7 did not have this enabled. The other
> was
> > to set in Tomcat the SSL_VERSION parameter in catalina.sh. The site I
> read
> > to set the SSL_VERSION in the catalina.sh indicated the user had to do
> this
> > because his Tomcat would not talk to another Tomcat without this set.
> When
> > I went in and looked the SSL_VERSION was set to TLSv1, so I added 1.1 and
> > 1.2 with the following command:
> >
> > SSL_VERSION="-Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2"
> >
> > This change was easy to make but I learned a restart was needed for the
> > change it take place.
> >
>
> Never ever edit catalina.sh, this is bad practice and strongly discouraged.
> This file lies in the official binary distribution tree and should never
> been tempered with. There is other ways to configure properly Tomcat. If
> you change the connector properties, which is what you need to do to enable
> TLSv1.2, there is not turnaround for a restart.
>
>
> >
> > Prior to me finding the change to make above I was reading to make the
> > change for Java (not through Tomcat) I would run the command on the
> command
> > line:
> >
> > java -Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2
> >
> > no matter how I ran this the command would not be taken.
> >
> >
> Of course it would not affect another process than itself. This is totally
> useless to execute this command alone.
>
>
> > I did not think only making the change to the SSL_VERSION was enough but
> my
> > colleague decided to try connecting to the Tomcat server with an SSH
> client
> > and we received the notification that the TLSv1.2 connection was good.
> >
> > We finally were able to get a console working on the server and to our
> > surprise Java's console did not have any of the TLS versions enabled and
> > only the SSL versions.
> >
> > So I am confused here. It doesn't seem like Tomcat is relying on Java's
> > settings matching what is in the catalina.sh file and works without
> setting
> > these in the java console.
> >
> > Why is that?
> >
> > Thanks for improving my knowledge.
> >
> > -Joleen
> >
>
> You need to setup properly Tomcat othewise a setting somewhere may be
> override elsewhere. For your connector to support TLSv1.2, you need to edit
> the server.xml file and nothing else.
>
> The other thing you will need to do, is to make the necessary steps for
> your version of Java to support the TLSv1.2 if it doesn't support it yet.
> You didn't mention which version of Java 7 exactly you are using. Did you
> install the Unlimited JDK security package?
>
> Did you read the documentation on TLS/SSL?
>  http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
>
> -
> Daniel Savard
>

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-21 14:12 GMT-04:00 Joleen Barker :

> Hello Tomcat friends,
>
> I am looking for some understanding on what is happening in my environment
> to make sure I am not missing anything in my settings.
>
> Basics:
> 1) OS is GNU/Linux
> 2) Java is JDK v1.7
> 3) Tomcat 7
>
> First, this question has come up because we needed to allow TLSv1.2
> connections to our application. I was looking for how someone would do this
> and found 2 items. The first was to set the java https protocol to allow
> TLSv1.2 because by default java 7 did not have this enabled. The other was
> to set in Tomcat the SSL_VERSION parameter in catalina.sh. The site I read
> to set the SSL_VERSION in the catalina.sh indicated the user had to do this
> because his Tomcat would not talk to another Tomcat without this set. When
> I went in and looked the SSL_VERSION was set to TLSv1, so I added 1.1 and
> 1.2 with the following command:
>
> SSL_VERSION="-Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2"
>
> This change was easy to make but I learned a restart was needed for the
> change it take place.
>

Never ever edit catalina.sh, this is bad practice and strongly discouraged.
This file lies in the official binary distribution tree and should never
been tempered with. There is other ways to configure properly Tomcat. If
you change the connector properties, which is what you need to do to enable
TLSv1.2, there is not turnaround for a restart.


>
> Prior to me finding the change to make above I was reading to make the
> change for Java (not through Tomcat) I would run the command on the command
> line:
>
> java -Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2
>
> no matter how I ran this the command would not be taken.
>
>
Of course it would not affect another process than itself. This is totally
useless to execute this command alone.


> I did not think only making the change to the SSL_VERSION was enough but my
> colleague decided to try connecting to the Tomcat server with an SSH client
> and we received the notification that the TLSv1.2 connection was good.
>
> We finally were able to get a console working on the server and to our
> surprise Java's console did not have any of the TLS versions enabled and
> only the SSL versions.
>
> So I am confused here. It doesn't seem like Tomcat is relying on Java's
> settings matching what is in the catalina.sh file and works without setting
> these in the java console.
>
> Why is that?
>
> Thanks for improving my knowledge.
>
> -Joleen
>

You need to setup properly Tomcat othewise a setting somewhere may be
override elsewhere. For your connector to support TLSv1.2, you need to edit
the server.xml file and nothing else.

The other thing you will need to do, is to make the necessary steps for
your version of Java to support the TLSv1.2 if it doesn't support it yet.
You didn't mention which version of Java 7 exactly you are using. Did you
install the Unlimited JDK security package?

Did you read the documentation on TLS/SSL?
 http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

-
Daniel Savard

Re: How to force keystoreFile and truststoreFile to be absolute paths

[Mark Eggers]

Gerald,

On 6/21/2016 11:03 AM, Miller, Gerald wrote:
> I'm seeing errors from attempts to append uncorrected paths (e.g.,
> C:\out\) and corrected ones (e.g., ~/out/) onto some arbitrary path.
> Assuming a relative path in a case like this makes about as much
> sense as using relative branching in non-relocatable code.  I've
> wasted hours trying to get rid of errors in catalina.2016-06-21.log,
> and after I got fed up with the ridiculous assumption that the
> directory within Tomcat would also be accessed by the web services
> developed in an entirely separate directory hierarchy, that's when I
> decided to cut out the asinine duplication once and for all and
> define one central absolute path.  So much for that idea.  It's
> complaining tha
> /home/iaadmin/IA/apache-tomcat-8.0.24/~/out/servicetlsstore.jks isn't
> found!  (Yes, I also have to deal with the fact that the equivalence
> of servicetlsstore.jks and ServiceTlsStore.jks in Windows is used so
> carelessly that converting to Ubuntu is a nightmare.

I just played with this using Apache Tomcat 8.0.36, JRE 1.8.0_92, and
Windows 7 64 bit.

I followed the fine documentation here:

http://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

Here is my server.xml connector configuration:



(sorry for the word wrap).

Please note that I've moved and renamed the keystore file from the
defaults as generated by the keytool utility.

This works fine, tastes great.

Since I install Tomcat in the same place (for development) regardless of
platform, I then copied the keystore file and Connector configuration to
my 64 bit CentOS 6.8 system running the same version of Tomcat and Java.

This works fine, tastes great. OK, so I changed the ports on the CentOS
system since I already run a production Tomcat on that system with the
default ports. I also had to open up the firewall on that system.

Without seeing your Connector configuration, we have no idea what is
going on. Actually I do, but I'm not going to use Pid's crystal ball at
this junction (for reasons - see below).

We had to intuit your Tomcat version (please upgrade). We don't know
your Java version (please provide).

As an aside, we're all volunteers on this mailing list. We use Tomcat
because it's an awesome platform maintained by awesome, responsive, and
talented people. Vitriol, while certainly understandable after spending
hours working on a problem, is not the best way to win friends,
influence enemies, nor get volunteers to respond to questions.

. . . just my two cents
/mde/



signature.asc
Description: OpenPGP digital signature

RE: How to force keystoreFile and truststoreFile to be absolute paths

[Miller, Gerald]

Now that I think about it, this is probably a classpath issue.  Nice to have 
when it works, but a royal pain the rest of the time.

From: Miller, Gerald
Sent: Tuesday, June 21, 2016 2:04 PM
To: 'users@tomcat.apache.org' 
Subject: How to force keystoreFile and truststoreFile to be absolute paths

I'm seeing errors from attempts to append uncorrected paths (e.g., C:\out\) and 
corrected ones (e.g., ~/out/) onto some arbitrary path.  Assuming a relative 
path in a case like this makes about as much sense as using relative branching 
in non-relocatable code.  I've wasted hours trying to get rid of errors in 
catalina.2016-06-21.log, and after I got fed up with the ridiculous assumption 
that the directory within Tomcat would also be accessed by the web services 
developed in an entirely separate directory hierarchy, that's when I decided to 
cut out the asinine duplication once and for all and define one central 
absolute path.  So much for that idea.  It's complaining tha 
/home/iaadmin/IA/apache-tomcat-8.0.24/~/out/servicetlsstore.jks isn't found!  
(Yes, I also have to deal with the fact that the equivalence of 
servicetlsstore.jks and ServiceTlsStore.jks in Windows is used so carelessly 
that converting to Ubuntu is a nightmare.

Configuring Tomcat to support TLSv1.2

[Joleen Barker]

Hello Tomcat friends,

I am looking for some understanding on what is happening in my environment
to make sure I am not missing anything in my settings.

Basics:
1) OS is GNU/Linux
2) Java is JDK v1.7
3) Tomcat 7

First, this question has come up because we needed to allow TLSv1.2
connections to our application. I was looking for how someone would do this
and found 2 items. The first was to set the java https protocol to allow
TLSv1.2 because by default java 7 did not have this enabled. The other was
to set in Tomcat the SSL_VERSION parameter in catalina.sh. The site I read
to set the SSL_VERSION in the catalina.sh indicated the user had to do this
because his Tomcat would not talk to another Tomcat without this set. When
I went in and looked the SSL_VERSION was set to TLSv1, so I added 1.1 and
1.2 with the following command:

SSL_VERSION="-Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2"

This change was easy to make but I learned a restart was needed for the
change it take place.

Prior to me finding the change to make above I was reading to make the
change for Java (not through Tomcat) I would run the command on the command
line:

java -Dhttps.protocol=TLSv1,TLSv1.1,TLSv1.2

no matter how I ran this the command would not be taken.

I did not think only making the change to the SSL_VERSION was enough but my
colleague decided to try connecting to the Tomcat server with an SSH client
and we received the notification that the TLSv1.2 connection was good.

We finally were able to get a console working on the server and to our
surprise Java's console did not have any of the TLS versions enabled and
only the SSL versions.

So I am confused here. It doesn't seem like Tomcat is relying on Java's
settings matching what is in the catalina.sh file and works without setting
these in the java console.

Why is that?

Thanks for improving my knowledge.

-Joleen

How to force keystoreFile and truststoreFile to be absolute paths

[Miller, Gerald]

I'm seeing errors from attempts to append uncorrected paths (e.g., C:\out\) and 
corrected ones (e.g., ~/out/) onto some arbitrary path.  Assuming a relative 
path in a case like this makes about as much sense as using relative branching 
in non-relocatable code.  I've wasted hours trying to get rid of errors in 
catalina.2016-06-21.log, and after I got fed up with the ridiculous assumption 
that the directory within Tomcat would also be accessed by the web services 
developed in an entirely separate directory hierarchy, that's when I decided to 
cut out the asinine duplication once and for all and define one central 
absolute path.  So much for that idea.  It's complaining tha 
/home/iaadmin/IA/apache-tomcat-8.0.24/~/out/servicetlsstore.jks isn't found!  
(Yes, I also have to deal with the fact that the equivalence of 
servicetlsstore.jks and ServiceTlsStore.jks in Windows is used so carelessly 
that converting to Ubuntu is a nightmare.

This communication, along with its attachments, is considered confidential and 
proprietary to Vistronix.  It is intended only for the use of the person(s) 
named above.  Note that unauthorized disclosure or distribution of information 
not generally known to the public is strictly prohibited.  If you are not the 
intended recipient, please notify the sender immediately.

Re: Http2UpgradeHandler error

[Mark Thomas]

On 21/06/2016 14:52, Mark Thomas wrote:
> On 21/06/2016 14:43, Andrei Ivanov wrote:



>> 21-Jun-2016 13:38:41.122 FINE [https-openssl-apr-8443-exec-6]
>> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.fillReadBuffer
>> An APR general error was returned by the SSL read operation on
>> APR/native socket [1,852,286,144] with wrapper
>> [org.apache.tomcat.util.net.
>> AprEndpoint$AprSocketWrapper@1dfa0278:1852286144]. It will be treated
>> as EAGAIN and the socket returned to the poller.
>> 21-Jun-2016 13:38:41.125 SEVERE [https-openssl-apr-8443-exec-6]
>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
>> reading request, ignored
>>  java.lang.IllegalStateException
> 
> Bingo!
> 
> That proves the theory. Thanks for testing it so quickly. I should be
> able to put together a fix for this fairly quickly. I'll update this
> thread when I have the fix ready to test. If you're able to build Tomcat
> 8.5.x locally by then, great. If not, I can always provide a snapshot
> build for you to test with.

This is going to take a little longer than I thought. I need to dig
deeper into the tc-native / OpenSSL code.

Mark


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

Re: Memory problems caused by the messageBufferText CharBuffer in WSFrameBase.java

[Mark Thomas]

On 21/06/2016 15:52, Afaf Zahkya wrote:
> Hello,
> 
> I m using tomcat 8.0.21.
> 
> I want to send *up* to 4 MB of text messages through a websocket connection
> to my tomcat server. I set the MaxTextMessageBufferSize to 4 MB.Now as a
> result, every time I open a websocket  connection and I send a message , I
> can see that 4 MB are  being allocated in memory for the CharBuffer
> messageBufferText regardless of the size of the message I send . 99 % of my
> messages would be way smaller.The 4 MB  remain allocated in the
> messageBufferText CharBuffer even after the message is handled.  The
> connection can stay open up to 30 minutes in my case, and each  websocket
> connection is taking 4 MB of memory all of that time even if it's inactive
> which leads my server to eventually run out of memory even with inactive
> connections  . Note that I m using a Whole Message Handler.
> 
> in WSFrameBase.java  why not set the messageBufferText CharBuffer size to
> the payload length if it doesn't exceed the maxTextMessageBufferSize, and
> then clearing that buffer ( reducing its size) after the message is handled
> by the Handler, so that inactive connections don't take up memory. ( same
> for the binary) ?

GC churn.

> Any other / better suggestions on how to solve that problem ?

If you want scalability and the ability to handle messages that vary
significantly in size use a partial message handler.

Mark

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

Memory problems caused by the messageBufferText CharBuffer in WSFrameBase.java

[Afaf Zahkya]

Hello,

I m using tomcat 8.0.21.

I want to send *up* to 4 MB of text messages through a websocket connection
to my tomcat server. I set the MaxTextMessageBufferSize to 4 MB.Now as a
result, every time I open a websocket  connection and I send a message , I
can see that 4 MB are  being allocated in memory for the CharBuffer
messageBufferText regardless of the size of the message I send . 99 % of my
messages would be way smaller.The 4 MB  remain allocated in the
messageBufferText CharBuffer even after the message is handled.  The
connection can stay open up to 30 minutes in my case, and each  websocket
connection is taking 4 MB of memory all of that time even if it's inactive
which leads my server to eventually run out of memory even with inactive
connections  . Note that I m using a Whole Message Handler.

in WSFrameBase.java  why not set the messageBufferText CharBuffer size to
the payload length if it doesn't exceed the maxTextMessageBufferSize, and
then clearing that buffer ( reducing its size) after the message is handled
by the Handler, so that inactive connections don't take up memory. ( same
for the binary) ?

Any other / better suggestions on how to solve that problem ?

Thanks.

Re: Http2UpgradeHandler error

[Andrei Ivanov]

On Tue, Jun 21, 2016 at 4:52 PM, Mark Thomas  wrote:
> On 21/06/2016 14:43, Andrei Ivanov wrote:
>> On Tue, Jun 21, 2016 at 4:01 PM, Mark Thomas  wrote:
>>> On 21/06/2016 13:43, Mark Thomas wrote:
>>>
 I'll take a look at the code and see if I can figure out how this is
 happening. Are you able to build 8.5.x from source to test any changes I
 might make?
>> If all it needs is a Java tools, I can build.
>
> Tomcat is a lot easier to build that it used to be. You need Ant, svn
> client and an internet connection. For details see:
> http://tomcat.apache.org/tomcat-8.5-doc/building.html
>
> If you prefer (although there are no explicit instructions) you can
> replace svn with git and use the mirror at:
> https://github.com/apache/tomcat85
>
>> Btw, tcnative is 1.2.7, the one that came in
>> apache-tomcat-8.5.3-windows-x64.zip.
>
> I guessed you were using that version but wanted to be sure.
>
>>> I have a theory which can be proved/disproved with some extra logging.
>
> 
>
>> Restarted Tomcat and Firefox.
>> The following are just from loading the login form and its
>> dependencies (css/js).
>
> 
>
>> 21-Jun-2016 13:38:41.122 FINE [https-openssl-apr-8443-exec-6]
>> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.fillReadBuffer
>> An APR general error was returned by the SSL read operation on
>> APR/native socket [1,852,286,144] with wrapper
>> [org.apache.tomcat.util.net.
>> AprEndpoint$AprSocketWrapper@1dfa0278:1852286144]. It will be treated
>> as EAGAIN and the socket returned to the poller.
>> 21-Jun-2016 13:38:41.125 SEVERE [https-openssl-apr-8443-exec-6]
>> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
>> reading request, ignored
>>  java.lang.IllegalStateException
>
> Bingo!
>
> That proves the theory. Thanks for testing it so quickly. I should be
> able to put together a fix for this fairly quickly. I'll update this
> thread when I have the fix ready to test. If you're able to build Tomcat
> 8.5.x locally by then, great. If not, I can always provide a snapshot
> build for you to test with.
>
> Mark

One more, for the fun :-)
Not sure if it's related:

21-Jun-2016 13:43:52.248 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,302,560] for event(s) [1]
21-Jun-2016 13:43:52.250 FINE [https-openssl-apr-8443-exec-3]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,302,560], timeout [-1], flags [1]
21-Jun-2016 13:43:52.250 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,302,560]
21-Jun-2016 13:43:52.251 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,302,560] from poller
21-Jun-2016 13:43:52.254 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,302,560] for event(s) [1]
21-Jun-2016 13:43:52.255 FINE [https-openssl-apr-8443-exec-5]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,302,560], timeout [-1], flags [1]
21-Jun-2016 13:43:52.256 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,302,560]
21-Jun-2016 13:43:52.259 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,302,560] from poller
21-Jun-2016 13:43:52.275 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,302,560] for event(s) [1]
21-Jun-2016 13:43:52.291 FINE [https-openssl-apr-8443-exec-6]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,302,560], timeout [-1], flags [1]
21-Jun-2016 13:43:52.314 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,302,560]
21-Jun-2016 13:43:52.320 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,302,560] from poller
21-Jun-2016 13:43:52.325 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,302,560] for event(s) [1]
21-Jun-2016 13:43:52.333 FINE [https-openssl-apr-8443-exec-10]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,302,560], timeout [-1], flags [1]
21-Jun-2016 13:43:52.338 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,302,560]
21-Jun-2016 13:43:52.342 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,302,560] from poller
21-Jun-2016 13:43:52.427 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,302,560] for event(s) [1]
21-Jun-2016 13:43:52.430 FINE [https-openssl-apr-8443-exe

Re: Http2UpgradeHandler error

[Mark Thomas]

On 21/06/2016 14:43, Andrei Ivanov wrote:
> On Tue, Jun 21, 2016 at 4:01 PM, Mark Thomas  wrote:
>> On 21/06/2016 13:43, Mark Thomas wrote:
>>
>>> I'll take a look at the code and see if I can figure out how this is
>>> happening. Are you able to build 8.5.x from source to test any changes I
>>> might make?
> If all it needs is a Java tools, I can build.

Tomcat is a lot easier to build that it used to be. You need Ant, svn
client and an internet connection. For details see:
http://tomcat.apache.org/tomcat-8.5-doc/building.html

If you prefer (although there are no explicit instructions) you can
replace svn with git and use the mirror at:
https://github.com/apache/tomcat85

> Btw, tcnative is 1.2.7, the one that came in
> apache-tomcat-8.5.3-windows-x64.zip.

I guessed you were using that version but wanted to be sure.

>> I have a theory which can be proved/disproved with some extra logging.



> Restarted Tomcat and Firefox.
> The following are just from loading the login form and its
> dependencies (css/js).



> 21-Jun-2016 13:38:41.122 FINE [https-openssl-apr-8443-exec-6]
> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.fillReadBuffer
> An APR general error was returned by the SSL read operation on
> APR/native socket [1,852,286,144] with wrapper
> [org.apache.tomcat.util.net.
> AprEndpoint$AprSocketWrapper@1dfa0278:1852286144]. It will be treated
> as EAGAIN and the socket returned to the poller.
> 21-Jun-2016 13:38:41.125 SEVERE [https-openssl-apr-8443-exec-6]
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
> reading request, ignored
>  java.lang.IllegalStateException

Bingo!

That proves the theory. Thanks for testing it so quickly. I should be
able to put together a fix for this fairly quickly. I'll update this
thread when I have the fix ready to test. If you're able to build Tomcat
8.5.x locally by then, great. If not, I can always provide a snapshot
build for you to test with.

Mark

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

Re: Http2UpgradeHandler error

[Andrei Ivanov]

On Tue, Jun 21, 2016 at 4:01 PM, Mark Thomas  wrote:
> On 21/06/2016 13:43, Mark Thomas wrote:
>
>> I'll take a look at the code and see if I can figure out how this is
>> happening. Are you able to build 8.5.x from source to test any changes I
>> might make?
If all it needs is a Java tools, I can build.

Btw, tcnative is 1.2.7, the one that came in
apache-tomcat-8.5.3-windows-x64.zip.

>
> I have a theory which can be proved/disproved with some extra logging.
>
> First, please add the following line to logging.properties and then restart.
> org.apache.tomcat.util.net.AprEndpoint.level = FINE
>
> Re-create the problem and then look for the following in the logs. Where
> you see {n} in the message below, it will be replaced by some value.
>
> An APR general error was returned by the SSL read operation on
> APR/native socket [{0}] with wrapper [{1}]. It will be treated as EAGAIN
> and the socket returned to the poller.
>
>
> Do you see messages like this in the logs?

Restarted Tomcat and Firefox.
The following are just from loading the login form and its
dependencies (css/js).

21-Jun-2016 13:38:38.276 FINE [https-openssl-apr-8443-Acceptor-0]
org.apache.tomcat.util.net.AprEndpoint.processSocketWithOptions socket
[1,852,261,520]
21-Jun-2016 13:38:38.302 FINE [https-openssl-apr-8443-exec-1]
org.apache.tomcat.util.net.AprEndpoint.setSocketOptions Negotiated
[h2] protocol using ALPN
21-Jun-2016 13:38:38.303 FINE [https-openssl-apr-8443-exec-1]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,261,520], timeout [60,000], flags [1]
21-Jun-2016 13:38:38.303 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,261,520]
21-Jun-2016 13:38:38.304 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,261,520] from poller
21-Jun-2016 13:38:39.272 FINE [https-openssl-apr-8443-Acceptor-0]
org.apache.tomcat.util.net.AprEndpoint.processSocketWithOptions socket
[1,852,286,144]
21-Jun-2016 13:38:39.287 FINE [https-openssl-apr-8443-exec-2]
org.apache.tomcat.util.net.AprEndpoint.setSocketOptions Negotiated
[h2] protocol using ALPN
21-Jun-2016 13:38:39.287 FINE [https-openssl-apr-8443-exec-2]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,286,144], timeout [60,000], flags [1]
21-Jun-2016 13:38:39.289 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,286,144]
21-Jun-2016 13:38:39.289 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,286,144] from poller
21-Jun-2016 13:38:40.020 FINE [https-openssl-apr-8443-Acceptor-0]
org.apache.tomcat.util.net.AprEndpoint.processSocketWithOptions socket
[1,852,294,352]
21-Jun-2016 13:38:40.041 FINE [https-openssl-apr-8443-exec-3]
org.apache.tomcat.util.net.AprEndpoint.setSocketOptions Negotiated
[h2] protocol using ALPN
21-Jun-2016 13:38:40.042 FINE [https-openssl-apr-8443-exec-3]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,294,352], timeout [60,000], flags [1]
21-Jun-2016 13:38:40.043 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,294,352]
21-Jun-2016 13:38:40.043 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,294,352] from poller
21-Jun-2016 13:38:40.549 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,261,520] for event(s) [1]
21-Jun-2016 13:38:40.649 FINE [https-openssl-apr-8443-exec-4]
org.apache.tomcat.util.net.AprEndpoint$Poller.add Add to addList
socket [1,852,261,520], timeout [-1], flags [1]
21-Jun-2016 13:38:40.649 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Add to poller socket
[1,852,261,520]
21-Jun-2016 13:38:40.650 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [1,852,261,520] from poller
21-Jun-2016 13:38:41.119 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.run Processing socket
[1,852,286,144] for event(s) [1]
21-Jun-2016 13:38:41.122 FINE [https-openssl-apr-8443-exec-6]
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.fillReadBuffer
An APR general error was returned by the SSL read operation on
APR/native socket [1,852,286,144] with wrapper
[org.apache.tomcat.util.net.
AprEndpoint$AprSocketWrapper@1dfa0278:1852286144]. It will be treated
as EAGAIN and the socket returned to the poller.
21-Jun-2016 13:38:41.125 SEVERE [https-openssl-apr-8443-exec-6]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
reading request, ignored
 java.lang.IllegalStateException
at 
org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeH

Tomcat 7 performance tuning take full advantage of hardware

[tanming1...@163.com]

Hi,
I had done some stress tests on Apache Tomcat/7.0.47 and found that tomcat 
didn't taken full advantage of hardware resources.I had used Apache Benchmark 
tool(ab) to do benckmark,and then monitor the jvm instance of tomcat via 
jvisualvm.In the benchmark,I just test the response time of request a jsp.
The CPU usage is not high,about 20%,even when the concurrent requests increased.
So how can I to do some performance tuning to make tomcat 7 take full advantage
of hardware resources?

The test enviroment:
andy@test80:~$ uname -a
Linux test80 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 
2013 x86_64 x86_64 x86_64 GNU/Linux

andy@test80:~$ lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):16
On-line CPU(s) list:   0-15
Thread(s) per core:2
Core(s) per socket:4
Socket(s): 2
NUMA node(s):  2
Vendor ID: GenuineIntel
CPU family:6
Model: 44
Stepping:  2
CPU MHz:   1596.000
BogoMIPS:  4800.19
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  12288K
NUMA node0 CPU(s): 0-3,8-11
NUMA node1 CPU(s): 4-7,12-15

andy@test80:~$ java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

andy@test80:~$ vmstat -s
 82481856 K total memory
 81243296 K used memory
 51191508 K active memory
 27359516 K inactive memory
  1238560 K free memory
   454584 K buffer memory
 46734728 K swap cache
 33542140 K total swap
11836 K used swap
 33530304 K free swap
   3259773994 non-nice user cpu ticks
   172256 nice user cpu ticks
137055078 system cpu ticks
  28564934681 idle cpu ticks
 17736327 IO-wait cpu ticks
 2324 IRQ cpu ticks
  7998142 softirq cpu ticks
0 stolen cpu ticks
 39740382 pages paged in
  71293969233 pages paged out
14159 pages swapped in
73239 pages swapped out
   2381549755 interrupts
   1089236704 CPU context switches
   1446432805 boot time
  2733476 forks

catalina.sh:
CATALINA_OPTS='-Xms2g -Xmx2g -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K 
-XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled 
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 
-XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M 
-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 
-Dcom.sun.management.jmxremote  -Djava.rmi.server.hostname=10.241.14.80 
-Dcom.sun.management.jmxremote.port=60108 -Djava.net.preferIPv4Stack=true 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false'

server.xml:

  
  
   

   
  
   

  

  





tanming1...@163.com

Re: Http2UpgradeHandler error

[Mark Thomas]

On 21/06/2016 13:43, Mark Thomas wrote:

> I'll take a look at the code and see if I can figure out how this is
> happening. Are you able to build 8.5.x from source to test any changes I
> might make?

I have a theory which can be proved/disproved with some extra logging.

First, please add the following line to logging.properties and then restart.
org.apache.tomcat.util.net.AprEndpoint.level = FINE

Re-create the problem and then look for the following in the logs. Where
you see {n} in the message below, it will be replaced by some value.

An APR general error was returned by the SSL read operation on
APR/native socket [{0}] with wrapper [{1}]. It will be treated as EAGAIN
and the socket returned to the poller.


Do you see messages like this in the logs?

Mark

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

Re: Http2UpgradeHandler error

[Mark Thomas]

On 21/06/2016 12:31, Andrei Ivanov wrote:
> Hello,
> Trying to upgrade from 8.0.35 to 8.5.3 (on Win 7 and JDK
> 1.8.0_92-b14), I ran into this error, using Firefox 47:
> 
> 21-Jun-2016 11:13:01.689 SEVERE [https-openssl-apr-8443-exec-5]
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
> reading request, ignored
>  java.lang.IllegalStateException
> at 
> org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1087)
> at 
> org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1063)
> at 
> org.apache.coyote.http2.Http2Parser.readConnectionPreface(Http2Parser.java:519)
> at 
> org.apache.coyote.http2.Http2UpgradeHandler.init(Http2UpgradeHandler.java:225)
> at 
> org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:273)
> at 
> org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
> at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
> at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
> at 
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2226)
> at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)

That indicates a blocking read read 0 bytes which should never happen -
which is why you see the ISE.

Which version of tc-native are you using?



> Did I configure something wrong?

I don't see anything.

> It's working fine with Tomcat 8.0, but I guess that's just using HTTP 1.1

Correct.

I'll take a look at the code and see if I can figure out how this is
happening. Are you able to build 8.5.x from source to test any changes I
might make?

Mark

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

Re: Http2UpgradeHandler error

[Rémy Maucherat]

2016-06-21 13:31 GMT+02:00 Andrei Ivanov :

> Hello,
> Trying to upgrade from 8.0.35 to 8.5.3 (on Win 7 and JDK
> 1.8.0_92-b14), I ran into this error, using Firefox 47:
>
> Try not using the APR connector, for starters, your platform isn't the
best for it IMO.

Rémy

Http2UpgradeHandler error

[Andrei Ivanov]

Hello,
Trying to upgrade from 8.0.35 to 8.5.3 (on Win 7 and JDK
1.8.0_92-b14), I ran into this error, using Firefox 47:

21-Jun-2016 11:13:01.689 SEVERE [https-openssl-apr-8443-exec-5]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
reading request, ignored
 java.lang.IllegalStateException
at 
org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1087)
at 
org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1063)
at 
org.apache.coyote.http2.Http2Parser.readConnectionPreface(Http2Parser.java:519)
at 
org.apache.coyote.http2.Http2UpgradeHandler.init(Http2UpgradeHandler.java:225)
at 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:273)
at 
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
at 
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2226)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)


This happened after the login formed was displayed and submitted, on
the 2nd screen of the app, on successful login.

The page was displayed as if the stylesheets were not loaded, just the
plain html rendered.

Clicking around I've just triggered this error:

21-Jun-2016 11:22:34.118 SEVERE [https-openssl-apr-8443-exec-5]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error
reading request, ignored
 java.lang.ArrayIndexOutOfBoundsException: -3
at 
org.apache.coyote.http2.HpackDecoder.handleIndex(HpackDecoder.java:248)
at org.apache.coyote.http2.HpackDecoder.decode(HpackDecoder.java:99)
at 
org.apache.coyote.http2.Http2Parser.readHeaderBlock(Http2Parser.java:404)
at 
org.apache.coyote.http2.Http2Parser.readHeadersFrame(Http2Parser.java:246)
at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:96)
at org.apache.coyote.http2.Http2Parser.readFrame(Http2Parser.java:68)
at 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:291)
at 
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:54)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:53)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
at 
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2226)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

This one seems to be when loading
https://test:8443/enss/javax.faces.resource/angel/css/angel.css.jsf
Firebug shows a lot of aborted requests to other resources like these,
ending in css.jsf or js.jsf (loaded through the JSF filter from
Mojarra 2.2.13, with Primefaces 6.0).


Config details with modifications from the default follow:

conf/server.xml













conf/context.xml





Did I configure something wrong?

It's working fine with Tomcat 8.0, but I guess that's just using HTTP 1.1

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

Re: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Jochen Wiedmann]

Thanks for forwarding. I hope, that everything is alright with the announcement?


On Tue, Jun 21, 2016 at 11:53 AM, Mark Thomas  wrote:
>
>  Original Message 
> From: Jochen Wiedmann 
> Sent: 21 June 2016 10:18:15 BST
> To: priv...@commons.apache.org, "secur...@apache.org" , 
> Tomcat Security List , annou...@apache.org, 
> Apache Commons Developers List 
> Subject: CVE-2016-3092: Apache Commons Fileupload information disclosure 
> vulnerability
>
> CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability
>
> Severity: Moderate
>
> Vendor:
> The Apache Software Foundation
>
> Versions Affected:
> Apache Commons Fileupload 1.3 to 1.3.1
> Apache Commons Fileupload 1.2 to 1.2.2
> The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be 
> affected.
> Apache Tomcat 9.x to 9.0.0M6
> Apache Tomcat 8.x to 8.0.35
> Apache Tomcat 7.x to 7.0.69
> Apache Tomcat 6.x
> Unsupported versions of Apache Tomcat, like 5.x may also be affected.
> Apache Struts 2.5.x, and previous versions, which are distributing
> Commons FileUpload 1.3.1, or earlier versions.
>
> Description:
> A malicious client can send file upload requests that cause the HTTP server
> using the Apache Commons Fileupload library to become unresponsive, preventing
> the server from servicing other requests.
>
> This flaw is not exploitable beyond causing the code to loop expending
> CPU resources.
>
>
> Mitigation:
> All users of Apache Commons Fileupload should upgrade to 1.3.2.
> All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or
> 7.0.70, respectively.
> All users of Apache Struts should replace the copy of Commons
> FileUpload (which is distributed as part of Struts) with the fixed
> version 1.3.2.
>
> Workaround:
>
> System administrators should restrict the permitted maximum size of HTTP 
> request
> header values (For example, Apache Httpd provides a
> LimitRequestFieldSize directive,
> and Apache Tomcat provides a maxHttpHeaderSize attribute in their respective
> configuration files). A maximum header value size of 2048 bytes would block 
> all
> dangerous request.
>
> Example:
> File upload requests contain a so-called boundary in the Content-Type header:
>
> Content-Type: multipart/mixed;
>   boundary=gc0p4Jq0M2Yt08jU534c0p
>
> The boundary may be chosen by the request sender. In the case of
> previous versions
> of Apache Commons Fileupload the boundary becomes dangerous, if its
> size is close
> to 4096 bytes.
>
> Credit:
> TERASOLUNA Framework Development Team at the Software Engineering,
> Research and Development Headquarter, for detecting this flaw, and reporting
> it to the JPCERT/CC,
> Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported this
> problem to us.
>
> References:
> https://commons.apache.org/proper/commons-fileupload/security.html
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> Note: Apache Tomcat 6.x and earlier are NOT affected.
>
>



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: mod JK ho to rout all content to tomcat except for a few static folders

[Campbell, Lance]

I am so sorry.  You are correct.  

Lance

Sent from my iPhone

> On Jun 20, 2016, at 12:13 PM, Rainer Jung  wrote:
> 
>> Am 20.06.2016 um 18:32 schrieb Campbell, Lance:
>> Neither of these options will work for me:
>> 1) no-jk is only supported for: "Starting with mod_jk 1.2.6 for Apache 2.x 
>> and 1.2.19 for Apache 1.3"
> 
> So? You wrote your versions are
> 
> Apache 2.2.15
> mod_jk  1.2.41
> 
> and isn't 1.2.41 >= 1.2.6? So the no-jk feature is supported. Why do you 
> think it is not?
> 
>> 2) The urls that get sent to Tomcat are unkown.  This is a dynamic content 
>> driven site.
> 
> 1) and 2) both work once you know which URIs you want to exclude form 
> forwarding. You wrote "except for three directories that contain static 
> content" so I guess you are able to describe those URIs to exclude e.g. by 
> one to three URI prefixes?
> 
> The examples Anthony gave are correct, so if your URIs to exclude start e.g. 
> with /img/, /css/ and /static/, you could either
> 
> JkUnMount /img/* *
> JkUnMount /css/* *
> JkUnMount /static/* *
> 
> or
> 
> SetEnvIf Request_URI "/img/*" no-jk
> SetEnvIf Request_URI "/css/*" no-jk
> SetEnvIf Request_URI "/static/*" no-jk
> 
> I slightly prefer the JkUnMount way, because it is a bit easier to 
> read/understand if you put it close to your JkMount in the config file. The 
> second way is convenient if the exclusion rules get more complex, because you 
> can do tricky stuff with environment variables (no-jk).
> 
> Regards,
> 
> Rainer
> 
>> -Original Message-
>> From: Anthony Biacco [mailto:abia...@handll.com]
>> Sent: Monday, June 20, 2016 10:29 AM
>> To: Tomcat Users List 
>> Subject: Re: mod JK ho to rout all content to tomcat except for a few static 
>> folders
>> 
>>> On Mon, Jun 20, 2016 at 9:14 AM, Campbell, Lance  wrote:
>>> 
>>> These are the versions of software I have to use.  I cannot install
>>> other
>>> software:
>>> 
>>> 
>>> 
>>> Apache 2.2.15
>>> 
>>> mod_jk  1.2.41
>>> 
>>> Tomcat 8.0.36
>>> 
>>> 
>>> 
>>> Issue:
>>> 
>>> We are looking at having a domain where all content will get routed to
>>> Tomcat 8 except for three directories that contain static content.
>>> These three directories will be served up by Apache.  Based on the
>>> above versions how can I tell Apache to handle just these three
>>> directories and then send all other content requests to Tomcat?
>> should be able to use either of:
>> 
>> JkUnMount /URI/* worker
>> 
>> SetEnvIf Request_URI "/URI/*" no-jk
>> 
>> 
>> -Tony
> 
> -
> 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: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Mark Thomas]

 Original Message 
From: Jochen Wiedmann 
Sent: 21 June 2016 10:18:15 BST
To: priv...@commons.apache.org, "secur...@apache.org" , 
Tomcat Security List , annou...@apache.org, Apache 
Commons Developers List 
Subject: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability

CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

Severity: Moderate

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Commons Fileupload 1.3 to 1.3.1
Apache Commons Fileupload 1.2 to 1.2.2
The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be affected.
Apache Tomcat 9.x to 9.0.0M6
Apache Tomcat 8.x to 8.0.35
Apache Tomcat 7.x to 7.0.69
Apache Tomcat 6.x
Unsupported versions of Apache Tomcat, like 5.x may also be affected.
Apache Struts 2.5.x, and previous versions, which are distributing
Commons FileUpload 1.3.1, or earlier versions.

Description:
A malicious client can send file upload requests that cause the HTTP server
using the Apache Commons Fileupload library to become unresponsive, preventing
the server from servicing other requests.

This flaw is not exploitable beyond causing the code to loop expending
CPU resources.


Mitigation:
All users of Apache Commons Fileupload should upgrade to 1.3.2.
All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or
7.0.70, respectively.
All users of Apache Struts should replace the copy of Commons
FileUpload (which is distributed as part of Struts) with the fixed
version 1.3.2.

Workaround:

System administrators should restrict the permitted maximum size of HTTP request
header values (For example, Apache Httpd provides a
LimitRequestFieldSize directive,
and Apache Tomcat provides a maxHttpHeaderSize attribute in their respective
configuration files). A maximum header value size of 2048 bytes would block all
dangerous request.

Example:
File upload requests contain a so-called boundary in the Content-Type header:

Content-Type: multipart/mixed;
  boundary=gc0p4Jq0M2Yt08jU534c0p

The boundary may be chosen by the request sender. In the case of
previous versions
of Apache Commons Fileupload the boundary becomes dangerous, if its
size is close
to 4096 bytes.

Credit:
TERASOLUNA Framework Development Team at the Software Engineering,
Research and Development Headquarter, for detecting this flaw, and reporting
it to the JPCERT/CC,
Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported this
problem to us.

References:
https://commons.apache.org/proper/commons-fileupload/security.html

-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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


Note: Apache Tomcat 6.x and earlier are NOT affected.



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

Incorrect request processing times in server status

[Mohit Chawla]

Hello list,

On a new tomcat installation I am noticing extremely high values for
request processing times being reported by the server status page. Even if
I restart tomcat and start sending requests again, the request processing
time again shows extremely high values for a few requests. I have tested
this with tomcat 7.0.26 and 7.0.52 on Ubuntu 14.04.

For example,

K  1466499689496 ms  ?  ?  10.128.3.236  10.128.3.236  ?  ?

In reality that request came into the system only a few milliseconds ago.

Can someone suggest what could be done here ?

Thanks,

Mohit

[ANN] Apache Tomcat 7.0.70 released

[Violeta Georgieva]

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

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

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


- Update the packaged version of the Tomcat Native Library to 1.2.7 to pick
  up the Windows binaries that are based on OpenSSL 1.0.2h and APR 1.5.2

- Remove native code (Windows Service Wrapper, APR/native connector)
  support for Windows Itanium.


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

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

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

Enjoy

The Apache Tomcat team

Re: session-timeout and maxInactiveInterval

[Mark Thomas]

On 21/06/2016 03:54, mw...@loftware.com wrote:
> 
> 
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Monday, June 20, 2016 11:32 AM
>> To: Tomcat Users List 
>> Subject: Re: session-timeout and maxInactiveInterval
>>
>> On 20/06/2016 16:00, mw...@loftware.com wrote:
>>> We are running 7.0.69 and Java 1.8.0_91.
>>>
>>> We ran into an incident at a customer where the customer had set
>>> session-timeout to 0 – which according to the servlet 3.0 spec, the
>>> session should never time out.  However, the customer was basically
>>> seeing the session timeout immediately.  When we changed
>>> session-timeout to a larger number (30) and restarted, the problem
>> immediately went away.
>>
>> Set how?
>>
>> I've looked through the code and everything looks OK.
>>
>> What is the simplest possible test case that demonstrates this with a clean
>> Tomcat install? (I'm thinking of something along the lines of changing the
>> timeout in the web.xml for the examples app and adding a JSP that
>> demonstrates the problem.)
>>
>> Mark
>>
> 
> +1
> Touche, barking up the wrong tree here.  Turns out to be an issue with 
> Granite, for some reason using the Tomcat parameters, but using them wrong 
> (fortunately we were able to work around the bug).
> 
> Sorry to waste your time.

Not at all. The question and answer is in the archives and could well
proof to provide a useful clue to someone facing a similar issue in the
future.

Mark

> 
> 
>>>
>>>
>>>
>>> It looks like setMaxInactiveInterval _/may/_ be using the value of
>>> session-timeout if it is not explicitly set, and if so, is not
>>> handling the session-timeout = 0 case specially.  It also looks like
>>> maxInactiveInterval is really controlling the lifetime of the session.
>>>  But I have also not been through the Tomcat code often, so I am not
>>> 100% sure I’m looking in the right spot.
>>>
>>>
>>>
>>> Has anyone seen this issue before?  Am I misinterpreting something?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>>
>>> The Top 5 Trends in Enterprise Labeling for 2016
>>> >> tml>
>>> --
>>> --
>>> 
>>>
>>> 249 Corporate Drive, Portsmouth, NH 03801
>>> Website: loftware.com  Connect with us:
>>> Twitter  | LinkedIn
>>>  | Google+
>>> 
>>> What is Enterprise Labeling?
>>>  Why it's
>>> essential for global businesses.
>>> Visit the Enterprise Labeling Blog for all of your industry news
>>>
>>
>>
>> -
>> 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