Re: getRequestURI() in relation to Connector.URIEncoding
On 17.02.2013 23:00, Mike Wilson wrote: Mark Thomas wrote: On 17/02/2013 16:54, André Warnier wrote: Mike Wilson wrote: snip/ Example 2: path /ä in binary Unicode GET /.. [0xC3,0xA4] request.getRequestURI() - /.. [0xC3,0xA4] request.getPathInfo() - /ä snip/ I believe that your example #2 above is simply illegal. One is not supposed to send such bytes in a URL without URL-encoding them. That's per the HTTP RFC itself : RFC 2616 3.2.2 3.2.3 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2) - RFC 2396 part 2. URI Characters and Escape Sequences (http://www.ietf.org/rfc/rfc2396.txt) And I believe that the fact that Tomcat is returning the correct translation in the corresponding request.getPathInfo() is purely accidental, and it could be argued that this is a bug in Tomcat : the request should probably have been rejected, because the requested URL was invalid. +1. It is on my list of things to do to check why this wasn't rejected with a 400 response. Mark Explicitly making this invalid is probably fine, although it might be looked upon as breaking working systems. Note that we have apparently been running with a setup sending these binary URLs for years, where mod_jk is the source of the invalid URLs. Ie, the browser sends a nice URL-encoded URL which is decoded by mod_jk before sending to Tomcat. So might be appropriate to hold off this change to a release where back compat isn't crucial? Now you throw in another component in the mix. mod_jk is not using HTTP as a protocol to talk to Tomcat and the protocol decoding is not identical with the HTTP one. Before saying such binary URLs are invalid someone would need to check the AJP protocol and the protocol parser in Tomcat about this. I doubt that such URLs are invalid - not based on any code inspection, but simply on the fact that mod_jk decoded percent encoding before forwarding for a long time (5.5 years, from Oct. 2001 to May 2007, version 1.2.0 to 1.2.22). Since version 1.2.24 any bytes in the URI expected to be unsafe are percent encoded before forwarding. At least that's the default. If you use an non-default ForwardURIxxx option via JkOptions, then that behavior depend on the chosen setting. Nevertheless it makes sense to check and clarify. Which mod_jk version and JkOptions are you using? Can you give a real example of the original URI, the URI that mod_jk forwards (JkLogLevel debug will show it, but that's not meant for production) and how that forwarded URL should look like instead? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getRequestURI() in relation to Connector.URIEncoding
On 17.02.2013 23:57, André Warnier wrote: Mike Wilson wrote: Mark Thomas wrote: On 17/02/2013 16:54, André Warnier wrote: Mike Wilson wrote: snip/ Example 2: path /ä in binary Unicode GET /.. [0xC3,0xA4] request.getRequestURI() - /.. [0xC3,0xA4] request.getPathInfo() - /ä snip/ I believe that your example #2 above is simply illegal. One is not supposed to send such bytes in a URL without URL-encoding them. That's per the HTTP RFC itself : RFC 2616 3.2.2 3.2.3 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2) - RFC 2396 part 2. URI Characters and Escape Sequences (http://www.ietf.org/rfc/rfc2396.txt) And I believe that the fact that Tomcat is returning the correct translation in the corresponding request.getPathInfo() is purely accidental, and it could be argued that this is a bug in Tomcat : the request should probably have been rejected, because the requested URL was invalid. +1. It is on my list of things to do to check why this wasn't rejected with a 400 response. Mark Explicitly making this invalid is probably fine, although it might be looked upon as breaking working systems. Note that we have apparently been running with a setup sending these binary URLs for years, where mod_jk is the source of the invalid URLs. Ie, the browser sends a nice URL-encoded URL which is decoded by mod_jk before sending to Tomcat. So might be appropriate to hold off this change to a release where back compat isn't crucial? Mmmm. It stretches the imagination a bit to imagine that mod_jk by default takes a valid URL and makes it invalid before forwarding it to Tomcat. The web server will first decode the URL to be able to do whatever it is configured to do. When mod_jk needs to forward the request, there's a decision needed: - using the original undecoded URL: that seems to be safe, but means it will be incompatible with any URL rewritng configured in Apache, e.g. using mod_rewrite - using the final decoded and maybe rewritten URL: this is insecure, because it can be used for double-encoding attacks. - using the final decoded and maybe rewritten URL, but re-encoding any bytes that doe not seem to be safe: that's what mod_jk currently does by default. As far as I recall, there are several options in mod_jk (ForwardURI* family) which allow to do things there, some of them unsafe. Right, see above. The default should be safe. So it raises the question : are you doing something until now which is considered as unsafe, and therefore are having that problem ? (And a linked question is whether by changing this mod_jk option you could restore operability with a Tomcat rejecting the invalid URLs). Otherwise, my feeling is that it will cost you quite a number of beers to stop Mark from fixing what could potentially be a security issue, now that he's sniffed it. :) Not sure whether Mark's sniffing changes based on the fact that we are now talking about the AJP part of the connectors. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getRequestURI() in relation to Connector.URIEncoding
On 18/02/2013 09:54, Rainer Jung wrote: On 17.02.2013 23:57, André Warnier wrote: Otherwise, my feeling is that it will cost you quite a number of beers to stop Mark from fixing what could potentially be a security issue, now that he's sniffed it. :) Not sure whether Mark's sniffing changes based on the fact that we are now talking about the AJP part of the connectors. It does mean I'm rather less concerned since that explains why the request wasn't rejected with a 400 response. I still want to look at this to understand why getRequestURI() is behaving the way it is. There might still be a bug here. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getRequestURI() in relation to Connector.URIEncoding
Mark Thomas wrote: On 18/02/2013 09:54, Rainer Jung wrote: On 17.02.2013 23:57, André Warnier wrote: Otherwise, my feeling is that it will cost you quite a number of beers to stop Mark from fixing what could potentially be a security issue, now that he's sniffed it. :) Not sure whether Mark's sniffing changes based on the fact that we are now talking about the AJP part of the connectors. It does mean I'm rather less concerned since that explains why the request wasn't rejected with a 400 response. Well, the OP did not specifically test with the HTTP Connector, but it doesn't mean that the issue is not there too.. I still want to look at this to understand why getRequestURI() is behaving the way it is. There might still be a bug here. Looks like getRequestURI() is behaving according to the Javadocs though, by providing the original request line undecoded, as is. The issue is that the request should probably not even get to the point where it can be retrieved by getRequestURI(), no ? The beer question is still open.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: getRequestURI() in relation to Connector.URIEncoding
On 18/02/2013 11:44, André Warnier wrote: Mark Thomas wrote: On 18/02/2013 09:54, Rainer Jung wrote: On 17.02.2013 23:57, André Warnier wrote: Otherwise, my feeling is that it will cost you quite a number of beers to stop Mark from fixing what could potentially be a security issue, now that he's sniffed it. :) Not sure whether Mark's sniffing changes based on the fact that we are now talking about the AJP part of the connectors. It does mean I'm rather less concerned since that explains why the request wasn't rejected with a 400 response. Well, the OP did not specifically test with the HTTP Connector, but it doesn't mean that the issue is not there too.. Very true. I did a quick test and the request is not rejected which surprised me rather. I still want to look at this to understand why getRequestURI() is behaving the way it is. There might still be a bug here. Looks like getRequestURI() is behaving according to the Javadocs though, by providing the original request line undecoded, as is. The issue is that the request should probably not even get to the point where it can be retrieved by getRequestURI(), no ? A little digging and it is clear that the AJP connector is behaving as intended. Any %nn values sent by the client are decoded by the reverse proxy so the AJP message contains (mostly) the raw bytes. There is the potential for a problem here (CVE-2007-0450, CVE-2007-1860) but as long as the reverse proxy is correctly configured (which it is by default - see [1]) all will be fine as the potentially problematic bytes will be re-encoded. While it is a little surprising that getRequestURI() returns characters outside of those defined for uric by RFC2396 given the circumstances I think it is reasonable (for AJP) since that is what Tomcat received. Arguably a byte that represents a character not in uric should be re-encoded using %nn before including it in the return value for getRequestURI() but I don't see a need to implement that. If it was causing a problem somehow then I could be persuaded otherwise. I am more surprised by the HTTP connector. Looking at the code it is clear why this happens. The sequence is: 1. %nn - byte 2. normalise 3. convert to characters Bytes that should have been %nn encoded but have not, simply skip the first stage and then continue as normal. Where this could get messy is when the client converts multibyte characters to bytes using one encoding and Tomcat converts those bytes to characters using a different encoding. However, while this might cause unexpected behaviour from the client's point of view I don't see how this could cause a problem for Tomcat. Any sequence of bytes that Tomcat ends up processing from stage 2 as a result of byte - char conversion issues onwards could be sent legally using %nn encoding. Tomcat could justifiably reject these requests as not conforming to RFC 2616. That said, RFC2616 also encourages servers to be tolerant about that they receive from clients and I think this falls into that category. As long as such behaviour does not cause a problem for Tomcat I think it is reasonable to leave the current behaviour as is. The leaves the behaviour of getRequestURI(). It is returning what the client sent so no issue there. Again given a specific issue I'd be prepared to look at %nn encoding for characters not in uric. I agree access to the bytes would be ideal but since bytes are only necessary when going above and beyond what is required by RFC 2616 it isn't surprising that the Servlet EG opted to return a String here. So in summary, not what I was expecting but after some digging I don't see anything that particularly concerns me at this point. The beer question is still open.. Beers are always welcome. I'll be at ApacheConNA in Portland, OR next week :) Mark [1] http://tomcat.apache.org/connectors-doc/reference/apache.html#Forwarding - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 7.0.22 - allowTrace=false not working
Hi, I want to disable http TRACE method in my application which is running on tomcat 7.0.22 web-server. Though apache tomcat configuration for http says that it is set to false by default, it allows TRACE. I tried setting it to false specifically, but still it allows. I searched through your mail archives hosted on 4-5 sites and general web but could not find a working solution. Please help. Here is 'connector' (only 1) from my server.xml Connector port=8080 protocol=HTTP/1.1 server=SACHIN connectionTimeout=2 allowTrace=false redirectPort=8443 / Thanks Regards Sachin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: getRequestURI() in relation to Connector.URIEncoding
[multiple inline responses] Rainer Jung wrote: I doubt that such URLs are invalid - not based on any code inspection, but simply on the fact that mod_jk decoded percent encoding before forwarding for a long time (5.5 years, from Oct. 2001 to May 2007, version 1.2.0 to 1.2.22). Since version 1.2.24 any bytes in the URI expected to be unsafe are percent encoded before forwarding. At least that's the default. If you use an non-default ForwardURIxxx option via JkOptions, then that behavior depend on the chosen setting. Nevertheless it makes sense to check and clarify. Which mod_jk version and JkOptions are you using? We were indeed running with the 2007 default, ie resulting in ForwardURICompat which has an appropriate warning in the docs. But my point is not that a change in Tomcat could hit us - we will correct our config this week. My point is that invalidating these urls could break sites for folks that don't follow this mailing list and just update to the latest Tomcat ;-) Mark Thomas wrote: snip While it is a little surprising that getRequestURI() returns characters outside of those defined for uric by RFC2396 given the circumstances I think it is reasonable (for AJP) since that is what Tomcat received. Arguably a byte that represents a character not in uric should be re-encoded using %nn before including it in the return value for getRequestURI() but I don't see a need to implement that. If it was causing a problem somehow then I could be persuaded otherwise. I am more surprised by the HTTP connector. Looking at the code it is clear why this happens. The sequence is: 1. %nn - byte 2. normalise 3. convert to characters Bytes that should have been %nn encoded but have not, simply skip the first stage and then continue as normal. Where this could get messy is when the client converts multibyte characters to bytes using one encoding and Tomcat converts those bytes to characters using a different encoding. However, while this might cause unexpected behaviour from the client's point of view I don't see how this could cause a problem for Tomcat. Any sequence of bytes that Tomcat ends up processing from stage 2 as a result of byte - char conversion issues onwards could be sent legally using %nn encoding. Tomcat could justifiably reject these requests as not conforming to RFC 2616. That said, RFC2616 also encourages servers to be tolerant about that they receive from clients and I think this falls into that category. As long as such behaviour does not cause a problem for Tomcat I think it is reasonable to leave the current behaviour as is. The leaves the behaviour of getRequestURI(). It is returning what the client sent so no issue there. Again given a specific issue I'd be prepared to look at %nn encoding for characters not in uric. I agree access to the bytes would be ideal but since bytes are only necessary when going above and beyond what is required by RFC 2616 it isn't surprising that the Servlet EG opted to return a String here. I think we are talking about four alternatives on how to handle this. Here's my 2c about them: 1) Leave as is I wish getRequestURI() was declared with byte[] return value... It hurts to see these bytes copied straight into a string. I like this alternative the least. 2) Invalid, throw an error back at the client This is strict and clear, might surprise some folks if implemented in a point release. 3) Decode binary chars in getRequestURI() according to URIEncoding (ie, returning a fully decoded value.) This follows Postel's law. I like Postel's law. 4) Revert binary chars in getRequestURI() back to URL encoding (ie, returning a value with % notation.) This follows Postel's law. I like Postel's law. Best regards Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP rejections and too many open files exception on tomcat
Radha Krishnan D wrote: Hi, We are running into too many open issues exception on our production systems for the last With a lot of guesswork .. Google for ulimit ? Get a bigger server ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP rejections and too many open files exception on tomcat
Hi Am sorry, clicked submit by mistake The below is the actual problem We are running into too many open files exception on our production tomcat server for the last 2-3 days. We have max threads as 150 and acceptCount as 100 and at one point of time all the 250 threads are busy processing requests (due to application related issues) At peak times, when all the threads are busy, new requests are rejected by tomcat. Nearly 40 mins to 1 hr after the rejections begin, there are too many open files exception coming on the tomcat server.. The number of file descriptors is 16384 and we are getting 50-60 requests per sec. What can be the root cause here. After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? Can any one help us in this regard ? Thanks, D.Radhakrishnan -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 18 February 2013 22:32 To: Tomcat Users List Subject: Re: HTTP rejections and too many open files exception on tomcat Radha Krishnan D wrote: Hi, We are running into too many open issues exception on our production systems for the last With a lot of guesswork .. Google for ulimit ? Get a bigger server ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP rejections and too many open files exception on tomcat
Radha Krishnan D wrote: Hi Am sorry, clicked submit by mistake The below is the actual problem We are running into too many open files exception on our production tomcat server for the last 2-3 days. We have max threads as 150 and acceptCount as 100 and at one point of time all the 250 threads are busy processing requests (due to application related issues) At peak times, when all the threads are busy, new requests are rejected by tomcat. Nearly 40 mins to 1 hr after the rejections begin, there are too many open files exception coming on the tomcat server.. The number of file descriptors is 16384 and we are getting 50-60 requests per sec. What can be the root cause here. After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? Can any one help us in this regard ? platform/OS version ? Java version ? Tomcat version (x.y.z) ? The number of file descriptors is 16384.. : where does that number come from ? And are they sockets or other things ? After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? There are some states in TCP/IP, that a connection goes through even after a close() has been issued by the server side. There are some delays there, and maybe that is a source for your problem. Google for TCP state diagram. Use netstat and lsof (under Unix/Linux) to find out more. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP rejections and too many open files exception on tomcat
André Warnier wrote: Radha Krishnan D wrote: Hi Am sorry, clicked submit by mistake The below is the actual problem We are running into too many open files exception on our production tomcat server for the last 2-3 days. We have max threads as 150 and acceptCount as 100 and at one point of time all the 250 threads are busy processing requests (due to application related issues) At peak times, when all the threads are busy, new requests are rejected by tomcat. Nearly 40 mins to 1 hr after the rejections begin, there are too many open files exception coming on the tomcat server.. The number of file descriptors is 16384 and we are getting 50-60 requests per sec. What can be the root cause here. After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? Can any one help us in this regard ? platform/OS version ? Java version ? Tomcat version (x.y.z) ? The number of file descriptors is 16384.. : where does that number come from ? And are they sockets or other things ? After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? There are some states in TCP/IP, that a connection goes through even after a close() has been issued by the server side. There are some delays there, and maybe that is a source for your problem. Google for TCP state diagram. Use netstat and lsof (under Unix/Linux) to find out more. See also this http://stackoverflow.com/questions/34588/how-do-i-change-the-number-of-open-files-limit-in-linux The point is : your system(s) may really be too small to handle the load that comes to them; or your application may be too slow to respond; or you may have KeepAlive set too high for your own good, or any of the parameters here that can be used to modulate what happens could be wrong for your case : https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation But all these parameters are to some extent interdependent, and before tuning any of them, you would need to have (and provide us with) a better picture of what really happens. If you start playing around with them without really understanding what is happening and what you are doing, you'll probably make the situation worse, not better. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.22 - allowTrace=false not working
On 18/02/2013 15:00, Sachin wrote: Hi, I want to disable http TRACE method in my application which is running on tomcat 7.0.22 web-server. Though apache tomcat configuration for http says that it is set to false by default, it allows TRACE. I tried setting it to false specifically, but still it allows. I searched through your mail archives hosted on 4-5 sites and general web but could not find a working solution. Please help. Here is 'connector' (only 1) from my server.xml Connector port=8080 protocol=HTTP/1.1 server=SACHIN connectionTimeout=2 allowTrace=false redirectPort=8443 / How are you testing this? I just tested 7.0.x trunk and see the documented behaviour. Further, there has been no change in the code that handles this in a number of years. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat 7.0.22 - allowTrace=false not working
I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our security certifying vendor tests application against. And it logs - The URL http://localhost:8080/app/; has the following allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found in the request with id 19. Thanks Regards Sachin -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, February 18, 2013 11:34 PM To: Tomcat Users List Subject: Re: tomcat 7.0.22 - allowTrace=false not working On 18/02/2013 15:00, Sachin wrote: Hi, I want to disable http TRACE method in my application which is running on tomcat 7.0.22 web-server. Though apache tomcat configuration for http says that it is set to false by default, it allows TRACE. I tried setting it to false specifically, but still it allows. I searched through your mail archives hosted on 4-5 sites and general web but could not find a working solution. Please help. Here is 'connector' (only 1) from my server.xml Connector port=8080 protocol=HTTP/1.1 server=SACHIN connectionTimeout=2 allowTrace=false redirectPort=8443 / How are you testing this? I just tested 7.0.x trunk and see the documented behaviour. Further, there has been no change in the code that handles this in a number of years. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.22 - allowTrace=false not working
On 18/02/2013 18:19, Sachin wrote: I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our security certifying vendor tests application against. And it logs - The URL http://localhost:8080/app/; has the following allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found in the request with id 19. That looks like a false positive although I'm not sure how it is happening. You'd have to dig into the test to look at the HTTP request and response headers to see what is goign on. Mark Thanks Regards Sachin -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, February 18, 2013 11:34 PM To: Tomcat Users List Subject: Re: tomcat 7.0.22 - allowTrace=false not working On 18/02/2013 15:00, Sachin wrote: Hi, I want to disable http TRACE method in my application which is running on tomcat 7.0.22 web-server. Though apache tomcat configuration for http says that it is set to false by default, it allows TRACE. I tried setting it to false specifically, but still it allows. I searched through your mail archives hosted on 4-5 sites and general web but could not find a working solution. Please help. Here is 'connector' (only 1) from my server.xml Connector port=8080 protocol=HTTP/1.1 server=SACHIN connectionTimeout=2 allowTrace=false redirectPort=8443 / How are you testing this? I just tested 7.0.x trunk and see the documented behaviour. Further, there has been no change in the code that handles this in a number of years. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.22 - allowTrace=false not working
On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote: On 18/02/2013 18:19, Sachin wrote: I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our security certifying vendor tests application against. And it logs - The URL http://localhost:8080/app/; has the following allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found in the request with id 19. That looks like a false positive although I'm not sure how it is happening. You'd have to dig into the test to look at the HTTP request and response headers to see what is goign on. Mark IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed in an OPTIONS request, but then refuse the request when an actual TRACE was made. I've also seen this happen with PUT. Perhaps w3af is taking the OPTIONS response at face value instead of actually testing whether a TRACE request is allowed? I would suggest that w3af should do both, but I would also suggest that Tomcat should not include TRACE in the OPTIONS response if TRACE is really disallowed, and likewise for the other methods. My $0.02. N Thanks Regards Sachin -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, February 18, 2013 11:34 PM To: Tomcat Users List Subject: Re: tomcat 7.0.22 - allowTrace=false not working On 18/02/2013 15:00, Sachin wrote: Hi, I want to disable http TRACE method in my application which is running on tomcat 7.0.22 web-server. Though apache tomcat configuration for http says that it is set to false by default, it allows TRACE. I tried setting it to false specifically, but still it allows. I searched through your mail archives hosted on 4-5 sites and general web but could not find a working solution. Please help. Here is 'connector' (only 1) from my server.xml Connector port=8080 protocol=HTTP/1.1 server=SACHIN connectionTimeout=2 allowTrace=false redirectPort=8443 / How are you testing this? I just tested 7.0.x trunk and see the documented behaviour. Further, there has been no change in the code that handles this in a number of years. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: tomcat 7.0.22 - allowTrace=false not working
On 18/02/2013 19:03, Nick Williams wrote: On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote: On 18/02/2013 18:19, Sachin wrote: I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our security certifying vendor tests application against. And it logs - The URL http://localhost:8080/app/; has the following allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found in the request with id 19. That looks like a false positive although I'm not sure how it is happening. You'd have to dig into the test to look at the HTTP request and response headers to see what is goign on. Mark IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed in an OPTIONS request, but then refuse the request when an actual TRACE was made. I've also seen this happen with PUT. Perhaps w3af is taking the OPTIONS response at face value instead of actually testing whether a TRACE request is allowed? I would suggest that w3af should do both, but I would also suggest that Tomcat should not include TRACE in the OPTIONS response if TRACE is really disallowed, and likewise for the other methods. No supported Tomcat version has behaved that way for over three years including the entire of the 7.0.x branch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.22 - allowTrace=false not working
On Feb 18, 2013, at 1:11 PM, Mark Thomas wrote: On 18/02/2013 19:03, Nick Williams wrote: On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote: On 18/02/2013 18:19, Sachin wrote: I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our security certifying vendor tests application against. And it logs - The URL http://localhost:8080/app/; has the following allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found in the request with id 19. That looks like a false positive although I'm not sure how it is happening. You'd have to dig into the test to look at the HTTP request and response headers to see what is goign on. Mark IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed in an OPTIONS request, but then refuse the request when an actual TRACE was made. I've also seen this happen with PUT. Perhaps w3af is taking the OPTIONS response at face value instead of actually testing whether a TRACE request is allowed? I would suggest that w3af should do both, but I would also suggest that Tomcat should not include TRACE in the OPTIONS response if TRACE is really disallowed, and likewise for the other methods. No supported Tomcat version has behaved that way for over three years including the entire of the 7.0.x branch. Mark Okay. This was a couple of years ago that I saw this, and it was Tomcat 6.0 at the time, so that would probably explain why I saw what I saw. It would not explain the false positive he is seeing on 7.0.22, since the entire 7.0.x branch has handled this correctly. Nick smime.p7s Description: S/MIME cryptographic signature
[ANN] Apache Tomcat 7.0.37 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.37. Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. This release contains a small number of bug fixes and improvements compared to version 7.0.35. The notable changes include: - Fix the regression in the JspC tool that is used to pre-compile JSP pages introduced in 7.0.35. See issue 54440 for details. Patch provided by Sheldon Shao. - Improve handling of ciphers and sslEnabledProtocols options for the BIO and NIO connectors. The behaviour of each connector is now the same. The values provided are pruned to those supported by the SSL implementation and when none of the remaining values are supported a warning is issued and the connector configured with an empty set of options (which essentially disables HTTPS support). - Update to Commons Daemon 1.0.13. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Note: This version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures. Note: If you use the APR/native AJP or HTTP connector you *must* upgrade to version 1.1.24 or later of the AJP/native library and it is recommended that you upgrade to 1.1.27 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
No javax.servlet.error.query_string
Hi, This is rather a question about Servlet specification. Is there a reason why there is no javax.servlet.error.query_string ? At http://tomcat.apache.org/tomcat-7.0-doc/servletapi/constant-values.html we see there is *.query_string for forward and include, but not for error. Is it because of some security concern or something else ? Thanks, Martin
Re: HTTP rejections and too many open files exception on tomcat
On 18/02/2013 17:05, Radha Krishnan D wrote: Hi Am sorry, clicked submit by mistake The below is the actual problem We are running into too many open files exception on our production tomcat server for the last 2-3 days. We have max threads as 150 and acceptCount as 100 and at one point of time all the 250 threads are busy processing requests (due to application related issues) You only have 150 threads, not 250. 150 is not a large number is in fact lower than the default. At 50-60 requests per second, you must serve each request within 0.3s to avoid queuing requests (ie, using the acceptCount queue). You should avoid queueing requests. At peak times, when all the threads are busy, new requests are rejected by tomcat. Expected. Nearly 40 mins to 1 hr after the rejections begin, there are too many open files exception coming on the tomcat server.. Maybe this is the real peak. The number of file descriptors is 16384 and we are getting 50-60 requests per sec. What can be the root cause here. Too many possible options, not enough info. After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? Can any one help us in this regard ? Please post the Connector configuration from server.xml. You may obscure/remove passwords if present. p Thanks, D.Radhakrishnan -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 18 February 2013 22:32 To: Tomcat Users List Subject: Re: HTTP rejections and too many open files exception on tomcat Radha Krishnan D wrote: Hi, We are running into too many open issues exception on our production systems for the last With a lot of guesswork .. Google for ulimit ? Get a bigger server ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and Solaris 11
I'm having some problems getting the nsapi_redirect.dll working with
iPlanet 7.0.15 on solaris 11. The problem seems specifically related to
Solaris 11 and only if I try to install/run the server as root (using
webservd as the non-privileged user).
When I do so (and after enabling debug jk loglevel) during jk_init I see
the following messages in the jk log:
[Mon Feb 18 22:36:25.588 2013] [20669:1] [debug]
jk_init::jk_nsapi_plugin.c (337): jk_init, a second passed
repeated a bunch of times
and in the iPlanet error log the following:
[18/Feb/2013:22:37:24] failure (20669): CORE2254: Error running Init
function jk_init
Looking at the code:
s = systhread_start(SYSTHREAD_DEFAULT_PRIORITY,
0, init_workers_on_other_threads,
init_map);
for (sleep_cnt = 0; sleep_cnt 60; sleep_cnt++) {
systhread_sleep(1000);
jk_log(logger, JK_LOG_DEBUG, jk_init, a second passed);
if (init_on_other_thread_is_done) {
break;
}
}
I can find no evidence in the jklog that the
init_workers_on_other_threads thread actually started properly.
Here's the cute thing. It only happens on Solaris 11 with the server
run as root, and configured to run as a non-privileged user (any
non-privileged user has this issue)
If I execute startserv as the non-privileged user rather than root or do
this on Solaris 10, no problems.
Any ideas why systhread_start (this is an iPlanet NSAPI function) would
fail here as root?
Thanks,
Andy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi Cris,
Il giorno ven, 15/02/2013 alle 12.36 -0500, Christopher Schultz ha
scritto:
[...]
Allow legacy hello messages: true [snip] http-192.168.1.55-8443-1,
READ: SSLv3 Handshake, length = 75 *** ClientHello, SSLv3
RandomCookie: GMT: 1360933724 bytes = { 203, 86, 168, 88, 75, 77,
52, 134, 4, 76, 204, 78, 0, 160, 168, 123, 96, 78, 106, 23, 40, 47,
219, 81, 28, 23, 174, 156 } Session ID: {} Cipher Suites:
[TLS_EMPTY_RENEGOTIATION_INFO_SCSV, Unknown 0x0:0x3d, Unknown
0x0:0x3c, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA,
SSL_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x67, Unknown 0x0:0x6b,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, Unknown 0x0:0x3b,
SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5] Compression Methods:
{ 0 } ***
So the client is doing an SSLv3 handshake. The message above about
allowing legacy hellos seems like it should support a SSLv3
handshake. Looking at the ciphers, your JVM (without BouncyCastle) and
client truly have no overlap. I'm actually surprised that your JVM
does not support any TLS_RSA_* or TLS_DHE_* ciphers. Can you re-run my
cipher-dump program without BouncyCastle and provide the full output?
I was a little unclear as to what you posted last time.
I listed all providers here:
http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphers-no-bouncycastle.html
as you may see, a few of them are TLS_RSA and TLS_DHE:
* TLS_RSA_WITH_AES_128_CBC_SHA
* TLS_RSA_WITH_AES_256_CBC_SHA
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA
They are also listed as default ciphers, so -- if I understood what
default means -- they should not be enabled explicitly.
They overlap with those client ciphers:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Is there any possibility that some of those server ciphers are disabled
because of the algorithm used in the server certificate? Its signature
algorithm is SHA1withDSA. I created it with this command line:
keytool -genkeypair -alias tomcat -keystore ~tomcat6/.keystore
A side note: is it possibile to put tomcat behind a web server and make
the latter encrypt in SSL? This would imply that communication between
the web server and tomcat would be in clear, but how do I create the
connector proxy* information? I may specify proxyName and proxyPort, but
I cannot specify proxyProtocol. Is this right?
Bye,
Giuseppe
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
Hi Martin, Il giorno ven, 15/02/2013 alle 18.29 -0500, Martin Gainty ha scritto: someone put cipherSuites patch on TC 7 Connector.. *IF you are implementing TC7 Connector with cipherSuites attribute support and have not specified cipherSuites supported by your ppk keys* then yes its tomcats fault I am using 6.0.36. Bye, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP rejections and too many open files exception on tomcat
On 18/02/2013 21:14, Pid wrote: On 18/02/2013 17:05, Radha Krishnan D wrote: Hi Am sorry, clicked submit by mistake The below is the actual problem We are running into too many open files exception on our production tomcat server for the last 2-3 days. We have max threads as 150 and acceptCount as 100 and at one point of time all the 250 threads are busy processing requests (due to application related issues) You only have 150 threads, not 250. 150 is not a large number is in fact lower than the default. At 50-60 requests per second, you must serve each request within 0.3s That number (0.3) is around an order of magnitude too small. Mark to avoid queuing requests (ie, using the acceptCount queue). You should avoid queueing requests. At peak times, when all the threads are busy, new requests are rejected by tomcat. Expected. Nearly 40 mins to 1 hr after the rejections begin, there are too many open files exception coming on the tomcat server.. Maybe this is the real peak. The number of file descriptors is 16384 and we are getting 50-60 requests per sec. What can be the root cause here. Too many possible options, not enough info. After rejecting a request, is the socket not closed immediately and this results in pile up of open files or is there some other reason ? Can any one help us in this regard ? Please post the Connector configuration from server.xml. You may obscure/remove passwords if present. p Thanks, D.Radhakrishnan -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 18 February 2013 22:32 To: Tomcat Users List Subject: Re: HTTP rejections and too many open files exception on tomcat Radha Krishnan D wrote: Hi, We are running into too many open issues exception on our production systems for the last With a lot of guesswork .. Google for ulimit ? Get a bigger server ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. - 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 does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
On 18.02.2013 22:59, Giuseppe Sacco wrote: A side note: is it possibile to put tomcat behind a web server and make the latter encrypt in SSL? This would imply that communication between the web server and tomcat would be in clear, but how do I create the connector proxy* information? I may specify proxyName and proxyPort, but I cannot specify proxyProtocol. Is this right? Look for scheme and for secure in https://tomcat.apache.org/tomcat-7.0-doc/config/http.html Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [FWD: Help Debugging 404 errors]
Jose, Thanks for you help. It is working now that I have a new Tomcat 7 friendly version from the author of the SpringMVC servlet author. I'm not sure what he changed. Siegfried Original Message Subject: Re: [FWD: Help Debugging 404 errors] From: Jose_María_Zaragoza demablo...@gmail.com Date: Wed, February 13, 2013 3:15 pm To: Tomcat Users List users@tomcat.apache.org They actually use a pseudo-CATALINA_BASE (I think) and run the server from: workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp[n] n is the number of your server in your Servers project. There is no bin directory, and there's an extra directory called wtpwebapps which contains an empty ROOT application. You can change all this configuration by double-clicking over the server icon in Servers tab. And choose root folder and webapps folder Regards - 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.0.22 - allowTrace=false not working
Thanks Mark n Nick. As far as I see from w3af documentation, they are looking into options to show the allowedMethods. (As Nick guessed) Mark, Can you suggest me an alternate way to prove that TRACE is not allowed on my webserver, if that's a possibly false positive. Thanks Regards Sachin -Original Message- From: Nick Williams [mailto:nicho...@nicholaswilliams.net] Sent: Tuesday, February 19, 2013 12:47 AM To: Tomcat Users List Subject: Re: tomcat 7.0.22 - allowTrace=false not working On Feb 18, 2013, at 1:11 PM, Mark Thomas wrote: On 18/02/2013 19:03, Nick Williams wrote: On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote: On 18/02/2013 18:19, Sachin wrote: I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our security certifying vendor tests application against. And it logs - The URL http://localhost:8080/app/; has the following allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found in the request with id 19. That looks like a false positive although I'm not sure how it is happening. You'd have to dig into the test to look at the HTTP request and response headers to see what is goign on. Mark IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed in an OPTIONS request, but then refuse the request when an actual TRACE was made. I've also seen this happen with PUT. Perhaps w3af is taking the OPTIONS response at face value instead of actually testing whether a TRACE request is allowed? I would suggest that w3af should do both, but I would also suggest that Tomcat should not include TRACE in the OPTIONS response if TRACE is really disallowed, and likewise for the other methods. No supported Tomcat version has behaved that way for over three years including the entire of the 7.0.x branch. Mark Okay. This was a couple of years ago that I saw this, and it was Tomcat 6.0 at the time, so that would probably explain why I saw what I saw. It would not explain the false positive he is seeing on 7.0.22, since the entire 7.0.x branch has handled this correctly. Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 and Solaris 11
On 02/18/2013 10:47 PM, Andy Wang wrote: If I execute startserv as the non-privileged user rather than root or do this on Solaris 10, no problems. Any ideas why systhread_start (this is an iPlanet NSAPI function) would fail here as root? Did you tried to check the ulimit. Seems like webservd once when switched to non privileged user cannot create threads either because of some security settings or lack of resources. Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
