Tomcat 8 APR/openSSL Issue

2017-10-05 Thread Syam Pillai
On my AMI (Amazon Linux) server, tomcat 8 was running happily but today,
after an upgrade (Version is now 8.5.16.0), the server is failing to start
with the following message:

INFO [main] org.apache.coyote.AbstractProtocol.init Initializing
ProtocolHandler ["https-openssl-nio-8443"]
/usr/share/soengine/jdk/bin/java: symbol lookup error:
/usr/lib64/libtcnative-1.so.0.2.10: undefined symbol:
SSL_CTX_add0_chain_cert

I can see that before these lines,
OpenSSL is loaded:
INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL
OpenSSL successfully initialized [OpenSSL 1.0.1e-fips 11 Feb 2013]

However,
​ ​
I don't know why this version of OpenSSL is being shown. On the OS terminal
(Kernel:
4.9.51-10.52.amzn1.x86_64 #1 SMP), if I check, it is showing a different
version. (I could not find any duplicate installation of OpenSSL
​ ​
on the server).

openssl version -v
OpenSSL 1.0.2k-fips  26 Jan 2017


Re: Performance settings for Multiple Hosts

2017-10-05 Thread Mark Thomas
On 05/10/17 21:36, Jerry Malcolm wrote:
> I am running TC 8.0 on WinServer8 on a commercially hosted platform with
> a WAMP environment.   I am running around 10 virtual hosts.   2 hosts
> are dedicated to JSPWiki.  The other 8 are running variations of the
> same custom application with around 10-15 individual webapps each.
> 
> When I am running 7 of the 10 hosts, performance is great.  I get JSP
> response time under a second.  But when I add just a couple of more of
> the hosts, my page response time on all of the apps goes from an
> acceptable under a second to horrible at around 15-20 seconds per page. 
> It doesn't seem to be a specific host causing the problem.  Reducing
> overall hosts in any order makes the problem go away.
> 
> I've looked at the the processor utilization during the good times and
> slow times, and don't see a significant difference.  I have 16GB of
> memory, and it consistently shows about 35% utilization.

Is this the OS memory or what you have allocated to Java?

> I also checked
> mySQL response time, and the per-query SQL response does not vary.  So
> it doesn't appear to be a db problem.
> 
> I suspect there is some TC configuration parameter such as heap, etc
> that I need to tweak. (But I'm not getting OutOfMemory errors).  But I
> don't know which one, and I don't know a formula to use to figure out
> what to set it to.  So I just need a little education.  What tools can I
> use to help me figure out what is going south slowing everything to a
> crawl when the extra hosts come online?  And what parameters should I be
> looking at (and how should I calculate the proper values based on number
> of hosts)?
> 
> Suggestions?>
> Thanks.
> 
> Jerry
> 
> 
> -
> 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



Performance settings for Multiple Hosts

2017-10-05 Thread Jerry Malcolm
I am running TC 8.0 on WinServer8 on a commercially hosted platform with 
a WAMP environment.   I am running around 10 virtual hosts.   2 hosts 
are dedicated to JSPWiki.  The other 8 are running variations of the 
same custom application with around 10-15 individual webapps each.


When I am running 7 of the 10 hosts, performance is great.  I get JSP 
response time under a second.  But when I add just a couple of more of 
the hosts, my page response time on all of the apps goes from an 
acceptable under a second to horrible at around 15-20 seconds per page.  
It doesn't seem to be a specific host causing the problem.  Reducing 
overall hosts in any order makes the problem go away.


I've looked at the the processor utilization during the good times and 
slow times, and don't see a significant difference.  I have 16GB of 
memory, and it consistently shows about 35% utilization.  I also checked 
mySQL response time, and the per-query SQL response does not vary.  So 
it doesn't appear to be a db problem.


I suspect there is some TC configuration parameter such as heap, etc 
that I need to tweak. (But I'm not getting OutOfMemory errors).  But I 
don't know which one, and I don't know a formula to use to figure out 
what to set it to.  So I just need a little education.  What tools can I 
use to help me figure out what is going south slowing everything to a 
crawl when the extra hosts come online?  And what parameters should I be 
looking at (and how should I calculate the proper values based on number 
of hosts)?


Suggestions?

Thanks.

Jerry


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



Re: Severity of CVE-2016-6816

2017-10-05 Thread Mark Thomas
On 05/10/17 20:35, Justin wrote:
> Hi all,
> I'm curious about the severity of CVE-2016-6816 fixed last November.
> http://svn.apache.org/viewvc?view=revision=1767653
> 
> I see that vendors backported this fix (over time).
> http://www.securitytracker.com/id/1037332
> Severity is described as Important, Moderate, CVSS v2 Medium, and CVSS v3 
> High.
> "A remote user can exploit this to spoof content on the target server, 
> attempt to poison any intermediate web caches, or conduct cross-site 
> scripting attacks."
> This sounds pretty serious. If my server is running a vulnerable version of 
> Tomcat, how easy is it to exploit?

I'm not going to go into the details of exactly how to exploit this
issue but the answer to your question is pretty difficult.

1. You need to be running Tomcat behind a reverse proxy of some form.

2. That reverse proxy needs to accept the same invalid requests as
   Tomcat (it should reject them with a 400 response).

3. The attacker needs to be able to either upload arbitrary static
   content which they can then request or formulate a request in such a
   way that arbitrary content is injected into the response.

1 is very common. 2 is possible but I haven't seen any evidence of it
for these particular invalid requests. 3 is (very) unlikely.

Overall, I'd judge the chances of all of these lining up on any given
system as low to very low. It is one of those where the chances of it
happening are low but the impact if it does happen is high. You could
argue rating of Low, Moderate or High for this on Tomcat's scale. It is
very much a judgement call. Where there is uncertainty over the
likelihood then we tend to err on the side of caution.

> Must webapps use cookies as some example exploits have shown?

No.

> "By manipulating the HTTP response the attacker could... obtain sensitive 
> information from requests other then their own." So if trusted users are 
> logging in, untrusted users could obtain passwords? Path or query parameters?

Untrusted users could obtain anything from the response intended for a
trusted user. Passwords are therefore unlikely, as is anything on the
request side unless the application is echoing that data back to the
client. Session cookies are probably the most likely target.

HTH,

Mark

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



RE: ISAPI and IIS 10 Logging Issue

2017-10-05 Thread Thomas, Michael
[External Email]

--
On 05.10.2017 17:09, George Stanchev wrote:
> 
>
>> Note that also in the course of my investigations, somewhere I found a 
>> phrase to the effect that Mirosoft would be discouraging the future use of 
>> ISAPI modules in IIS, and recommends some other architecture instead now.
>
> Do you remember where you saw that? Can you provide a link?

Oh my, I think that I wrote this...

I do not remember exactly, but it might have been through a Google search for 
"IIS and ISAPI", which yelds this first result :

https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_iis_configuration_system.webserver_isapifilters_=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=RhqitdWJrYFj4X-VbyU24zGMsHLG_rF_ZPbp8r7_AZk=

(see the Note box)

or here :
https://urldefense.proofpoint.com/v2/url?u=https-3A__technet.microsoft.com_en-2Dus_library_cc733109-2528v-3Dws.10-2529.aspx=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=M-sMPmY0MIsn5kRfRQh585_T47nRBfnglZrF8SOey9s=
"In IIS 7, modules replace ISAPI filters, but you can still add ISAPI filters 
if you require the functionality that they provide. "

or here :
https://urldefense.proofpoint.com/v2/url?u=https-3A__technet.microsoft.com_en-2Dus_library_cc753568-2528v-3Dws.11-2529.aspx=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=XKH-dyaNlgF0SZw__Fd1QToaxeEblm3xQMfH1Qc57Lk=

Not really solid, but I am quite sure that I saw something more "forceful" 
elsewhere.

Ah, here :
https://urldefense.proofpoint.com/v2/url?u=https-3A__technet.microsoft.com_en-2Dus_library_hh831460-2528v-3Dws.11-2529.aspx=DwIC-g=Ff2GokX4A_6S-cy_JRNEiQ=qnRbnLRaPTyCnNugXfUwBahUZvJn-qGmC8Rh9wHr8D0=DbQ305KuTM2F_E2iBepldzdcGBtdlaOltNKMsXQJiPY=dCzIxTcvs4S2BUcLmkC9Nk3iAk985CuVxROdGRwfI8E=

There (for IIS 8) it says "are replaced".


All of this without any guarantee though, I am not an MS expert in any way.
--
On 05.10.2017 17:09, Thomas, Michael wrote:

Just want to drop a few questions:

Are folks who develop and maintain the ISAPI redirector on this mailing list?

Is the ISAPI redirector still in active development?  It looks like it hasn't 
had an update since 2016. 
http://tomcat.apache.org/connectors-doc/news/20160901.html

If so, have the folks who maintain it tested on Windows 2016 and IIS 10?



The preceding message (including attachments) is covered by the Electronic 
Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for 
the person or entity to which it is addressed, and may contain information that 
is confidential, protected by attorney-client or other privilege, or otherwise 
protected from disclosure by law. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, or copying 
of this communication is strictly prohibited. Please reply to the sender that 
you have received the message in error and destroy the original message and all 
copies.

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



Severity of CVE-2016-6816

2017-10-05 Thread Justin
Hi all,
I'm curious about the severity of CVE-2016-6816 fixed last November.
http://svn.apache.org/viewvc?view=revision=1767653

I see that vendors backported this fix (over time).
http://www.securitytracker.com/id/1037332
Severity is described as Important, Moderate, CVSS v2 Medium, and CVSS v3 High.
"A remote user can exploit this to spoof content on the target server, attempt 
to poison any intermediate web caches, or conduct cross-site scripting attacks."
This sounds pretty serious. If my server is running a vulnerable version of 
Tomcat, how easy is it to exploit? Must webapps use cookies as some example 
exploits have shown? "By manipulating the HTTP response the attacker could... 
obtain sensitive information from requests other then their own." So if trusted 
users are logging in, untrusted users could obtain passwords? Path or query 
parameters?
Thanks, Justin


Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

2017-10-05 Thread James H. H. Lampert

This just keeps getting weirder.

Late yesterday afternoon, I did a lengthy "stare-and-compare" between 
what SSLInfo returned for the two different Tomcat servers, and I 
couldn't find any differences. But then, I got called away from this on 
something that kept me in the office until after 7 PM.


Finally getting back to it, I looked at the "connector ciphers" on the 
Tomcat 8 manager (there isn't one on the Tomcat 7 manager), and saw that 
only 16 of the 36 ciphers that SSLInfo starred as "default" are actually 
enabled in Tomcat.


Then, using what Mr. Schultz told me about reading cipher names, I 
compared what actually *does* come up in the Tomcat 8 manager with the 
DSPSYSVAL on the AS/400. And I found that if

*RSA_AES_256_CBC_SHA

is the same as

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA


then maybe we DO have a common cipher, at least in theory (unless 
"ECDHE" makes it otherwise).


Unfortunately, I can't run the local box's Tomcat server through 
SSLLabs, because it's on a nonstandard port number, and Tomcat 7 doesn't 
have a "connector ciphers" button on the manager main page.


The cloud box is a Google Compute Engine instance. Is it possible that 
Google is somehow vetoing the handshake?


--
JHHL

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



Re: ISAPI and IIS 10 Logging Issue

2017-10-05 Thread tomcat

On 05.10.2017 17:09, George Stanchev wrote:




Note that also in the course of my investigations, somewhere I found a phrase 
to the effect that Mirosoft would be discouraging the future use of ISAPI 
modules in IIS, and recommends some other architecture instead now.


Do you remember where you saw that? Can you provide a link?


Oh my, I think that I wrote this...

I do not remember exactly, but it might have been through a Google search for "IIS and 
ISAPI", which yelds this first result :


https://docs.microsoft.com/en-us/iis/configuration/system.webserver/isapifilters/

(see the Note box)

or here :
https://technet.microsoft.com/en-us/library/cc733109%28v=ws.10%29.aspx
"In IIS 7, modules replace ISAPI filters, but you can still add ISAPI filters if you 
require the functionality that they provide. "


or here :
https://technet.microsoft.com/en-us/library/cc753568%28v=ws.11%29.aspx

Not really solid, but I am quite sure that I saw something more "forceful" 
elsewhere.

Ah, here :
https://technet.microsoft.com/en-us/library/hh831460%28v=ws.11%29.aspx

There (for IIS 8) it says "are replaced".


All of this without any guarantee though, I am not an MS expert in any way.


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



Tomcat 8.5.23 - Nio2 Connector - Error reading request, ignored

2017-10-05 Thread Eirik Lykken
Dear All,

We are running Tomcat 8.5.23 production server on a CentOS 6.9 machine, Oracle 
JVM 1.8.0_144, and OpenSSL 1.1.0f. The server hosts a web application where 
almost all the traffic is https.

We used to have a Http11NioProtocol connector with Java SSL using HTTP 1.1 but 
we switched to Http2Protocol upgrade because of problems with Apple clients 
(KeepAlive timeout, server dropped the connection, etc..). We also switched to 
OpenSSL for ALPN.

Since then we have had several problems with the different connectors, all of 
them tested with Tomcat 8.5.16, 8.5.20 and 8.5.23.

- Http11NioProtocol has a memory leak, we experienced the same behaviour as 
this bug https://bz.apache.org/bugzilla/show_bug.cgi?id=57546 so we have to 
restart the server regularly.
- Http11AprProtocol runs fine but the JVM crashes unexpectedly with a core dump 
from time to time.
- Http11Nio2Protocol runs fine but some requests are not processed. We have not 
found a way to reproduce the problem but it happens once every 5 minutes. The 
server processes 1.13 million requests per day so it's one request failed every 
4000 approximately. We can't reproduce the failed requests, but some crawling 
tools report them as if the server failed to respond (no status code)

This is the exception we get:

05-Oct-2017 17:13:32.535 SEVERE 
[https-openssl-nio2-94.229.64.230-443-exec-19701] 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading 
request, ignored
 java.lang.IllegalStateException
at 
org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1314)
at 
org.apache.coyote.http2.Http2UpgradeHandler.fill(Http2UpgradeHandler.java:1290)
at 
org.apache.coyote.http2.Http2Parser.readConnectionPreface(Http2Parser.java:574)
at 
org.apache.coyote.http2.Http2UpgradeHandler.init(Http2UpgradeHandler.java:243)
at 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:310)
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:868)
at 
org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1693)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:946)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:115)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:108)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)
at 
sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
at 
sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
at 
sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
at 
java.nio.channels.AsynchronousSocketChannel.write(AsynchronousSocketChannel.java:577)
at 
org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:273)
at 
org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:204)
at 
org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.doRun(Nio2Endpoint.java:1671)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
org.apache.tomcat.util.net.AbstractEndpoint.processSocket(AbstractEndpoint.java:946)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:98)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:91)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker$2.run(Invoker.java:218)
at 
sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

This is our current Connector configuration:


 





We have experimented with different parameters of the Http2Protocol connector 
to improve performance and control the leak with Http11NioProtocol connector 
but the exceptions are there with any of the values or removing the extra 
parameters.

We also tried Tomcat/9.0.0.M26 and the 

RE: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

2017-10-05 Thread Gali, Vamsi A
Hello,
I just realized that I didn’t provide the environment info & following are the 
details:

Tomcat:  apache-tomcat-7.0.75
IHS: HIS v8.5.5.x
OS: RHEL

We have IHS→mod_proxy(on IHS) → Tomcat.
I know that IHS isn’t the suggested webserver to use with Tomcat but it’s in 
use.
[error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection 

When Tomcat is accessed through webserver url, it throws ‘500’ with the 
following stack on the IHS Error log:

[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2313): proxy: HTTPS: fam 2 
socket created to connect to TOMCAT2 [Thu Oct 00 09:20:20 2017] [debug] 
proxy_util.c(2419): proxy: HTTPS: connection complete to  TOMCAT-IP:PORT 
(TOMCAT2) [Thu Oct 00 09:20:20 2017] [error] SSL0266E: Handshake Failed, Could 
not establish SSL proxy connection.
[Thu Oct 00 09:20:20 2017] [info] [client TOMCAT-IP] [7fa404014a60] [13789] 
SSL0240I: SSL Handshake Failed, Socket has been closed. Client sent fatal alert 
[level 2 (fatal), description 40 (handshake_failure)]  [TOMCAT-IP:PORT -> 
IHS:PORT] [09:20:20.000967434] 0ms [Thu Oct 00 09:20:20 2017] [debug] [client  
TOMCAT-IP] [7fa404014a60] Handshake transcript:
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]   [Thu Oct 
00 09:20:20 2017] [debug] [client  TOMCAT-IP]  client_version
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_8Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]03
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_8Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]03
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  TLSV12 [Thu Oct 00 
09:20:20 2017] [debug] [client  TOMCAT-IP]  random
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_32Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]9xx
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_Opaque
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]Length: 28
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]1x 62 xx B3 1F 44 xx 
8E D2 xx x7 17 xx 59 x9 x9 .b...D...)...Y..
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]x1 91 19 08 25 xx DC 
xx E1 xx 20 xx %..o.9 x
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  session_id [Thu Oct 00 
09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 00 [Thu Oct 00 09:20:20 
2017] [debug] [client  TOMCAT-IP]  cipher_suites [Thu Oct 00 09:20:20 2017] 
[debug] [client  TOMCAT-IP]  Length: 14
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  0x Fx x6 00 00 xx 00 xx 
00 xx 00 xx 00 xx   ..V/.5
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  
tls_ri_scsv,tls_fallback_scsv,tls_rsa_with_rc4_128_sha,tls_rsa_with_aes_128_cbc_sha,tls_rsa_with_aes_256_cbc_sha,tls_rsa_with_3des_ede_cbc_sha,tls_rsa_with_rc4_128_md5
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  compression_methods 
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 01
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  00  
.
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Extensions [Thu Oct 00 
09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 00
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]   Extension Count: 0
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP] end handshake transcript 
[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2442): proxy: HTTPS: 
pre_connection setup failed (500) [Thu Oct 00 09:20:20 2017] [debug] 
proxy_util.c(2022): proxy: HTTPS: has released connection for TOMCAT2
--
What’s done: IHS & Tomcat keystores contain required signers for proper 
communication. During the troubleshooting, I even added IHS server cert as a 
signer into Tomcat keystore and vice-versa but cannot get rid of this error.
Also, tried restricting both IHS & Tomcat to use TLSv1 but no success. 

Has anyone ran into similar issues? Or ever tried Tomcat with IHS using 
mod_proxy module?


Thank you,
Vamsi Gali


This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not 

[error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

2017-10-05 Thread Gali, Vamsi A
Hello,

We have IHS→mod_proxy(on IHS) → Tomcat.
I know that IHS isn’t the suggested webserver to use with Tomcat but it’s in 
use.
[error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection 

When Tomcat is accessed through webserver url, it throws ‘500’ with the 
following stack on the IHS Error log:

[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2313): proxy: HTTPS: fam 2 
socket created to connect to TOMCAT2
[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2419): proxy: HTTPS: connection 
complete to  TOMCAT-IP:PORT (TOMCAT2)
[Thu Oct 00 09:20:20 2017] [error] SSL0266E: Handshake Failed, Could not 
establish SSL proxy connection.
[Thu Oct 00 09:20:20 2017] [info] [client TOMCAT-IP] [7fa404014a60] [13789] 
SSL0240I: SSL Handshake Failed, Socket has been closed. Client sent fatal alert 
[level 2 (fatal), description 40 (handshake_failure)]  [TOMCAT-IP:PORT -> 
IHS:PORT] [09:20:20.000967434] 0ms
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP] [7fa404014a60] Handshake 
transcript:
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  client_version
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_8Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]03
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_8Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]03
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  TLSV12
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  random
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_32Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]9xx
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_Opaque
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]Length: 28
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]1x 62 xx B3 1F 44 xx 
8E D2 xx x7 17 xx 59 x9 x9 .b...D...)...Y..
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]x1 91 19 08 25 xx DC 
xx E1 xx 20 xx %..o.9 x
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  session_id
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 00
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  cipher_suites
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 14
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  0x Fx x6 00 00 xx 00 xx 
00 xx 00 xx 00 xx   ..V/.5
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  
tls_ri_scsv,tls_fallback_scsv,tls_rsa_with_rc4_128_sha,tls_rsa_with_aes_128_cbc_sha,tls_rsa_with_aes_256_cbc_sha,tls_rsa_with_3des_ede_cbc_sha,tls_rsa_with_rc4_128_md5
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  compression_methods
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 01
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  00  
.
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Extensions
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 00
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]   Extension Count: 0
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP] end handshake transcript
[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2442): proxy: HTTPS: 
pre_connection setup failed (500)
[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2022): proxy: HTTPS: has 
released connection for TOMCAT2
--
What’s done: IHS & Tomcat keystores contain required signers for proper 
communication. During the troubleshooting, I even added IHS server cert as a 
signer into Tomcat keystore and vice-versa but cannot get rid of this error.
Also, tried restricting both IHS & Tomcat to use TLSv1 but no success. 

Has anyone ran into similar issues? Or eve tried Tomcat with IHS using 
mod_proxy module?


Thank you,
Vamsi Gali
Web Systems Services
Ph: 214-416-3128




This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 

RE: ISAPI and IIS 10 Logging Issue

2017-10-05 Thread George Stanchev


> Note that also in the course of my investigations, somewhere I found a phrase 
> to the effect that Mirosoft would be discouraging the future use of ISAPI 
> modules in IIS, and recommends some other architecture instead now.

Do you remember where you saw that? Can you provide a link?


-
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 unstable after updating apache http client

2017-10-05 Thread Konstantin Kolinko
2017-10-05 14:12 GMT+03:00 Alex O'Ree :
> I ran into a strange issue the other day.  Running tomcat 7.0.81. I have a
> war file with apache http client vs 4.3.3. I was having some issues with my
> code in the war and experimented with updating the http client to 4.5.3.
> The result was bizarre.
>
> Tomcat would start as normal but stop serving http requests after the first
> request.
>
> When running in the terminal,  I couldn't stop tomcat with ctrl c. I had to
> force close it with task mgr.
>
> Is this expected?

Such DoS triggered by a simple client request is a security concern,
as the load is not proportional to the size of request.
It'd be better to send specific details to security@, not a public list
http://tomcat.apache.org/security.html

1. Take a thread dump (better: 3 of them in a sequence). What is
really going on should be visible there,
https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

2. Tomcat 7.0.82 was released a few days ago.

Best regards,
Konstantin Kolinko

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



Bug 45014 - Request and Response classes should have wrappers for use in Valves

2017-10-05 Thread Amit Pande
https://bz.apache.org/bugzilla/show_bug.cgi?id=45014


Any plans/thoughts on merging Chris' mod in Tomcat 9.x branch?

It is really a nice to have built in support for Valves to have wrapper classes 
for Request and Response.

We also had a requirement to read the request payload at a valve level (to make 
it application independent) which essentially meant wrapping the request body 
to make it available to subsequent components.

But, no built-in support meant we had to move the implementation at a filter 
level.

Thanks,
Amit


Re: Tomcat unstable after updating apache http client

2017-10-05 Thread Alex O'Ree
Ill see if I can make a test war they'd reduces it to the minium.

On Oct 5, 2017 8:04 AM, "Mark Thomas"  wrote:

On 05/10/17 12:12, Alex O'Ree wrote:
> I ran into a strange issue the other day.  Running tomcat 7.0.81. I have a
> war file with apache http client vs 4.3.3. I was having some issues with
my
> code in the war and experimented with updating the http client to 4.5.3.
> The result was bizarre.
>
> Tomcat would start as normal but stop serving http requests after the
first
> request.
>
> When running in the terminal,  I couldn't stop tomcat with ctrl c. I had
to
> force close it with task mgr.
>
> Is this expected?

No, not at all. Can you create a test war that demonstrates the issue?

Mark

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


RE: ISAPI and IIS 10 Logging Issue

2017-10-05 Thread Thomas, Michael
--
On 06.09.2017 22:07, Thomas, Michael wrote:
>
> --
>> On 01.09.2017 22:21, Thomas, Michael wrote:
>>> All,
>>>
>>> When using the ISAPI Handler Mapping in IIS 10 on Windows 2016, the IIS 
>>> logs are not identifying the URI Stem (cs-uri-stem) and URI Query 
>>> (cs-uri-query) as expected.  For EVERY request that the handler processes 
>>> (e.g. .cfm), the cs-uri-stem records an entry as 
>>> "/jakarta/isapi_redirect.dll" and the cs-uri-query is always empty.
>>>
>>> Environment Details:
>>>
>>> * IIS 10 (Windows 2016)
>>>
>>> * Tomcat 8.5.11.0
>>>
>>> * Java 1.8.0_131
>>>
>>> * ISAPI Connector 1.2.41
>>>
>>> * ColdFusion 2016
>>>
>>> For comparison, we have a similar setup on another box (IIS 8.5 Windows 
>>> Server 2012 R2) and the logs are recording as expected.
>>>
>>> Any assistance would be great!
>>>
>>
>
>
>
> --
>> On 01.09.2017 22:37, Warnier, Andre wrote
>>> Hi.
>>>
>>> If I understand this correctly, the difference between your two setups 
>>> above is at the Windows/IIS level, not at the tomcat/ISAPI-redirector level.
>>>
>>> This may be naive, but isn't this a question then for the Windows/IIS 
>>> people ?
>>
>
> --
>> On 05.09.2017 22:42, Thomas, Michael wrote:
>> Andre, you're right.  Perhaps this is a good question for the Windows folks. 
>>  I guess I was hoping that someone in this community has seen this issue 
>> before and had a recommended solution.
>>
>> It is really challenging to not know what traffic your IIS Web Server is 
>> actually seeing.  There are of course other avenues (e.g. firewall logs, 
>> siem logs, etc) but the IIS logs are native to the boxes themselves and much 
>> easier to analyze.  I was curious if the ISAPI Connector returned a specific 
>> URL back to IIS and it could be tweaked.  Not sure if IIS is expecting a 
>> response in a certain format, etc.
>>
>> Is there documentation that I can look at for what the ISAPI module should 
>> return to IIS?  Anyone have any insight into that pipeline?
>
>
>
> --
>> On 06.09.2017 00:41, Warnier, Andre wrote
>>
>> First, about your last question above : I don't know, and I guess that the 
>> right people for that on this list would be Rainer or Mladen.
>>
>> But second, I believe that the terminology you are using above is a bit 
>> confusing, from the point of view of the logic of the thing, particularly 
>> when you mention "what the ISAPI module should return to IIS".
>>
>> IIS is the front-end, and it gets the client HTTP request first (URL, 
>> headers and all).
>> So it /has/ all the information needed to log whatever, should it choose to 
>> do so (*).
>>
>> In a second step, IIS examines the request URL and, maybe with the help of 
>> the isapi_redirector, it determines that to properly answer this request, it 
>> should not use its own internal machinery, but it should delegate this to 
>> the isapi_redirector module.
>> What the isapi_redirector module does with the request, is none of IIS's 
>> business, so to speak. The only thing which IIS expects back from the 
>> isapi_redirector module, is either a HTTP succesful response, or some error 
>> code.
>> So this is the only additional information for which IIS might be waiting, 
>> for logging the request (e.g. the size of the response, and/or the time 
>> needed to generate it).
>>
>> That the isapi_redirector module, to generate this HTTP response, uses a 
>> back-channel with a back-end tomcat, is unknown to IIS, and it does not 
>> care. From the IIS point of view, isapi_redirector might as well be using 
>> black magic to generate that response internally, without ever talking to 
>> anyone else.
>>
>> (*) but in your case, it doesn't do it, or does it differently than IIS 8.5 
>> or whatever earlier version did, although all the rest of the machinery did 
>> not change. So /that's/ the mystery to solve. Maybe MS changed the rules of 
>> the game (the ISAPI interface) somehow for IIS 10, and an ISAPI module is 
>> now >supposed to do something additional, to get things properly logged, 
>> that the ISAPI-redirector module does not do (yet).
>> But I think that you are still more likely to get that kind of information 
>> on an IIS-oriented forum, that on this tomcat forum.
>>
>>
>> I would ask first for example, for any IIS-10 specific changes in the 
>> logging of requests, maybe in conjunction with the usage of ISAPI filters in 
>> general.
>> (Maybe it is just your log formatting that does not invoke the right
>> items of information ?)
>
> --
> Andre, thank you for the detailed explanation.  That helps me 

Re: Tomcat unstable after updating apache http client

2017-10-05 Thread Mark Thomas
On 05/10/17 12:12, Alex O'Ree wrote:
> I ran into a strange issue the other day.  Running tomcat 7.0.81. I have a
> war file with apache http client vs 4.3.3. I was having some issues with my
> code in the war and experimented with updating the http client to 4.5.3.
> The result was bizarre.
> 
> Tomcat would start as normal but stop serving http requests after the first
> request.
> 
> When running in the terminal,  I couldn't stop tomcat with ctrl c. I had to
> force close it with task mgr.
> 
> Is this expected?

No, not at all. Can you create a test war that demonstrates the issue?

Mark

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



Tomcat unstable after updating apache http client

2017-10-05 Thread Alex O'Ree
I ran into a strange issue the other day.  Running tomcat 7.0.81. I have a
war file with apache http client vs 4.3.3. I was having some issues with my
code in the war and experimented with updating the http client to 4.5.3.
The result was bizarre.

Tomcat would start as normal but stop serving http requests after the first
request.

When running in the terminal,  I couldn't stop tomcat with ctrl c. I had to
force close it with task mgr.

Is this expected?


Re: encodeURL, jsessionid and mod_rewrite ?

2017-10-05 Thread Mark Thomas
On 4 October 2017 23:31:36 BST, Laurent Perez  wrote:
>Thanks for the replies. The jsessionid/cookie tracking mode is not
>really
>part of the problem, sorry about that.
>
>Obviously I'm thinking about renaming the war but the rewriting is
>really
>used, for example seo friendly urls like /bar/steps/1 internally
>rewrite to
>/foo/somesubmodule/steps.jsp?step=1 and the system really can't expose
>/somesubmodule/steps.jsp?step=1 as public urls, it messes with google
>analytics stats or bookmarked urls.

Rewrites are not generally problematic. It is changing the context path that 
causes all the problems. Renaming foo.war to bar.war (or equivalent for you 
config) should be sufficient.

Mark


>
>As last resort I could move the apache RewriteRules to tuckey
>urlrewriter
>under the war itself and just keep the ProxyPasses under apache.
>Configuration & docs would be in a sole space.
>
>I know that just because I /can/ do nasty rewriting stuff at the
>response
>wrapper level I may not want to do it. The replies were useful ;)
>
>regards
>
>
>On Wed, Oct 4, 2017 at 9:58 AM, André Warnier (tomcat) 
>wrote:
>
>> On 04.10.2017 07:40, Peter Kreuser wrote:
>>
>>>
>>> Peter Kreuser
>>>
>>> Am 04.10.2017 um 02:44 schrieb Christopher Schultz <
 ch...@christopherschultz.net>:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Laurant,

 On 10/3/17 5:17 PM, Laurent Perez wrote:
> I'm using apache+mod_proxy+mod_rewrite as a tomcat frontend. A
> "foo" war is deployed at /foo context path under tomcat. The /foo
> path is not public, apache has a rewrite rule defined as : /bar/*
> rewrites internally to /foo/*.
>
> I'm using jstl and its  for every url in
>my
> jsps to gain the ;jsessionid from encodeURL whenever jsessionid
> cookie is not yet set (1st requests)
>
>
>>> adding to Christopher, accepting the jsessionid from the Url is a
>bad
>>> security risk (Session fixation). So you should disable that by
>accepting
>>> the session only via COOKIE via
>>>
>>> COOKIE
>
>>> then at least this rewriting problem is gone.
>>>
>>> Peter
>>>
>>>
>> Well, a cookie can also be path-specific.  Which is only *one* of
>these
>> issues which we are talking about, when we say "don't".
>>
>>
>>
>>
>> -
>> 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