jstl jar location

2020-10-20 Thread George Stanchev

I am hoping someone can shed some lights on a question. I did try to search 
online and SO but haven't had luck in figure it out so hopefully it is a quick 
answer from the people that know that stuff. We have an uber-lib folder where 
we keep shared libraries in our TC85-hosted app. If we put jstl-1.2.jar into 
that directory but not in the application /WEB-INF/lib directory, TC generates 
[1]. If I move jstl into the application lib folder, it works. I made sure jstl 
is excluded from jarsToSkip and included in jarsToScan.

Is there any rule or switch that says that the JSP compiler cannot use the 
parent CL to resolve the jstl URIs?

George



[1]
Type Exception Report
Message The absolute uri: [http://java.sun.com/jsp/jstl/core] cannot be 
resolved in either web.xml or the jar files deployed with this application
Description The server encountered an unexpected condition that prevented it 
from fulfilling the request.
Exception
org.apache.jasper.JasperException: The absolute uri: 
[http://java.sun.com/jsp/jstl/core] cannot be resolved in either web.xml or the 
jar files deployed with this application
 
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:293)

org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:80)
org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLibraryInfoImpl.java:251)

org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:122)
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:431)
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:489)
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1445)
org.apache.jasper.compiler.Parser.parse(Parser.java:144)

org.apache.jasper.compiler.ParserController.doParse(ParserController.java:244)

org.apache.jasper.compiler.ParserController.parse(ParserController.java:105)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:203)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:335)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:168)

org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:304)

org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1286)
org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1041)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:984)
  
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)



RE: CVE-2020-1935

2020-07-27 Thread George Stanchev
Hi Mark,

Thank you for the detailed answer. I really appreciate your response. As 
someone who handles security at work I can empathize and agree with all the 
points you are making. In previous security disclosures it has been pretty easy 
for me to assess the risk of a vulnerability with either the disclosure or 
looking at the fix. This particular one is worded especially  vague because of 
the nebulous reference to an upstream 3rd party product's misconfiguration. We 
have a customer concerned about security, behind an F5 reverse proxy asking us 
if our product is going to be affected by this CVE and to explain why if not. 
Without at least basic understanding of how the issue happens, I cannot provide 
what they ask. Your explanation provides context, so again, I really appreciate 
your response. 

Cheers!

George


-Original Message-
From: Mark Thomas  
Sent: Sunday, July 26, 2020 5:09 AM
To: users@tomcat.apache.org
Subject: Re: CVE-2020-1935

George,

As an open source project with an open development process, the Tomcat security 
team has a number of challenges to deal with.

First, any commit to address a security issue will be public before the 
security issue is announced and before a release is available that includes the 
fix. We therefore have to be careful that the commit and associated log entry 
do not draw attention to the issue.

Secondly, we know that a large proportion of attacks are from "script kiddies" 
that run every attack they (or more likely the toolkit they
downloaded) know against every server they can find. We therefore do not 
provide proofs of concept, recipes for reproducing issues (we can't stop the 
original reporter producing them) or specific details of the attack where we 
can avoid doing so. Yes, a sophisticated attacker could reverse engineer some 
issues but they tend not share when they do so and - on balance - we consider 
not disclosing the details the right thing to do.

(As an aside I haven't looked at how easy issues are to reverse engineer from 
the commit that fixed them. Going from memory I can only recall that some would 
be very simple and some very unlikely. I can't recall enough information to 
determine what proportion they are in. That might be an interesting exercise.)

Thirdly, we want to provide users with enough information to determine if they 
are vulnerable without providing instructions to reproduce the issue (see 
previous point).

As I am sure you can appreciate, there is a tricky balance to strike here. As I 
wrote both the commit that fixed the issue and the vulnerability announcement, 
let me see if I can reword it in a way that is more helpful.

If the reverse proxy accepts anything other then CRLF as the end of line marker 
for an HTTP header (it shouldn't the HTTP/1.1 RFCs require CRLF for headers) 
then a request smuggling attack as described by
CVE-2020-1935 is likely to be possible.

It should be relatively simple to test what the reverse proxy accepts and 
doesn't accept. For completeness you might want to test how it responds to all 
bytes from 0x00 to OxFF in a field name and/or value as well and ensure that it 
is compliant with RFC 7230.

HTH,

Mark



On 24/07/2020 23:13, George Stanchev wrote:
> Chris,
> 
> This is just silly. The code change is there. If I am rouge actor, I can and 
> I will understand issue and try to produce exploit. With explanation like 
> this legitimate Tomcat users are left to scratch their head if they are 
> vulnerable or not especially as the explanation says that a 3rd party 
> upstream component *could* be misconfigured but does not explain how. I hope 
> you understand the absurdity of the situation and how it makes the job of 
> people like me just harder and it does not provide any additional security. I 
> hope the rest of the Tomcat team doesn't share your sentiment.
> 
> Cheers!
> 
> George
> 
> -Original Message-
> From: Christopher Schultz 
> Sent: Friday, July 24, 2020 3:40 PM
> To: users@tomcat.apache.org
> Subject: Re: CVE-2020-1935
> 
> -BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> George
> George,
> 
> On 7/24/20 15:15, George Stanchev wrote:
>> The description for this CVE is pretty vague (as perhaps
>> necessary) but we have a customer that is trying to assess their risk 
>> for this CVE.
> 
> Their risk is probably very low. Their risk of a bunch of other "important" 
> items included in later releases is probably much higher.
> 
> What's going on at this client that they are rapidly approaching an 8-month 
> delay in issuing this security patch?
> 
>> They are behind a reverse-proxy. Even though the description on 
>> Tomcat's security page states that the risk is low it doesn't 
>> describe how would a reverse-proxy mishandle the Transfer-Encoding in 
>> order to compromise the backend 

RE: CVE-2020-1935

2020-07-24 Thread George Stanchev
Chris,

This is just silly. The code change is there. If I am rouge actor, I can and I 
will understand issue and try to produce exploit. With explanation like this 
legitimate Tomcat users are left to scratch their head if they are vulnerable 
or not especially as the explanation says that a 3rd party upstream component 
*could* be misconfigured but does not explain how. I hope you understand the 
absurdity of the situation and how it makes the job of people like me just 
harder and it does not provide any additional security. I hope the rest of the 
Tomcat team doesn't share your sentiment.

Cheers!

George

-Original Message-
From: Christopher Schultz  
Sent: Friday, July 24, 2020 3:40 PM
To: users@tomcat.apache.org
Subject: Re: CVE-2020-1935

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 7/24/20 15:15, George Stanchev wrote:
> The description for this CVE is pretty vague (as perhaps
> necessary) but we have a customer that is trying to assess their risk 
> for this CVE.

Their risk is probably very low. Their risk of a bunch of other "important" 
items included in later releases is probably much higher.

What's going on at this client that they are rapidly approaching an 8-month 
delay in issuing this security patch?

> They are behind a reverse-proxy. Even though the description on 
> Tomcat's security page states that the risk is low it doesn't describe 
> how would a reverse-proxy mishandle the Transfer-Encoding in order to 
> compromise the backend Tomcat server.
It's a fairly small window of opportunity. Basically, several bugs in both the 
reverse proxy /and/ Tomcat would have to both be present in order to thread the 
needle.

> Any information about this exploit would be appreciated. (I did try to 
> read the commit but it is rather large so it would require more time 
> to unroll the fix for me than getting a direct answer)...
Nobody from the Security Team is going to explain how to exploit this or test 
to see if you are vulnerable. Sorry. :(

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8bVSUACgkQHPApP6U8
pFjXJg//Zto3QQN0sdPgl/JNCFwJTMdzQg1+OzwebLLa+epRmdkZ5HpUBTGpB5Uh
JHRHu/U1CnFUaCOUNYCix5TaqyKErODhouJlGG7uII68EqMb+xSB0qMRvr16tqrp
l32wv6PE/ehSN/1VTpWwOvctEifYAuK8CFEs4U6iOfKhPKNew/ynv2DeErD0rS9n
d8IQLGK255CWx3CiYDUT+eGCgJ1eVSVed0jZU00iADoivCK4MAWO3b6Cn66QFHLq
Qe0Siq0ZuY3BvWYOvHybtaDJiEEgLar6v/15ueslsh7q20m+SyOi+5HEikTSlUhU
Ws5PREOAJuGVk2HT9NL2OgSRtcT/zAi7WPkGaa20wOugoTB/bcPOjoT37BxpPpsB
YffsGVPiTEwlLX29jY09X/JfgyI0HWIkZVUrvIxuAdVqRyfbz4PNqSvz45HUS66X
fWnfAYPw3l6pDPWtdu0Hqc/oQtuDOyfzVLsEjgx3cCxnTY5honEVpL6Gt+P9AQQY
tlBdtEpynrvmiF2aE+dxu2GbdtjoDaHouE5eqBuA1VCFiLmMb5HHey1N6j/yLZke
ffc6IQToyCdeubgf+qGP3wC5eYUOVmy3LCZEPU/LzbckW0xF28GPCKmwZ4FyKr1W
EKMtKr25ibHJDp60DhbCD8eqGFHfWC5JGNjS0Gqkr798kf4qghU=
=dU//
-END PGP SIGNATURE-

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


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



CVE-2020-1935

2020-07-24 Thread George Stanchev
The description for this CVE is pretty vague (as perhaps necessary) but we have 
a customer that is trying to assess their risk for this CVE. They are behind a 
reverse-proxy. Even though the description on Tomcat's security page states 
that the risk is low it doesn't describe how would a reverse-proxy mishandle 
the Transfer-Encoding in order to compromise the backend Tomcat server. Any 
information about this exploit would be appreciated. (I did try to read the 
commit but it is rather large so it would require more time to unroll the fix 
for me than getting a direct answer)...

George


RE: Tomcat Connector issue

2020-07-02 Thread George Stanchev
To give some closure to the issue, it turned out to be networking related. 
Still not clear how cleanup of the hosts file on the client machines fixed it 
but that's what happened.

Thanks to all that chimed in earlier.

George

-Original Message-
From: George Stanchev  
Sent: Monday, June 29, 2020 9:13 AM
To: Tomcat Users List 
Subject: RE: Tomcat Connector issue

I am sorry, but any ideas how to approach this? I have eliminated the 
possibility that the client is dropping the connection so it must be something 
within IIS/Win. Switching to keep_alive=true and 
HSE_REQ_SEND_RESPONSE_HEADER_EX did not make a difference.

In the logs, occasionally I  see a variation:

start_response::jk_isapi_plugin.c (1082): HSE_REQ_SEND_RESPONSE_HEADER_EX 
failed with error=1229 (0x04cd)

one time there was

iis_write::jk_isapi_plugin.c (1283): Vector write of chunk encoded response 
failed with 1229 (0x04cd)

which means the send response headers succeeded before writing the chunk. The 
responses are generated in relatively good time so timeouts are ruled out...

All things point to connID being dropped/invalid but I can put a finger on 
anything. The only thing I that pops on Google is an old post about having to 
adjust responseBufferLimit=0 in IIS that might cause those errors. I think I 
have ruled out external firewall/intermediary dropping the connection on the 
client side. I know they have FIPS enabled on the Windows side but I cannot 
imagine that would make a difference. Calls to other virtual directories under 
that site do not exhibit this behavior. Interestingly the same is observed 
under othe OSes (Windows Server 2012) procured with their scrips...

Any help/ideas is much appreciated

George

-Original Message-
From: George Stanchev 
Sent: Tuesday, June 23, 2020 10:31 AM
To: Tomcat Users List 
Subject: RE: Tomcat Connector issue

Thanks all for the responses. It is on AWS VM machine that I don't have access 
to. I've googed the crap of x57 but besides some Bugzilla report from Adobe 
that seemed unrelated nothing good comes out of Google. x57 as Mark said is bad 
parameter and it is a generic error meaning either the p->lpEcb->ConnID is 
invalid or something is wrong with the headers or their sizes. Also chunking is 
off so keep-alive is JK_FALSE. I can try to enable the chunking to see if I can 
fork the execution into the HSE_REQ_SEND_RESPONSE_HEADER_EX call on 
jk_isapi_plugin.c#1066 and if it would make a difference. The headers from TC 
on the 302 response are pretty vanilla and I cannot imagine headers+sizes are 
wrong which leaves p->lpEcb->ConnID. I have omitted the actual binary dump of 
the AJP message because it is from a customer and didn't want to disclose their 
hostname but I can obfuscate it and post it if we think it is related to the 
issue.

For now forking into the _EX call is the only idea I have to explore...

Asked to procur another VM image in case something is wrong with IIS but it is 
a problem for them...

Any ideas on how to even approach this are much appreciated...

George

-Original Message-
From: Mark Thomas 
Sent: Tuesday, June 23, 2020 9:42 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Connector issue

On 23/06/2020 16:35, Christopher Schultz wrote:
> 
> 
> On 6/23/20 11:32, Mark Thomas wrote:
>> On 23/06/2020 16:20, Christopher Schultz wrote:
>>> George,
>>>
>>> On 6/22/20 17:13, George Stanchev wrote:
>>>> We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with
>>>> error=87 (0x0057) on a 302 redirect proxied by TC connector 
>>>> 1.2.46.
>>> Windows error 0x0057 is ... "Cannot connect to printer"???
> 
>> Not sure where you found that. 0x57 is "Invalid Parameter"
> 
> Yeah, it sounded weird. Searching Google for "windows 0x0057" (at 
> least here in the US) gives a million pages about errors connecting to 
> printers, like this one which is the top-hit for me with expanded
> explanation:
> 
> https://appuals.com/fix-printer-error-0x0057/
> 
> "
> Error 0x0057 is a printer related error on Windows which does not 
> allow the user to add the printer. This error is usually due to 
> corrupt drivers previously installed and the permission issues. ...
> The 1st one would delete the driver and the second method would be to 
> copy the driver from a working computer.
> "
> 
> I don't have a "perror" program for Windows handy right now, so I just 
> tried Google :/

For the archives:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

Mark

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

RE: Tomcat Connector issue

2020-06-29 Thread George Stanchev
I am sorry, but any ideas how to approach this? I have eliminated the 
possibility that the client is dropping the connection so it must be something 
within IIS/Win. Switching to keep_alive=true and 
HSE_REQ_SEND_RESPONSE_HEADER_EX did not make a difference.

In the logs, occasionally I  see a variation:

start_response::jk_isapi_plugin.c (1082): HSE_REQ_SEND_RESPONSE_HEADER_EX 
failed with error=1229 (0x04cd)

one time there was

iis_write::jk_isapi_plugin.c (1283): Vector write of chunk encoded response 
failed with 1229 (0x04cd)

which means the send response headers succeeded before writing the chunk. The 
responses are generated in relatively good time so timeouts are ruled out...

All things point to connID being dropped/invalid but I can put a finger on 
anything. The only thing I that pops on Google is an old post about having to 
adjust responseBufferLimit=0 in IIS that might cause those errors. I think I 
have ruled out external firewall/intermediary dropping the connection on the 
client side. I know they have FIPS enabled on the Windows side but I cannot 
imagine that would make a difference. Calls to other virtual directories under 
that site do not exhibit this behavior. Interestingly the same is observed 
under othe OSes (Windows Server 2012) procured with their scrips...

Any help/ideas is much appreciated

George

-Original Message-
From: George Stanchev  
Sent: Tuesday, June 23, 2020 10:31 AM
To: Tomcat Users List 
Subject: RE: Tomcat Connector issue

Thanks all for the responses. It is on AWS VM machine that I don't have access 
to. I've googed the crap of x57 but besides some Bugzilla report from Adobe 
that seemed unrelated nothing good comes out of Google. x57 as Mark said is bad 
parameter and it is a generic error meaning either the p->lpEcb->ConnID is 
invalid or something is wrong with the headers or their sizes. Also chunking is 
off so keep-alive is JK_FALSE. I can try to enable the chunking to see if I can 
fork the execution into the HSE_REQ_SEND_RESPONSE_HEADER_EX call on 
jk_isapi_plugin.c#1066 and if it would make a difference. The headers from TC 
on the 302 response are pretty vanilla and I cannot imagine headers+sizes are 
wrong which leaves p->lpEcb->ConnID. I have omitted the actual binary dump of 
the AJP message because it is from a customer and didn't want to disclose their 
hostname but I can obfuscate it and post it if we think it is related to the 
issue.

For now forking into the _EX call is the only idea I have to explore...

Asked to procur another VM image in case something is wrong with IIS but it is 
a problem for them...

Any ideas on how to even approach this are much appreciated...

George

-Original Message-
From: Mark Thomas 
Sent: Tuesday, June 23, 2020 9:42 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Connector issue

On 23/06/2020 16:35, Christopher Schultz wrote:
> 
> 
> On 6/23/20 11:32, Mark Thomas wrote:
>> On 23/06/2020 16:20, Christopher Schultz wrote:
>>> George,
>>>
>>> On 6/22/20 17:13, George Stanchev wrote:
>>>> We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with
>>>> error=87 (0x0057) on a 302 redirect proxied by TC connector 
>>>> 1.2.46.
>>> Windows error 0x0057 is ... "Cannot connect to printer"???
> 
>> Not sure where you found that. 0x57 is "Invalid Parameter"
> 
> Yeah, it sounded weird. Searching Google for "windows 0x0057" (at 
> least here in the US) gives a million pages about errors connecting to 
> printers, like this one which is the top-hit for me with expanded
> explanation:
> 
> https://appuals.com/fix-printer-error-0x0057/
> 
> "
> Error 0x0057 is a printer related error on Windows which does not 
> allow the user to add the printer. This error is usually due to 
> corrupt drivers previously installed and the permission issues. ...
> The 1st one would delete the driver and the second method would be to 
> copy the driver from a working computer.
> "
> 
> I don't have a "perror" program for Windows handy right now, so I just 
> tried Google :/

For the archives:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

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 Connector issue

2020-06-23 Thread George Stanchev
Is it possible something is wrong with the header values

[Thu Jun 18 09:37:28.229 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[0] 
[Expires] = [19-Mar-1971 08:23:00 GMT]
[Thu Jun 18 09:37:28.229 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[1] 
[Cache-Control] = [no-store, no-cache, private, must-revalidate]
[Thu Jun 18 09:37:28.230 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[2] 
[Pragma] = [no-cache]
[Thu Jun 18 09:37:28.231 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[3] 
[Location] = 
[https://host/idp/login?fsid=2baf82dbd9e74657988568e2ae98ceef=https%3A%2F%2Fhost%2Fworkcenter%2Ftmtrack.dll%3Fshell%3Dswc]
[Thu Jun 18 09:37:28.232 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[4] 
[Content-Length] = [0]


This is pretty standard, I can't see anything wrong...

-Original Message-
From: George Stanchev 
Sent: Tuesday, June 23, 2020 10:33 AM
To: users@tomcat.apache.org
Subject: RE: Tomcat Connector issue

Thanks all for the responses. It is on AWS VM machine that I don't have access 
to. I've googed the crap of x57 but besides some Bugzilla report from Adobe 
that seemed unrelated nothing good comes out of Google. x57 as Mark said is bad 
parameter and it is a generic error meaning either the p->lpEcb->ConnID is 
invalid or something is wrong with the headers or their sizes. Also chunking is 
off so keep-alive is JK_FALSE. I can try to enable the chunking to see if I can 
fork the execution into the HSE_REQ_SEND_RESPONSE_HEADER_EX call on 
jk_isapi_plugin.c#1066 and if it would make a difference. The headers from TC 
on the 302 response are pretty vanilla and I cannot imagine headers+sizes are 
wrong which leaves p->lpEcb->ConnID. I have omitted the actual binary dump of 
the AJP message because it is from a customer and didn't want to disclose their 
hostname but I can obfuscate it and post it if we think it is related to the 
issue.

For now forking into the _EX call is the only idea I have to explore...

Asked to procur another VM image in case something is wrong with IIS but it is 
a problem for them...

Any ideas on how to even approach this are much appreciated...

George

-Original Message-
From: Mark Thomas 
Sent: Tuesday, June 23, 2020 9:42 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Connector issue

On 23/06/2020 16:35, Christopher Schultz wrote:
> 
> 
> On 6/23/20 11:32, Mark Thomas wrote:
>> On 23/06/2020 16:20, Christopher Schultz wrote:
>>> George,
>>>
>>> On 6/22/20 17:13, George Stanchev wrote:
>>>> We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with
>>>> error=87 (0x0057) on a 302 redirect proxied by TC connector 
>>>> 1.2.46.
>>> Windows error 0x0057 is ... "Cannot connect to printer"???
> 
>> Not sure where you found that. 0x57 is "Invalid Parameter"
> 
> Yeah, it sounded weird. Searching Google for "windows 0x0057" (at 
> least here in the US) gives a million pages about errors connecting to 
> printers, like this one which is the top-hit for me with expanded
> explanation:
> 
> https://appuals.com/fix-printer-error-0x0057/
> 
> "
> Error 0x0057 is a printer related error on Windows which does not 
> allow the user to add the printer. This error is usually due to 
> corrupt drivers previously installed and the permission issues. ...
> The 1st one would delete the driver and the second method would be to 
> copy the driver from a working computer.
> "
> 
> I don't have a "perror" program for Windows handy right now, so I just 
> tried Google :/

For the archives:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

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 Connector issue

2020-06-23 Thread George Stanchev
Thanks all for the responses. It is on AWS VM machine that I don't have access 
to. I've googed the crap of x57 but besides some Bugzilla report from Adobe 
that seemed unrelated nothing good comes out of Google. x57 as Mark said is bad 
parameter and it is a generic error meaning either the p->lpEcb->ConnID is 
invalid or something is wrong with the headers or their sizes. Also chunking is 
off so keep-alive is JK_FALSE. I can try to enable the chunking to see if I can 
fork the execution into the HSE_REQ_SEND_RESPONSE_HEADER_EX call on 
jk_isapi_plugin.c#1066 and if it would make a difference. The headers from TC 
on the 302 response are pretty vanilla and I cannot imagine headers+sizes are 
wrong which leaves p->lpEcb->ConnID. I have omitted the actual binary dump of 
the AJP message because it is from a customer and didn't want to disclose their 
hostname but I can obfuscate it and post it if we think it is related to the 
issue.

For now forking into the _EX call is the only idea I have to explore...

Asked to procur another VM image in case something is wrong with IIS but it is 
a problem for them...

Any ideas on how to even approach this are much appreciated...

George

-Original Message-
From: Mark Thomas  
Sent: Tuesday, June 23, 2020 9:42 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat Connector issue

On 23/06/2020 16:35, Christopher Schultz wrote:
> 
> 
> On 6/23/20 11:32, Mark Thomas wrote:
>> On 23/06/2020 16:20, Christopher Schultz wrote:
>>> George,
>>>
>>> On 6/22/20 17:13, George Stanchev wrote:
>>>> We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with
>>>> error=87 (0x0057) on a 302 redirect proxied by TC connector 
>>>> 1.2.46.
>>> Windows error 0x0057 is ... "Cannot connect to printer"???
> 
>> Not sure where you found that. 0x57 is "Invalid Parameter"
> 
> Yeah, it sounded weird. Searching Google for "windows 0x0057" (at 
> least here in the US) gives a million pages about errors connecting to 
> printers, like this one which is the top-hit for me with expanded
> explanation:
> 
> https://appuals.com/fix-printer-error-0x0057/
> 
> "
> Error 0x0057 is a printer related error on Windows which does not 
> allow the user to add the printer. This error is usually due to 
> corrupt drivers previously installed and the permission issues. ...
> The 1st one would delete the driver and the second method would be to 
> copy the driver from a working computer.
> "
> 
> I don't have a "perror" program for Windows handy right now, so I just 
> tried Google :/

For the archives:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

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



Tomcat Connector issue

2020-06-22 Thread George Stanchev
We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with error=87 (0x0057) 
on a 302 redirect proxied by TC connector 1.2.46. I can see the 302 response 
come over from TC and it looks legit. Trace logs below. Anyone else running 
into a similar error or perhaps some clue as to why this can be happening?



[Thu Jun 18 09:37:28.185 2020] [6060:2544] [trace] 
jk_tcp_socket_sendfull::jk_connect.c (1042): enter
[Thu Jun 18 09:37:28.186 2020] [6060:2544] [trace] 
jk_tcp_socket_sendfull::jk_connect.c (1072): exit
[Thu Jun 18 09:37:28.187 2020] [6060:2544] [trace] 
ajp_connection_tcp_send_message::jk_ajp_common.c (1292): exit
[Thu Jun 18 09:37:28.188 2020] [6060:2544] [debug] 
ajp_send_request::jk_ajp_common.c (1768): (worker-local) Statistics about 
invalid connections: connect check (0), cping (0), send (0)
[Thu Jun 18 09:37:28.188 2020] [6060:2544] [debug] 
ajp_send_request::jk_ajp_common.c (1779): (worker-local) request body to send 0 
- request body to resend 0
[Thu Jun 18 09:37:28.189 2020] [6060:2544] [trace] 
ajp_send_request::jk_ajp_common.c (1904): exit
[Thu Jun 18 09:37:28.190 2020] [6060:2544] [trace] 
ajp_get_reply::jk_ajp_common.c (2201): enter
[Thu Jun 18 09:37:28.191 2020] [6060:2544] [trace] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1325): enter
[Thu Jun 18 09:37:28.193 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1093): enter
[Thu Jun 18 09:37:28.199 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1122): exit
[Thu Jun 18 09:37:28.200 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1093): enter
[Thu Jun 18 09:37:28.202 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1122): exit
[Thu Jun 18 09:37:28.203 2020] [6060:2544] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1459): received from ajp13 
pos=0 len=307 max=16384
..
[Thu Jun 18 09:37:28.223 2020] [6060:2544] [trace] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1463): exit
[Thu Jun 18 09:37:28.224 2020] [6060:2544] [trace] 
ajp_process_callback::jk_ajp_common.c (1919): enter
[Thu Jun 18 09:37:28.225 2020] [6060:2544] [trace] 
ajp_unmarshal_response::jk_ajp_common.c (718): enter
[Thu Jun 18 09:37:28.226 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (736): (worker-local) status = 302
[Thu Jun 18 09:37:28.228 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (743): Number of headers is = 5
[Thu Jun 18 09:37:28.229 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[0] 
[Expires] = [19-Mar-1971 08:23:00 GMT]
[Thu Jun 18 09:37:28.229 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[1] 
[Cache-Control] = [no-store, no-cache, private, must-revalidate]
[Thu Jun 18 09:37:28.230 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[2] 
[Pragma] = [no-cache]
[Thu Jun 18 09:37:28.231 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[3] 
[Location] = 
[https://host/idp/login?fsid=2baf82dbd9e74657988568e2ae98ceef=https%3A%2F%host%2Fworkcenter%2Ftmtrack.dll%3Fshell%3Dswc]
[Thu Jun 18 09:37:28.232 2020] [6060:2544] [debug] 
ajp_unmarshal_response::jk_ajp_common.c (799): (worker-local) Header[4] 
[Content-Length] = [0]
[Thu Jun 18 09:37:28.233 2020] [6060:2544] [trace] 
ajp_unmarshal_response::jk_ajp_common.c (806): exit
[Thu Jun 18 09:37:28.234 2020] [6060:2544] [trace] 
start_response::jk_isapi_plugin.c (889): enter
[Thu Jun 18 09:37:28.235 2020] [6060:2544] [debug] 
start_response::jk_isapi_plugin.c (939): Starting response for URI '/idp/login' 
(protocol HTTP/1.1)
[Thu Jun 18 09:37:28.236 2020] [6060:2544] [debug] 
start_response::jk_isapi_plugin.c (1048): Not using Keep-Alive
[Thu Jun 18 09:37:28.237 2020] [6060:2544] [error] 
start_response::jk_isapi_plugin.c (1082): HSE_REQ_SEND_RESPONSE_HEADER failed 
with error=87 (0x0057)
[Thu Jun 18 09:37:28.238 2020] [6060:2544] [trace] 
start_response::jk_isapi_plugin.c (1092): exit
[Thu Jun 18 09:37:28.239 2020] [6060:2544] [trace] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1325): enter
[Thu Jun 18 09:37:28.240 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1093): enter
[Thu Jun 18 09:37:28.241 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1122): exit
[Thu Jun 18 09:37:28.242 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1093): enter
[Thu Jun 18 09:37:28.243 2020] [6060:2544] [trace] 
jk_tcp_socket_recvfull::jk_connect.c (1122): exit
[Thu Jun 18 09:37:28.244 2020] [6060:2544] [debug] 
ajp_connection_tcp_get_message::jk_ajp_common.c (1459): received from ajp13 
pos=0 len=2 max=16384


TLS key management

2019-11-11 Thread George Stanchev
Currently, (in most cases) Tomcat creates an in-memory keystore and initializes 
kmf as follows: KeyManagementFactory.getInstance(algo).init(keystore, kspass). 
The in-memory keystore has the key, the certificate and the chain and nothing 
else. This works fine in most cases but we've ran into a situation where this 
is not sufficient. I am running TC with BC as JSSE provider in FIPS-approved 
only mode and in certain use cases we're running into issues with RSA key 
reuse. FIPS states that an RSA key should be used for encryption/decryption or 
for signature/verification but not for both. So when one browser (in our case 
it was FF) selects TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, BC's key manager 
marks and remembers the key usage, then another browser (Chrome) settles for 
TLS_RSA_WITH_AES_128_GCM_SHA256 BC throws an key-reuse exception since the 
latter suite uses RSA for key exchange and the former for authentication. The 
BC key manager has the ability to select a different key based on KeyUsage 
extension, so it is possible to have multiple RSA keys in memory that would be 
used according to their certificates KeyUsage policy. However TC feeds only one 
certificate to the KM.

Here is a thread [1] that I ran into that shows someone else running into the 
issue and response from BC developer.

To be fair, BCFIPS does have a -D override for the key usage override for RSA 
keys in approved-only mode but according to this thread [2], the property is 
there for completely different purpose and running it to get around the TC 
issue is not FIPS compliant.

So having looked at the code in SSLUtilBase#getKeyManagers(), is it worth 
opening a BZ request to have some solution to this issue - perhaps if alias is 
omitted in configuration and the keystore is of transferrable type (not ms, 
hardware, etc) then transfer all entries to the KM and let it do the selection?

George


[1] 
http://bouncy-castle.1462172.n4.nabble.com/Using-different-cipher-suites-in-a-BCFIPS-JDK-triggers-RSA-key-reuse-td4659354.html
[2] 
http://bouncy-castle.1462172.n4.nabble.com/Modulus-reuse-in-FIPS-td4659219.html


building tcnative

2019-11-07 Thread George Stanchev
I am trying to build tcnative on Windows 7 using VS 2017 and it has been 
nothing but pain so far around the apr and tcnative itself. Any help is 
appreciated. I did get around the apr issues (which were very similar to what I 
am about to ask) by compiling via the .sln file. But the nmake route would 
simply not go with an error similar to the one below. One solution found on the 
internet [1] was to search replace #define _WIN32_WINNT with 0x0600 in 
/arp/include/arp.hw which I did but that still didn't fix the issue so I went 
the .sln file route (which still had to be adjusted to the correct target win 
SDK to find winsock2.h). Now I am stuck with the error below. I've googled that 
stuff to death and haven't been able to find a solution. What is the Tomcat 
team using to build tcnative on Windows? VS 2015?

Any pointers to get around this issue?


cl -c -nologo -DWIN32 -D_WIN32 -D_WINDOWS -DWINNT -D_WINNT 
-D_WIN32_WINNT=0x0700 -DWINVER=0x0700 -D_WIN32_IE=0x0800 -DPSAPI_VERSION=1 -W3 
-EHsc -D_MBCS -DMBCS -D_AMD64_=1 -DWIN64 -D_WIN64 -O2 -Ob2 -Zi -DNDEBUG -D_MT 
-MD -DAPR_DECLARE_STATIC -DZLIB_WINA
PI -DNO_IDEA -DNO_RC5 -DNO_MDC2 -DOPENSSL_NO_IDEA  -DOPENSSL_NO_RC5 
-DOPENSSL_NO_MDC2 -DHAVE_OPENSSL -DHAVE_SSL_SET_STATE=1 -I.\include -I 
"C:\Java\jdk8u232zulu\include" -I "C:\Java\jdk8u232zulu\include\win32" 
-Id:\builds\deps\apr\include -Id:\builds\deps\apr\
include\arch\win32 -Id:\builds\deps\openssl\include -FoWIN7_X64_DLL_RELEASE\ 
-FdWIN7_X64_DLL_RELEASE\tcnative-1-src .\os\win32\registry.c
registry.c
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2143: syntax 
error: missing ')' before '*'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2143: syntax 
error: missing '{' before '*'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2059: syntax 
error: ')'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2061: syntax 
error: identifier 'apr_winapi_pfn_if_indextoname'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2059: syntax 
error: ';'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2513: ' ': 
no variable declared before '='
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2065: 
'apr_winapi_pfn_if_indextoname': undeclared identifier
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): warning C4047: '=': 
'int' differs in levels of indirection from 'int *(__cdecl 
*)(NET_IFINDEX,PCHAR)'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2146: syntax 
error: missing ';' before identifier 'apr_load_dll_func'
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2100: 
illegal indirection
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): error C2064: term 
does not evaluate to a function taking 19 arguments
d:\builds\deps\apr\include\arch\win32\apr_arch_misc.h(503): warning C4033: 
'apr_winapi_if_indextoname' must return a value
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\cl.EXE"' : 
return code '0x2'
Stop.


RE: Client Cert TLS issue

2019-11-01 Thread George Stanchev
Thanks Mark, will do!

-Original Message-
From: Mark Thomas  
Sent: Thursday, October 31, 2019 3:04 PM
To: Tomcat Users List ; George Stanchev 

Subject: Re: Client Cert TLS issue

On 16/10/2019 18:55, George Stanchev wrote:

> And this is not where it hangs. I stepped through the code through the 
> handshaker but still haven't been able to figure out the hang point as I am 
> not familiar with the details of that portion of TC code . I've attached two 
> cacerts that you can plug in as truststore to try out the issue.

George,

The mailing list strips most attachments. Please open a BZ issue for this. One, 
that means it won't get forgotten and two you will be able to attach those 
cacert files so we can easily reproduce the issue you are seeing.

Thanks,

Mark



RE: tomcat service app

2019-10-30 Thread George Stanchev
My question about the source stays, but I guess I should've RTFM where it 
states that the wrapper uses # *or* ; as separator and if you want to embed 
those character you need to wrap them in single quotes...

From: George Stanchev
Sent: Wednesday, October 30, 2019 1:33 PM
To: Tomcat Users List 
Subject: tomcat service app

I am trying to troubleshoot an issue where when I call tomcat8.exe with 
following parameters it writes [2] to the registry (newline where the semicolon 
was) and I am having trouble locating the source code repository for the 
Windows service app. Can someone point me to it? (Or tell me what I've done 
wrong with that property value)

George


[1] tomcat.exe //US//SbmTomcat --Jvm "C:\Program 
Files\myapp\jre1.8\bin\server\jvm.dll" --JvmOptions 
"...#-Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext;C:\Program 
Files\myapp\jre1.8\lib\ext.fips#..."
[2]
...
-D Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext
C:\Program Files\myapp\jre1.8\lib\ext.fips


tomcat service app

2019-10-30 Thread George Stanchev
I am trying to troubleshoot an issue where when I call tomcat8.exe with 
following parameters it writes [2] to the registry (newline where the semicolon 
was) and I am having trouble locating the source code repository for the 
Windows service app. Can someone point me to it? (Or tell me what I've done 
wrong with that property value)

George


[1] tomcat.exe //US//SbmTomcat --Jvm "C:\Program 
Files\myapp\jre1.8\bin\server\jvm.dll" --JvmOptions 
"...#-Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext;C:\Program 
Files\myapp\jre1.8\lib\ext.fips#..."
[2]
...
-D Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext
C:\Program Files\myapp\jre1.8\lib\ext.fips


RE: Client Cert TLS issue

2019-10-20 Thread George Stanchev
Thanks Mark,

I was going to try to build tcnative with debug this weekend to try to help out 
but life begged to disagree...i will try to step in that code next week as 
well...

Appreciate it!

George

-Original Message-
From: Mark Thomas  
Sent: Sunday, October 20, 2019 2:38 PM
To: users@tomcat.apache.org
Subject: Re: Client Cert TLS issue

Just a note to say I haven't forgotten this. I hope to look at this this week 
unless someone beats me to it.

Mark


On 16/10/2019 17:55, George Stanchev wrote:
> 
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
>> I would need some help with tracking an issue with TC 8.5.47 (windows x64, 
>> java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple 
>> client tries to connect to the server, the server hangs on SSL handshake 
>> until either the client times out on read or the server times out (if I set 
>> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I 
>> have enabled the client side SSL trace and everything goes well until ECDH 
>> key exchange (for brevity I have enabled only one TLS suite 
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if 
>> requested. The cacerts we use is whatever comes with Azul's Java distro 
>> which has ~150 entries + the custom cert for testing. The issue comes from 
>> how the connector deals with trusted certs because if I reduce the cacerts 
>> to contain only the test certificate, the request is being served without an 
>> issue. Also if I remove the tcnative-1.dll from TC there is no issue either.
>>
>> Perhaps I am missing something. Any help is appreciated.
> 
> 
> This sounds like it is repeatable and that you have a system you can test 
> with. On that basis here are a few things to try:
> 
> 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake 
> is hanging.
> 
> 2. Try a binary search to try and determine if the issue is the number of 
> certificates in the trust store or is caused by a specific certificate.
> 
> It sounds like there might be an issue converting one or more of the trusted 
> certs in the trust store to a format OpenSSL can work with.
> 
> 
> 
> So the thread dumps didn't prove to be very useful - at least I couldn't see 
> anything. I attached one of them  (dump3.txt). But the trial and error in the 
> binary searched proved it is not any certificate but a magic number of 
> certificates in cacerts - 125 hang and 124 work. I don't know if it is a 
> memory issue or buffer size issue - I tried removing and adding random certs 
> around the 124/125 boundary and which one is out and in doesn't make a 
> difference. I realize that a cert is rather large blob so it still could be 
> memory issue with the size of the cert doesn't matter that much. In 
> 8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
>  tms, sr) we pass the DER-encoded certs to OpenSSL:
> 
> // Pass along the DER encoded certificates of the accepted 
> client
> // certificate issuers, so that their subjects can be 
> presented
> // by the server during the handshake to allow the client 
> choosing
> // an acceptable certificate
> for (X509Certificate caCert : 
> x509TrustManager.getAcceptedIssuers()) {
> SSLContext.addClientCACertificateRaw(ctx, 
> caCert.getEncoded());
> if (log.isDebugEnabled())
> log.debug(sm.getString("openssl.addedClientCaCert", 
> caCert.toString()));
> }
> 
> And this is not where it hangs. I stepped through the code through the 
> handshaker but still haven't been able to figure out the hang point as I am 
> not familiar with the details of that portion of TC code . I've attached two 
> cacerts that you can plug in as truststore to try out the issue.
> 
> George
> 
> 
> 
>>
>> George
>>
>> [1]
>>
>> > port="8443" SSLEnabled="true" maxHttpHeaderSize="8192" 
>> maxThreads="150" acceptCount="100" enableLookups="false" 
>> disableUploadTimeout="true"
>> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" 
>> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2" 
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> keystoreType="JKS" 
>> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit" 
>> keyAlias="jboss" URIEncod

RE: Client Cert TLS issue

2019-10-16 Thread George Stanchev
Hi Chris,

This didn't make a difference and no difference in CPU utilization was 
observed. The lockup happens before server request the client cert so you can 
drop my big fat cacerts in a TC instance create a client-cert connector, in our 
case we set the " javax.net.ssl.trustStore" to explicitly point to cacerts and 
hit it with curl -k https://localhost:8443/

George


-Original Message-
From: Christopher Schultz  
Sent: Wednesday, October 16, 2019 1:16 PM
To: users@tomcat.apache.org
Subject: Re: Client Cert TLS issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/16/19 12:55, George Stanchev wrote:
>
> On 15/10/2019 22:15, George Stanchev wrote:
>> Hi,
>>
>> I would need some help with tracking an issue with TC 8.5.47 (windows 
>> x64, java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. 
>> When a simple client tries to connect to the server, the server hangs 
>> on SSL handshake until either the client times out on read or the 
>> server times out (if I set the
>> HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I 
>> have enabled the client side SSL trace and everything goes well until 
>> ECDH key exchange (for brevity I have enabled only one TLS suite 
>> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs 
>> if requested. The cacerts we use is whatever comes with Azul's Java 
>> distro which has ~150 entries + the custom cert for testing. The 
>> issue comes from how the connector deals with trusted certs because 
>> if I reduce the cacerts to contain only the test certificate, the 
>> request is being served without an issue.
>> Also if I remove the tcnative-1.dll from TC there is no issue either.
>>
>> Perhaps I am missing something. Any help is appreciated.
>
>  This sounds like it is repeatable and that you have a 
> system you can test with. On that basis here are a few things to
> try:
>
> 1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS 
> handshake is hanging.
>
> 2. Try a binary search to try and determine if the issue is the number 
> of certificates in the trust store or is caused by a specific 
> certificate.
>
> It sounds like there might be an issue converting one or more of the 
> trusted certs in the trust store to a format OpenSSL can work with.
>
> 
>
> So the thread dumps didn't prove to be very useful - at least I 
> couldn't see anything.

Me, either.

Can you try again using:

pollerThreadCount="1"
and
acceptorThreadCount="1"

on your  to see if that changes anything?

Do you notice a spike in CPU when the connection hangs?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2nbIYACgkQHPApP6U8
pFguXQ//cFd9lOb665cZRC68AB/0p869DBPRN9Cie8EALUgHicYSdEiRCWAUofuJ
MZx8/Sds3mrB965nmfcNLWRQBBkDqVRrN39yqOMumAZeohZq9phUbGT8chsdHD8C
tI8T96bEvKIlOtHoWK9qIYoEKZQ0nKotc0Rz49xZXTNmHmIred4nmR5fCQG4R5qD
xoqXOo5wui3aN7y9VBk+sWBQh0HGpOXvGAHaQ2NbSKE6VTitiiEM92n6Dkz60wnG
QbK2KrflW5E36NdVwNvFkqR/H3WVCrABBJ6puGHAL3nmlhg/n+MTpyqd7nkg1WSU
j1U+hqxN4EHPlTcBUtaeb6DriwaQUIHNMH3h0J8H/UyfvoIRVPA570LF5Cycj7oK
zlVgVmsZIZjIzt+qP6xzKkvhXzPLpemIOheDOZO4opgPdHIXGPAI9XVzwrARxMfv
KeqyA16XrU6pM7GKvkDEnSDiMye/pPGbq/U3mnYdlRs4Lwn9PvmnzBasSXbrsg6i
qeU1v6lSWPx18/9Qq1Qyfjxfgu3SkBpvHypwdv3MNMBk6Y2Gp/pg917FyqfNvoxX
l0TaIYYf5xL6bHsxj1uopUoCnl4KxaTAaQ3qYg4+hFO3nzDNTB1k+Xu+pbuePr3U
CyaIdmM3sqN7fNIwbfQ1slXrckavl+z/ZZmTZn2zIfa1yeMmP4s=
=vkfG
-END PGP SIGNATURE-

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



RE: Client Cert TLS issue

2019-10-16 Thread George Stanchev

On 15/10/2019 22:15, George Stanchev wrote:
> Hi,
> 
> I would need some help with tracking an issue with TC 8.5.47 (windows x64, 
> java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple 
> client tries to connect to the server, the server hangs on SSL handshake 
> until either the client times out on read or the server times out (if I set 
> the HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I 
> have enabled the client side SSL trace and everything goes well until ECDH 
> key exchange (for brevity I have enabled only one TLS suite 
> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if 
> requested. The cacerts we use is whatever comes with Azul's Java distro which 
> has ~150 entries + the custom cert for testing. The issue comes from how the 
> connector deals with trusted certs because if I reduce the cacerts to contain 
> only the test certificate, the request is being served without an issue. Also 
> if I remove the tcnative-1.dll from TC there is no issue either.
> 
> Perhaps I am missing something. Any help is appreciated.


This sounds like it is repeatable and that you have a system you can test with. 
On that basis here are a few things to try:

1. Take a 3 thread dumps ~5s apart of the Tomcat process when TLS handshake is 
hanging.

2. Try a binary search to try and determine if the issue is the number of 
certificates in the trust store or is caused by a specific certificate.

It sounds like there might be an issue converting one or more of the trusted 
certs in the trust store to a format OpenSSL can work with.



So the thread dumps didn't prove to be very useful - at least I couldn't see 
anything. I attached one of them  (dump3.txt). But the trial and error in the 
binary searched proved it is not any certificate but a magic number of 
certificates in cacerts - 125 hang and 124 work. I don't know if it is a memory 
issue or buffer size issue - I tried removing and adding random certs around 
the 124/125 boundary and which one is out and in doesn't make a difference. I 
realize that a cert is rather large blob so it still could be memory issue with 
the size of the cert doesn't matter that much. In 
8.5.47-src\java\org\apache\tomcat\util\net\openssl\OpenSSLContext.java#init(kms,
 tms, sr) we pass the DER-encoded certs to OpenSSL:

// Pass along the DER encoded certificates of the accepted 
client
// certificate issuers, so that their subjects can be presented
// by the server during the handshake to allow the client 
choosing
// an acceptable certificate
for (X509Certificate caCert : 
x509TrustManager.getAcceptedIssuers()) {
SSLContext.addClientCACertificateRaw(ctx, 
caCert.getEncoded());
if (log.isDebugEnabled())
log.debug(sm.getString("openssl.addedClientCaCert", 
caCert.toString()));
}

And this is not where it hangs. I stepped through the code through the 
handshaker but still haven't been able to figure out the hang point as I am not 
familiar with the details of that portion of TC code . I've attached two 
cacerts that you can plug in as truststore to try out the issue.

George



> 
> George
> 
> [1]
> 
>  port="8443" SSLEnabled="true" maxHttpHeaderSize="8192" 
> maxThreads="150" acceptCount="100" enableLookups="false" 
> disableUploadTimeout="true"
> scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" 
> sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2" 
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> keystoreType="JKS" 
> keystoreFile="${server.conf.dir}/serena.keystore" keystorePass="changeit" 
> keyAlias="jboss" URIEncoding="UTF-8" useServerCipherSuitesOrder="true"
> ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, 
> TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, 
> TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, 
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, 
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> 

Client Cert TLS issue

2019-10-15 Thread George Stanchev
Hi,

I would need some help with tracking an issue with TC 8.5.47 (windows x64, 
java: azul 1.8.0_222) configured with [1] and tcnative-1.dll. When a simple 
client tries to connect to the server, the server hangs on SSL handshake until 
either the client times out on read or the server times out (if I set the 
HttpsURLConnection#setConnectTimeout(0) and ...#setReadTimeout(0)). I have 
enabled the client side SSL trace and everything goes well until ECDH key 
exchange (for brevity I have enabled only one TLS suite 
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"). I can provide the debug logs if 
requested. The cacerts we use is whatever comes with Azul's Java distro which 
has ~150 entries + the custom cert for testing. The issue comes from how the 
connector deals with trusted certs because if I reduce the cacerts to contain 
only the test certificate, the request is being served without an issue. Also 
if I remove the tcnative-1.dll from TC there is no issue either.

Perhaps I am missing something. Any help is appreciated.

George

[1]





RE: [OT] TLSv1.3 in TC8.5 + Azul Java 8

2019-08-06 Thread George Stanchev
So it seems to work. For whoever is interested to try, the openjsse comes 
prebundled with Azul's distro, all you need to do is run with -XX:+UseOpenJSSE 
command line option. On TC side, I added "TLSv1.3" to "sslEnabledProtocols":

sslEnabledProtocols="+TLSv1 +TLSv1.1 +TLSv1.2 +TLSv1.3"

Also not sure if I had to but also added the 1.3 ciphers under ciphers 
attribute:

ciphers="TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, 
TLS_CHACHA20_POLY1305_SHA256,"

I am getting some socket warnings though [1]. Anyone knows if those are benign?

George


[1]

ERROR 2019-08-02 13:25:31,425 [SYSERR] -- [] 
javax.net.ssl|DEBUG|01|main|2019-08-02 13:24:51.000 
MDT|SSLCipher.java:436|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding KeyUpdate 
2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
javax.net.ssl|DEBUG|03|Finalizer|2019-08-02 13:24:51.228 
MDT|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|WARNING|03|Finalizer|2019-08-02 13:24:51.230 
MDT|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
  java.net.SocketException: Socket is not connected
at java.net.Socket.shutdownOutput(Socket.java:1553)
at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(BaseSSLSocketImpl.java:233)
at 
org.openjsse.sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:561)
at 
org.openjsse.sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)
at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.finalize(BaseSSLSocketImpl.java:276)
at java.lang.System$2.invokeFinalize(System.java:1270)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:102)
at java.lang.ref.Finalizer.access$100(Finalizer.java:34)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:217)}

)
javax.net.ssl|DEBUG|03|Finalizer|2019-08-02 13:24:51.230 
MDT|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|WARNING|03|Finalizer|2019-08-02 13:24:51.230 
MDT|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
  java.net.SocketException: Socket is not connected
at java.net.Socket.shutdownOutput(Socket.java:1553)
at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(BaseSSLSocketImpl.java:233)
at 
org.openjsse.sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:561)
at 
org.openjsse.sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)
at 
org.openjsse.sun.security.ssl.BaseSSLSocketImpl.finalize(BaseSSLSocketImpl.java:276)
at java.lang.System$2.invokeFinalize(System.java:1270)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:102)
at java.lang.ref.Finalizer.access$100(Finalizer.java:34)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:217)}

)
javax.net.ssl|DEBUG|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.164 
MDT|SSLExtensions.java:132|Ignore unknown or unsupported extension (
"unknown extension (13,172)": {

}
)
javax.net.ssl|DEBUG|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.164 
MDT|SSLExtensions.java:132|Ignore unknown or unsupported extension (
"unknown extension (22)": {

}
)
javax.net.ssl|DEBUG|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.164 
MDT|SSLExtensions.java:132|Ignore unknown or unsupported extension (
"unknown extension (49)": {

}
)
javax.net.ssl|WARNING|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.169 
MDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by 
the underlying providers
javax.net.ssl|WARNING|3E|https-jsse-nio-8243-exec-2|2019-08-02 13:25:31.169 
MDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by 
the underlying providers


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



RE: [OT] TLSv1.3 in TC8.5 + Azul Java 8

2019-08-02 Thread George Stanchev
Chris,

We have done several product releases on Azul, also running our SaaS instances 
without any issues. Granted, we're Windows-only product but I know other 
products within my company that switched to it from Oracle's Java that have not 
had any issues. When Oracle changed its license agreement for Java last year we 
were given two vendors that are allowed to be used - Azul and AdoptOpenJDK. 
Azul so far has been more consistent and timely in its releases where we found 
AOJ somewhat lagging (they had issues with certificates, file signatures and 
DLL properties identifying the vendor in the past) . We do use AOJ for 
Java+OpenJ9 VM distros though...

George

-Original Message-
From: Christopher Schultz  
Sent: Thursday, August 01, 2019 5:48 PM
To: users@tomcat.apache.org
Subject: Re: [OT] TLSv1.3 in TC8.5 + Azul Java 8

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 8/1/19 16:42, George Stanchev wrote:
> As of recently Azul has backported the JSSE from Java 11 into Java
> 8 [1] and it is currently offering TLSv1.3 support in its Java 8 
> distro [2].

Good for them. It's too bad Oracle is so conservative with its policies.

I have Azul on my list of "things to look into when I retire and my house is 
totally clean and my kids are finally out of the house" so of course, I'll 
never get around to it.

I'm curious about your (and others') experiences with it.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1DeiwACgkQHPApP6U8
pFipBA//fOTHrORxRD5OZqfigFAf7cACtsoYuJlAvh255BiJfybNg0pnBlDoIROE
DCLt2Q2QQcBWUG/eeBIopdv7xeEaVaLNMl6on8CHqSdwetL9RQle1MWBG7ECexT5
ekNdspdBXb8FHatmyxfeuP80fzhJSJka+w44FdIl6tgR4WhlUnNuiYgjx2YGrycu
BFyGJEmanlm96JUoAMfUqzPYd7+dxvhFR3reFo5XMq7efw9EFy31IONYRpKgIYnL
PkYdZigGrHEtDS1DavasDTdgTC61uncaSDcbR68KMDPfgjC7NYk2v3/SZH6A0HBN
rxWt7ADGhuioTf62e6LBxd14BveHJjtbpOsfDbKk/wIGH0U3W39MOsixgPVjJl+Y
0Tza6h3aEF8tRxTrEpQPvk4jvqDQ7uwBPvgerXfEuarECoj5zuTllzvCjPjxe9h5
vdzZNi5BwBNr3rXLRFT4nYuLMPP7bJURNZUbSxrwqVpepVDPkWWZ2Y9AGr4zT0Ld
S967tDXrCsgCy8Gh5MnLcUIe9Fso8tslLMueTy227amY7lK5SvKpFeLMp9sAGPqc
NAsoCYsv6V6jpM4kbDSw5QzQKqsF/dKgJgnEGqEORDbwTOUwQeV6AYbsvyFovaT0
EkVfc8A8KLf74qD3Y6Hz0AZuACVVUac3H9D2ctDPfUUca+ndYOo=
=lseS
-END PGP SIGNATURE-

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


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



TLSv1.3 in TC8.5 + Azul Java 8

2019-08-01 Thread George Stanchev
As of recently Azul has backported the JSSE from Java 11 into Java 8 [1] and it 
is currently offering TLSv1.3 support in its Java 8 distro [2]. Does this help 
TC with JSSE SSL engine to also offer TLSv1.3 on its SSL listeners?


[1] https://github.com/openjsse/openjsse
[2] https://www.azul.com/keeping-network-traffic-safe-in-jdk-8-with-tls-1-3/


RE: AW: Outbound SSL?

2019-06-03 Thread George Stanchev
What is your webapp using as HTTP client that handles the SSL?

-Original Message-
From: James Lampert  
Sent: Friday, May 31, 2019 3:41 PM
To: Tomcat Users List 
Subject: Re: AW: Outbound SSL?

This just keeps getting weirder and weirder.

I extracted the actual request
> https://maps.googleapis.com/maps/api/geocode/json?key=
> ss=
from where it had been logged to catalina.out, and built a simple program to 
feed it to Scott Klement's HTTPAPI, an open-source HTTP interface for 
OS/400-native programs. It has a rather rich debugging capability.

Once I got it working on our box, I sent it over to the "problem" box.
And it worked perfectly: it got what appears to be the expected response.

Of course, it's doing all of this natively, rather than through Java.

We also know that Tomcat is running under a 64-bit Java 7 JVM on that box. And 
we also know that we've got this product running in Java 6, 7, and 8, on IBM 
Midrange boxes, WinDoze boxes, and Linux boxes, without the problem occurring.

--
JHHL

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



RE: OS

2019-04-21 Thread George Stanchev
FWIW someone is submitting the same identical question (with only the project 
name different) in the dozen or so Apache projects I am on mailing list of...

Just google "Hello, I am doing an investigation. Does Windows Server 2019 
support" and see for yourself

It looks like a troll


-Original Message-
From: Mark Thomas  
Sent: Friday, April 19, 2019 4:02 AM
To: Tomcat Users List 
Subject: Re: OS

On April 18, 2019 6:54:37 PM UTC, Christopher Schultz 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>
>
>On 4/18/19 01:06, liname...@outlook.com wrote:
>> Hello, I am doing an investigation. Does Windows Server 2019 support 
>> the following products:
>> 
>> Apache Tomcat   6.0.35 Tomcat Connectors (mod_jk)   1.2.35-m1.0
>> 
>> Is the other version supported? Can you tell me, thank you very much.
>
>Tomcat requires a JVM of a certain version in order to run. Tomcat 6 
>requires Java 5 or later, but is no longer supported by this community. 
>Tomcat 6.0.35 is, in fact, *dangerously* out of date.

As is mod_jk 1.2.35. You should use the latest available mod_jk version.

Mark


>
>You should look at running Tomcat 7.0, 8.5, or 9.0 at this point.
>
>- -chris
>-BEGIN PGP SIGNATURE-
>Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
>iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly4x+0ACgkQHPApP6U8
>pFjoNhAAkf6jkOOgqm1XwCQM0ioIa9Ab9jji45S2fPX0CFs5pMZ/MRtbT0XBrzQ1
>lFbzF1wZBWkBCpHCL/KWGnpEo3TVYHRIz4e6wTU4zVsChl9D10bcQEpV2RMnL6D3
>mUP2OY9vwrQszaNEtbWsVjnm6XrqyGolGqpl0qBqoasqgn1b/jSX/WITnnmXatK4
>JM/3ouNamnbFzZkfaSQPP8dR3GoIz7PwzrfMbX1aGEsUFPe5bYDtjCuFfLlLaYCj
>HYkICLnZewtnGL5/FuxjWYFqLep/6k9P4lbBGvnAQwLqvGtbdpqfm44iuAUuBvWB
>R+lbKbvpORwxvRMc9ncqrm1fveWPLR5Wqt6bJH/eGGpPyurr95fiG6w8BtgFUMeL
>Rad8p+CZjPxDDJ0ZBSy2//VQchpVtdSolaBcEpb3+F2YJB/W0hBSKS2qSS/Pebz9
>2nnK1CRhSJ8pzqAVnPANXjAAWj7LqVt2zs6eA+G4ku2ISV3Gxfgvm//V67YOFjt6
>HcFOX9+wZlHiMcMtn0eCxIKT8CWTotftBEQpX//RwOlohZML9uUGfhP7/Y/R8raM
>BBzsqqWpUPZk8oujMxTHocibUF0QOh9427+8JjKRRuUgOmIoUo1iUcSu2UoEY8S1
>d4C6ba8ScfN8m+cF9kohLVCSjsrZsbDDCkMEZnkoiDGByDR4n6A=
>=RBTT
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


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



RE: Tomcat 8.5.39 on maven central

2019-03-21 Thread George Stanchev
Thanks Mark!

-Original Message-
From: Mark Thomas  
Sent: Thursday, March 21, 2019 3:13 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8.5.39 on maven central

On 21/03/2019 21:00, George Stanchev wrote:
> Hi,
> 
> The announcement went out few days ago but 8.5.39 is still not out there [1]. 
> I know it takes a bit for maven central to pick it up but with the git 
> migration perhaps something got broken?
> 
> George
> 
> [1] https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina

That isn't Maven Central.

8.5.39 is present on Maven Central:
https://repo1.maven.org/maven2/org/apache/tomcat/tomcat/8.5.39/

Those are the full installs but the individual JARs are there as well.

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



Tomcat 8.5.39 on maven central

2019-03-21 Thread George Stanchev
Hi,

The announcement went out few days ago but 8.5.39 is still not out there [1]. I 
know it takes a bit for maven central to pick it up but with the git migration 
perhaps something got broken?

George

[1] https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina


Invalid URL characters via AJP

2019-02-06 Thread George Stanchev
In light of recent changes around allowing and subsequent relaxation of the 
invalid characters handling in TC, I just noticed that TC behind IIS (via JK 
connector/AJP) happily accepts ";<> etc while the HTTP connector rejects them. 
Is this how the AJP connector it is supposed to work? Is the assumption that 
the fronting service should be the line of defence?


NIO vs NIO2

2018-12-23 Thread George Stanchev
Hi,

We are currently on the latest TC 8.5.37 but soon will be moving to latest 9. 
Currently we use NIO connectors. I am having hard time evaluating the need (if 
necessary) to switch to NIO2. Can someone point me to a good resource/link 
where the two connectors are compared and which situations is NIO or NIO2 
better for.

Thanks!

George


RE: Number of Web Applications in one Tomcat: THANKS!

2018-10-31 Thread George Stanchev
This is an interesting discussion. Are there any guides to alleviating 
management work of such deployments? For example, how do you deal with the port 
mapping? Or logs - do you collect at a common location or let each app log in 
its corner ?  Can you share configuration across instances such as SSL, JNDI 
configuration, etc? Any blogs to such approach?

-Original Message-
From: Christopher Schultz  
Sent: Wednesday, October 31, 2018 9:29 AM
To: users@tomcat.apache.org
Subject: Re: Number of Web Applications in one Tomcat: THANKS!

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Guido,

On 10/31/18 05:14, Jäkel, Guido wrote:
>> Has anyone ever attacked one of your web applications? There are some 
>> fun ways to make an application use a huge amount of memory.
>> Just because the applications themselves are behaving doesn't mean 
>> that all the users are behaving.
>> 
>> For example, do you have a max POST size set for your application? If 
>> not, I can send your login form a username that is so long it might 
>> exhaust your heap. 2147483647 characters is a LOT of characters.
>> 
>> If you have a max POST size, maybe you don't filter-out PUT requests, 
>> and have Tomcat parsing those for you. Same problem, there.
> 
> Dear Chris,
> 
> But that's no argument for or against running more than one 
> application per Tomcat: If you're not aware of such things, one may 
> attack your other Tomcats in the same way because of identical 
> configuration.

Yes and no.

Presumably, more than one application means more resources required in general. 
Since each application might experience "peak" usage simultaneously, you must 
over-provision *for both*. That actually
*helps* you against the kind of attack I proposed (more memory is slightly more 
difficult to fill than less).

On the other hand, each application has different requirements.
Perhaps one application needs to be able to accept file uploads while the other 
one does not. That means that the application which need not accept large POST 
requests is now vulnerable because of a shared resource 9memory) which the 
other application can allow attackers to consume.

> Of course, if you plan to run a couple of applications per Tomcat, you 
> may also plan to spread it to more than instance to have a fail-over 
> or load balancing . But even if you use a HA-cluster with one App per 
> cluster member: If one is able to crash the Application by a Request 
> on one cluster member, this might be repeated on the other members 
> without noteworthy costs.

Cascade failures can indeed be a serious problem.

It's generally more difficult to crash a Tomcat instance with a single request. 
It usually requires multiple requests (sometimes
concurrently) and so that provides the admin more opportunities at mitigation.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvZykEACgkQHPApP6U8
pFiq+A/8DVWiQY6dZhlclS6IkN/Mah2iyslgpTrqASAO4ZkUf8bj9mZKR/FK0wEn
zBJyYz0K4YxZY5HKFn9oVE2WGQOIJAf3FXh/GY1OFb7PtFanU65QS9q7MCj+TmLX
D1lMfI4MjXqV6NTZsdPXwstCpKxFZ1MMpC6fjCO1cS3vE9pKYn8+OpUWgsL/e5Jj
uqj925911/ZNOUxtibG7E5l9uafadxHhVRa3XYOHzSq6t2+lvQ1NXmMYtDUIyatQ
IeMm++HML1RJBIYe38cMyq5IFg+uPkD5wnPHIFcS3kIkGv8nWBAL8xs+QPsEQoRa
I+tWoMJ5T5Yd+x8aP7ifHGtRs3PHczl07ZS5MJPwL/TUUaYolEYuvo+nMW0sJ6mX
75G6KBexS2oMww+m6jcBIZy9HEsi9LfZhWrUP71D3z86y6pbJLHqW9WfnfK+UH8B
MhOv+++xH6I8sLPPMikvy33Ppt8UfGJneyqOn6DXftw9ri4mXZQLs7XyzQWRjEmF
XWaWKWE8XtyVJwgr2S9Dt4HUJiOjMjcG5DhHXossBMwqemh6PYcbe1/LXAsv7t++
7jOOTgTiBHpgN6Ot5K1Q6qCbs9HvWXQBrDf9ycVsqAejV5gPIFqepoj9iPhFbKd+
Px+s18DcwoB6MgXRT5WtGgEsqRNOScdiC+PrJyzsoGN5MHsHxCI=
=GK5X
-END PGP SIGNATURE-

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



RE: log4j

2018-05-18 Thread George Stanchev
Depends on what you're asking. If you're asking to use log4j to capture Tomcat 
logging, then the answer is - you can't but you can use Log4j2 or JULI. If the 
question is how to use log4j for your apps deployed under Tomcat, then answer 
can be found easily...

From: Cheltenham, Chris 
Sent: Friday, May 18, 2018 7:50 AM
To: 'Tomcat Users List' 
Subject: log4j

Hello,

How do I configure Tomcat 8.5.x to use log4j?

Is there a good document to follow?

I am not very familiar with java but it looks like you configure to logs to 
accept java logging for Tomcat.


===

Thank You;

Chris Cheltenham
Technology Services
The School District of Philadelphia

Work # 215-400-5025
Cell # 215-301-6571


client cert authentication

2018-05-04 Thread George Stanchev
I guess I am looking for some pointers how to approach a certain scenario from 
"the right way" of implementing it. Say you have a standard login form with 
user/pass edits and "Login" and "Smartcard" buttons. The "Login" button does 
Its obvious thing. The "Smartcard" button authenticates the user using client 
cert SSL. The actual certificate validation happens way downstream of the login 
page controller so all it needs to do is to extract it from the request and 
pass it on to the backend. The login page can be served either over http or 
https. The way currently is implemented, is for the "Smartcard" for the servlet 
to detect that the "Smartcard" has been pressed and to 302 to a specially 
designated https connector that has 
"clientAuth="true"+"trustManagerClassName=... AnyCertX509TrustManager" 
attributes that handle the client cert authentication. I suspect though that 
this is a hack, and there could be a more clever way to handle this with either 
forwarding or somehow manually upgrading the connection from HTTP to 
HTTPS/clientAuth or HTTPS to HTTPS/clientAuth to challenge for a client 
certificate. I'd like to eliminate the 302 and the maintenance of a separate 
connector. Some pointers/advice would be appreciated...


RE: Security of AJP

2018-02-28 Thread George Stanchev
It is used, for example, if you want to front Tomcat by Apache Web Server or by 
IIS (among others). In those cases the HTTP processing is done in the front 
system and if necessary it is proxied to Tomcat via AJP. You take HTTP request 
from that system, put it in an AJP record and send it over TCPIP to Tomcat's 
AJP connector.

Is it more clear now?

-Original Message-
From: Cheltenham, Chris [mailto:ccheltenham-...@philasd.org] 
Sent: Wednesday, February 28, 2018 6:40 AM
To: Tomcat Users List 
Subject: RE: Security of AJP

Since AJP is not really needed by Tomcat; If I comment out the AJP startup line 
in server.xml will that affect anything.

I still don’t even understand what its for.
I have read the apache docs but it doesn’t mean anything to me..
Apache's description doesn't tell me anything.


The AJP Connector element represents a Connector component that communicates 
with a web connector via the AJP protocol. This is used for cases where you 
wish to invisibly integrate Tomcat into an existing (or new) Apache 
installation, and you want Apache to handle the static content contained in the 
web application, and/or utilize Apache's SSL processing.

That is mumbo jumbo.


===

Thank You;

Chris Cheltenham
Technology Services
The School District of Philadelphia

Work # 215-400-5025
Cell # 215-301-6571

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, February 27, 2018 4:26 PM
To: users@tomcat.apache.org
Subject: Re: Security of AJP

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/27/18 3:54 PM, Mark A. Claassen wrote:
> From what I have read, it seems that the AJP connector is not secure, 
> and is meant to be used in a protective environment.
> There are lots of things that imply this, like no SSL settings and 
> such, but I cannot find it directly stated anywhere.  I am pretty 
> confident in my read of this, but it is, of course, difficult to say 
> that "all options have been explored and it is not possible".

AJP is definitely a cleartext protocol, and offers no encryption capabilities. 
If you want to secure it, you will have to use some tunneling technology such 
as a VPN, stunnel, etc.

> First of all, am I correct in my assertion that it cannot be made 
> secure?

Theoretically, it can be made to be secure, but it would require a great deal 
of work and honestly, it's probably not worth it. The protocol is mature and 
nobody really feels like retrofitting encryption into it.

> And, if so, I would invite you (or us, the community!) to consider 
> modifying the documentation to state this.  Maybe something like:
>
> https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html The AJP 
> Connector element represents a Connector component that communicates 
> with a web connector via the AJP protocol. [This is an unencrypted 
> connector, intended for use in protected enviroments.] This is used 
> for cases where you wish to invisibly integrate Tomcat into an 
> existing (or new) Apache installation, and you want Apache to handle 
> the static content contained in the web application, and/or utilize 
> Apache's SSL processing.

That seems reasonable. Care to provide a documentation patch? You'll get your 
name into the change log ;)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqVzOgACgkQHPApP6U8
pFitmA/6A1fSjyIDEz7q9lxzwhlbVxZFMIGSM9pQLF3ZHAI3qA304luhNO9+wjAp
4cbczpnKiiEIj+753To2d0NOtjPP4+NfR25d8sg+T5e3SgynpEhx8wPCvPPxHGBx
hgsX9xY+gLikvJs25u7QAab8i2qe6i1YBtJhKUNgTLvD/OAI/MzfhkuQBEUq9yUx
66cWSJznsOHthnC2lUKCzTIrOEPDhhSd7B90n99SIV1DOZdOzI2fXA2xMXByaZ/e
kiWSvt5OfvThDZlbXFexEwFrQfJ+Tj10/L/tVz4OY3LSPDXEukFE/MnRya8HW1sj
6ANX3tNOBBPLMtNNLfJtn16mbAQsWZMFRPYl3fukwmwWzEs1IvMq7dQGSOo355A7
UXMjlFL/ogty6Q3qFzhnpvoSNxmrCXKWos7Mk3kYpeWkp9yEB7Kp48ogsKIMRcn+
YW8+1c/yKC17PjjhOr2ty3QzHFRbY+x4nZO65v9c402UhM+MTf0J6GhUxxe5nHI2
bmA3bRFTjyLNpu97XjAfUEIuYEXynZSn8ViVnKhG3xjPIWokSjDyIDVmED4mvimt
vE3bUTSkpAV8nE/M/Y3Xu5VjhLcjymHCVUoz/v8La7Bm9+nHfg1NH9XYmNmCrkr7
YkCaYAk9xErXTWbNABaY6sJNxATZA3pftl/592twWr7v9w0eDSQ=
=FAja
-END PGP SIGNATURE-

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


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


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



RE: Using Environment variables instead of Java -D properties for context.xml substitution

2018-01-22 Thread George Stanchev
Can you use catalina.properties? From the docs [1]

" All system properties are available including those set using the -D syntax, 
those automatically made available by the JVM and those configured in the 
$CATALINA_BASE/conf/catalina.properties file."

[1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html


-Original Message-
From: Algirdas Veitas [mailto:apvei...@gmail.com] 
Sent: Monday, January 22, 2018 4:02 PM
To: users@tomcat.apache.org
Subject: Using Environment variables instead of Java -D properties for 
context.xml substitution

Hi,

We have a context.xml under $TOMCAT_HOME/conf that looks like this:



if we do something like this in setenv.sh, the substitution works great

export DB_USERNAME=xyz
export DB_PASSWORD=vvv

export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"

However, if on a linux box, if someone did a "ps -ef | grep java", they would 
be able to see the actual values of these parameters.

theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
-Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/tomcat/apache-tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-DDB_USERNAME=xyz
-DDB_PASSWORD=vvv

Which our operations team does not want

Is there any syntax that Tomcat can recognize to substitute true environment 
variables (i.e. export DB_USERNAME=xyz) as opposed to Java properties injected 
into the JVM by -D (i.e. export
DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any documentation on it, 
but thought would ask.

Thanks in advance,
Al


RE: building TC 8.5 with checkstyle

2017-12-07 Thread George Stanchev
>On 07/12/17 21:12, Mark Thomas wrote:
>> On 07/12/17 20:48, George Stanchev wrote:
>>> I am trying to build TC 8.5.24 from source and running into checkstyle 
>>> validation issues [1]. I looked at 
>>> https://tomcat.apache.org/tomcat-8.5-doc/building.html and couldn't find 
>>> anything that suggest that the default target would not build, neither 
>>> checkstyle is mentioned. It is not a problem, because i can turn off the 
>>> checkstyle validation can be turned off in a custome build.properties with 
>>> "execute.validate=false" but I was wondering if the TC devs would like to 
>>> at least mention it on the build instructions page OR fix the checkstyle 
>>> issues
>> 
>> https://svn.apache.org/viewvc?view=revision=1816748

> Also, don't configure base.path to be part of the source tree else Checkstyle 
> will try to validate any 3rd party source the build downloads with the not 
> unsurprising result that it fails validation.



Thanks Mark! 

I definitely had my base path pointing to under the source tree since I wanted 
everything to be self-contained in the src dir. I will rework it a bit now...

Regards,
George

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



building TC 8.5 with checkstyle

2017-12-07 Thread George Stanchev
I am trying to build TC 8.5.24 from source and running into checkstyle 
validation issues [1]. I looked at 
https://tomcat.apache.org/tomcat-8.5-doc/building.html and couldn't find 
anything that suggest that the default target would not build, neither 
checkstyle is mentioned. It is not a problem, because i can turn off the 
checkstyle validation can be turned off in a custome build.properties with 
"execute.validate=false" but I was wondering if the TC devs would like to at 
least mention it on the build instructions page OR fix the checkstyle issues

George


[1]

validate:
[mkdir] Created dir: D:\work\My 
Projects\java\Tomcat\8.5.24-src\output\res\checkstyle
[checkstyle] Running Checkstyle 6.17 on 3211 files
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\LICENSE.txt:2:
 Line does not match expected header line of '^(rem)?\W*Licensed to the Apache 
Software Foundation \(ASF\) under one or mo
re$'. [RegexpHeader]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\NOTICE.txt:1:
 Missing a header - not enough lines in file. [RegexpHeader]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\apidocs\index-all.html:125:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\apidocs\org\apache\commons\daemon\Daemon.html:200:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\apidocs\org\apache\commons\daemon\DaemonInitException.html:114:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\apidocs\org\apache\commons\daemon\package-summary.html:142:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\apidocs\org\apache\commons\daemon\package-use.html:110:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]
[checkstyle] [ERROR] D:\work\My 
Projects\java\Tomcat\8.5.24-src\libraries-download\commons-daemon-1.1.0\apidocs\org\apache\commons\daemon\support\DaemonWrapper.html:247:
 Line matches the illegal pattern '\s+$'. [RegexpSingleline]

BUILD FAILED


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: Issue with static file in Tomcat 8.5.17

2017-07-20 Thread George Stanchev
 
>> The problem is related to the new code that handles the case when a 
>> file is stored in one encoding but served in another. Since changing 
>> encodings can change the value and number of bytes served (for example 
>> serving £ in UTF-8 requires two bytes but only one in ISO-8859-1). 
>> This code did not handle requests that use accept-ranges correctly.

> While the above is true, the actual problem looking more closely is that the 
> content length can change when conversion is used.

>Mark


Hi Mark,

I hate to do this, but the issue is still around in another form. After 
upgrading to the TC 8.5.18 which is currently under vote, Chrome fails to parse 
the jquery file with "SyntaxError: Unexpected Token ?" error. The response 
contains some data prior to the jQuery payload (it is probably encoding stuff) 
that throws Chrome off.

Unfortunately I cannot pinpoint exactly what is going on.

The original jQuery - the one I sent you with the testapp trying to reproduce 
the problem starts with "EF BB BF" before the actual payload. When I run it 
through wget, the file on disk starts with just "3F". The response in Chrome 
looks like this: "0x62, 0x36, 0x65, 0x33, 0x0D, 0x0A, 0x3F" - so there is extra 
"b6e3\r\n" leading prior to the "3F". Below [1] is the request/response headers 
of the Chrome request. I've got also a HAR if this helps and I can send it to 
you email address as it will probably get stripped on the user-mailing list



George


Request Headers:
GET http://hostname:8085/idp/javascript/jquery-1.8.3.min.js HTTP/1.1
Pragma: no-cache
DNT: 1
Accept-Encoding: gzip, deflate
Host: hostname:8085
Accept-Language: en-US,en;q=0.8,bg;q=0.6,und;q=0.4
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/59.0.3071.115 Safari/537.36
Accept: */*
Cookie: JSESSIONID=blahblah
Connection: keep-alive
Cache-Control: no-cache


Response headers:

HTTP/1.1 200
Date: Thu, 20 Jul 2017 19:59:05 GMT
X-Content-Type-Options: nosniff
Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
ETag: W/"93640-1496825994000"
X-Frame-Options: DENY
Content-Type: application/javascript
Transfer-Encoding: chunked
Accept-Ranges: bytes
X-XSS-Protection: 1; mode=block



RE: Issue with static file in Tomcat 8.5.17

2017-07-07 Thread George Stanchev

On 07/07/2017 20:56, George Stanchev wrote:
> Sorry, I didn't realize there is a -d option that gives you the full request 
> and response. Here is the dump:

Thanks for the extra information.

I can't reproduce this yet. I'm going to hold off on closing the currently 
running votes until I get to the bottom of this.

Which version of Windows is this?

Mark



We've reproduced it on Windows 7 and various versions of Windows Server (2016, 
2012 R2, etc). All times Tomcat runs through the service wrapper. I happen to 
run it in the command line via

start /b /wait %comspec% /c "%TOMCAT_EXE%" //TS//%TOMCAT_SERVICE_NAME%


command. Here are more details. Since you cannot reproduce it, perhaps I can 
package up the tomcat + the test app in a zip and upload it somewhere...

George



2017-07-07T16:00:53,409 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Server built:   
   Jul 4 2017 08:12:51 UTC
2017-07-07T16:00:53,410 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Server number:  
   8.5.17.0
2017-07-07T16:00:53,414 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- OS Name:
   Windows 7
2017-07-07T16:00:53,418 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- OS Version: 
   6.1
2017-07-07T16:00:53,422 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Architecture:   
   amd64
2017-07-07T16:00:53,427 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Java Home:  
   C:\Program Files\product\Common\jre1.8
2017-07-07T16:00:53,431 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- JVM Version:
   1.8.0_131-b11
2017-07-07T16:00:53,435 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- JVM Vendor: 
   Oracle Corporation
2017-07-07T16:00:53,439 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- CATALINA_BASE:  
   C:\Program Files\product\Common\tomcat\server\default
2017-07-07T16:00:53,444 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- CATALINA_HOME:  
   C:\Program Files\product\Common\tomcat
2017-07-07T16:00:53,448 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Xms256M
2017-07-07T16:00:53,452 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Xmx4096M
2017-07-07T16:00:53,457 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -XX:+UseConcMarkSweepGC
2017-07-07T16:00:53,461 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dsun.rmi.dgc.client.gcInterval=360
2017-07-07T16:00:53,465 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dsun.rmi.dgc.server.gcInterval=360
2017-07-07T16:00:53,470 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Xdebug
2017-07-07T16:00:53,475 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: 
-Xrunjdwp:transport=dt_socket,address=localhost:8000,server=y,suspend=n
2017-07-07T16:00:53,480 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dcatalina.home=C:\Program Files\product\Common\tomcat
2017-07-07T16:00:53,484 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dcatalina.base=C:\Program Files\product\Common\tomcat\server\default
2017-07-07T16:00:53,488 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
2017-07-07T16:00:53,493 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dlog4j.configurationFile=C:\Program 
Files\product\Common\tomcat\server\default\conf\log4j2.xml
2017-07-07T16:00:53,497 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
2017-07-07T16:00:53,501 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Djava.io.tmpdir=C:\Program 
Files\product\Common\tomcat\server\default\temp
2017-07-07T16:00:53,514 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Duser.country=US
2017-07-07T16:00:53,518 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dfile.encoding=UTF-8
2017-07-07T16:00:53,522 INFO  [main] 
[org.apache.catalina.startup.VersionLoggerListener:179] [::] -- Command line 
argument: -Dserver.log.dir=C

RE: Issue with static file in Tomcat 8.5.17

2017-07-07 Thread George Stanchev
Sorry, I didn't realize there is a -d option that gives you the full request 
and response. Here is the dump:


c:\>wget -d -S http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\bin\gnuwin32/etc/wgetrc
Setting --server-response (serverresponse) to 1
DEBUG output created by Wget 1.11.4 on Windows-MinGW.

--2017-07-07 13:52:36--  
http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js
Resolving hostname... seconds 0.00, , ...
Caching hostname => 
Connecting to hostname:8085... seconds 0.00, connected.
Created socket 336.
Releasing 0x00339048 (new refcount 1).

---request begin---
GET /testapp/javascript/jquery-1.8.3.min.js HTTP/1.0
User-Agent: Wget/1.11.4
Accept: */*
Host: hostname:8085
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes
ETag: W/"93640-1496825994000"
Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
Content-Type: application/javascript
Content-Length: 93640
Date: Fri, 07 Jul 2017 19:52:36 GMT
Connection: keep-alive

---response end---

  HTTP/1.1 200
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Accept-Ranges: bytes
  ETag: W/"93640-1496825994000"
  Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
  Content-Type: application/javascript
  Content-Length: 93640
  Date: Fri, 07 Jul 2017 19:52:36 GMT
  Connection: keep-alive
Registered socket 336 for persistent reuse.
Length: 93640 (91K) [application/javascript]
Saving to: `jquery-1.8.3.min.js.3'

99% [...] 93,638  89.5K/s   in 23s

2017-07-07 13:53:00 (3.96 KB/s) - Connection closed at byte 93638. Retrying.

--2017-07-07 13:53:01--  (try: 2)  
http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js
Disabling further reuse of socket 336.
Closed fd 336
Found hostname in host_name_addresses_map (00339048)
Connecting to hostname|:8085... seconds 0.00, connected.
Created socket 336.
Releasing 0x00339048 (new refcount 1).

---request begin---
GET /testapp/javascript/jquery-1.8.3.min.js HTTP/1.0
Range: bytes=93638-
User-Agent: Wget/1.11.4
Accept: */*
Host: hostname:8085
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 206
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes
ETag: W/"93640-1496825994000"
Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
Content-Range: bytes 93638-93639/93640
Content-Type: application/javascript
Content-Length: 2
Date: Fri, 07 Jul 2017 19:53:01 GMT
Connection: keep-alive

---response end---

  HTTP/1.1 206
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Accept-Ranges: bytes
  ETag: W/"93640-1496825994000"
  Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
  Content-Range: bytes 93638-93639/93640
  Content-Type: application/javascript
  Content-Length: 2
  Date: Fri, 07 Jul 2017 19:53:01 GMT
  Connection: keep-alive
Registered socket 336 for persistent reuse.
Length: 93640 (91K), 2 remaining [application/javascript]
Saving to: `jquery-1.8.3.min.js.3'

100%[...] 93,640  --.-K/s   in 0s 

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



RE: Issue with static file in Tomcat 8.5.17

2017-07-07 Thread George Stanchev


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, July 07, 2017 1:05 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Issue with static file in Tomcat 8.5.17

On 07/07/2017 19:09, George Stanchev wrote:
> Hi,

..

> Please let me know if I need to open a BZ issue to track this. I have a test 
> app but really it is very simple - an app with empty web descriptor and that 
> version of minimized jQuery JS in a folder.


The most likely suspect is this fix:

49464: Improve the Default Servlet's handling of static files when the file 
encoding is not compatible with the required response encoding. (markt)

What is your system's default file encoding (or if you have done so, what is 
explicitly configured for the DefaultServlet?).

The full response headers would also be helpful.

Thanks,

Mark




We run with -Dfile.encoding=UTF-8.

Here is more verbose response [1]. It takes ~20secs for the first request to 
time out. 


[1]

c:\>wget -S http://host:8085/testapp/javascript/jquery-1.8.3.min.js
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\bin\gnuwin32/etc/wgetrc
--2017-07-07 13:08:48--  http://host:8085/testapp/javascript/jquery-1.8.3.min.js
Resolving... hostnames ...
Connecting to host:8085... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Accept-Ranges: bytes
  ETag: W/"93640-1496825994000"
  Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
  Content-Type: application/javascript
  Content-Length: 93640
  Date: Fri, 07 Jul 2017 19:08:48 GMT
  Connection: keep-alive
Length: 93640 (91K) [application/javascript]
Saving to: `jquery-1.8.3.min.js.2'

99% 
[=>
 ] 93,638  86.5K/s   in 20s

2017-07-07 13:09:08 (4.57 KB/s) - Connection closed at byte 93638. Retrying.

--2017-07-07 13:09:09--  (try: 2)  
http://host/testapp/javascript/jquery-1.8.3.min.js
Connecting to host:8085... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 206
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Accept-Ranges: bytes
  ETag: W/"93640-1496825994000"
  Last-Modified: Wed, 07 Jun 2017 08:59:54 GMT
  Content-Range: bytes 93638-93639/93640
  Content-Type: application/javascript
  Content-Length: 2
  Date: Fri, 07 Jul 2017 19:09:09 GMT
  Connection: keep-alive
Length: 93640 (91K), 2 remaining [application/javascript]
Saving to: `jquery-1.8.3.min.js.2'

100%[++>]
 93,640  --.-K/s   in 0s

2017-07-07 13:09:09 (69.2 KB/s) - `jquery-1.8.3.min.js.2' saved [93640/93640]


Issue with static file in Tomcat 8.5.17

2017-07-07 Thread George Stanchev
Hi,

The current Tomcat 8.5.17 is under vote for release with +1s only. I took the 
liberty to download the distributable before officially announced and am 
running into an issue with it. Static file that used to download in 8.5.16 and 
below now it doesn't. Chrome reports:

jquery-1.8.3.min.js:1 GET 
http://rm9485:8085/testapp/javascript/jquery-1.8.3.min.js 
net::ERR_CONTENT_LENGTH_MISMATCH

In its console

If I try wget, it eventually succeeds but not without a retry:

c:\>wget http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\bin\gnuwin32/etc/wgetrc
--2017-07-07 11:58:40--  
http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js
Resolving hostname, IPs, etc, ...
Connecting to hostname:8085... connected.
HTTP request sent, awaiting response... 200
Length: 93640 (91K) [application/javascript]
Saving to: `jquery-1.8.3.min.js'

99% 
[=>
 ] 93,638  85.5K/s   in 21s

2017-07-07 11:59:02 (4.34 KB/s) - Connection closed at byte 93638. Retrying.

--2017-07-07 11:59:03--  (try: 2)  
http://hostname:8085/testapp/javascript/jquery-1.8.3.min.js
Connecting to ***:8085... connected.
HTTP request sent, awaiting response... 206
Length: 93640 (91K), 2 remaining [application/javascript]
Saving to: `jquery-1.8.3.min.js'

100%[++>]
 93,640  --.-K/s   in 0s

2017-07-07 11:59:03 (49.3 KB/s) - `jquery-1.8.3.min.js' saved [93640/93640]


Please let me know if I need to open a BZ issue to track this. I have a test 
app but really it is very simple - an app with empty web descriptor and that 
version of minimized jQuery JS in a folder.

George


jk connector + http2

2017-05-25 Thread George Stanchev
Hi,

Is a HTTP/2 call to Tomcat proxied via IIS / JK Connector (Tomcat Connector) 
expected to succeed?

George


RE: warning in tomcat logs

2017-05-02 Thread George Stanchev

>> This has been fixed in 8.5.x for 8.5.15 onwards and 9.0.x for 9.0.0.M21 
>> onwards.

Thanks Mark

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



RE: warning in tomcat logs

2017-05-02 Thread George Stanchev


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Sunday, April 30, 2017 5:02 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: warning in tomcat logs

On 29/04/17 15:13, George Stanchev wrote:
> TC 8.5.14 and noticed in the logs the following warning:
> 
> "The truststoreProvider [AnyCert] does not support the 
> certificateVerificationDepth configuration option"
> 
> In our case, we're using Shib's AnyCert trust manager to accept any 
> client cert on a particular connector as described here [1]. I noticed 
> that now one can inject the trust manager directly via 
> "trustManagerClassName" so I am planning to go that route to eliminate 
> the warning from the logs. But I looked at
> JSSEUtils.java#getTrustManagers() and it looks like the warning is 
> emitted for any algorithm other than "PKIX". My question is, what if 
> an algorithm implementation doesn't care about 
> "certificateVerificationDepth"? By setting different algorithm the 
> user should realize that they are deviating from PKIX and therefore 
> configuration parameters that apply to PKIX (such as 
> "trustMaxCertLength" would not be passed down to the trust manager.
> Doesn't it make sense to be logged at INFO level?


I think not.

What would be better is if the warning was only logged if the attribute was 
explicitly set.

Mark



Perhaps the intent of the warning was that even if it is not explicitly set, it 
still will not get pushed into the PKIXBuilderParameters:

xparams.setMaxPathLength(sslHostConfig.getCertificateVerificationDepth());

with the default value. So "certificateVerificationDepth" is alsways used in 
the case of "PKIX" regardless if explicitly set or not. I don't think I am 
expressing myself very clearly here. IMO the warning should not be emitted for 
non-PKIX algorithm since there is no way to introspect the algorithm 
implementation if it supports it or not. I think we will be better served just 
mention in the documentation that cert verification depth is only applicable to 
PKIX (which happens to be the default)...


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



warning in tomcat logs

2017-04-29 Thread George Stanchev
TC 8.5.14 and noticed in the logs the following warning:

"The truststoreProvider [AnyCert] does not support the 
certificateVerificationDepth configuration option"

In our case, we're using Shib's AnyCert trust manager to accept any client cert 
on a particular connector as described here [1]. I noticed that now one can 
inject the trust manager directly via "trustManagerClassName" so I am planning 
to go that route to eliminate the warning from the logs. But I looked at 
JSSEUtils.java#getTrustManagers() and it looks like the warning is emitted for 
any algorithm other than "PKIX". My question is, what if an algorithm 
implementation doesn't care about "certificateVerificationDepth"? By setting 
different algorithm the user should realize that they are deviating from PKIX 
and therefore configuration parameters that apply to PKIX (such as 
"trustMaxCertLength" would not be passed down to the trust manager. Doesn't it 
make sense to be logged at INFO level?

George


[1] https://wiki.shibboleth.net/confluence/display/SHIB/TomcatClientCertAuthN


RE: Apache Tomcat 7.0.59 - Even if a ws certificate stored in the WSkeystore expires, any webclient request is still accepted by server and not refused

2017-02-07 Thread George Stanchev
Mark, 

Apologies for top posting. We have our own trust manager that is attached to 
the connector because we want client certificates to be passed in the 
application for validation and authentication rather than the connector. If we 
switch to the OpenSSL/APR based certificate processing, would the trust manager 
still work? I presume not, but wanted to ask and if not, what are the options?


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, February 06, 2017 7:20 AM
To: Tomcat Users List 
Subject: Re: Apache Tomcat 7.0.59 - Even if a ws certificate stored in the 
WSkeystore expires, any webclient request is still accepted by server and not 
refused

On 06/02/17 13:49, Francesco Leone wrote:
> Dear Sirs, To communicate you a behaviour with Apache Tomcat 7.0.59
>
> Apache Tomcat 7.0.59 is running with: - RHEL6.6 - java jdk 1.8.0.74 - 
> OpenSSL 1.0.2g
>
> We have a client - server communication. The Client certificate is 
> produced via keytool  and we have same problem highlighted here
>
> http://stackoverflow.com/questions/33688020/configuring-apache-tomcat-
> 7-0-to-reject-connections-with-expired-client-certific
>
>  and
>
> http://stackoverflow.com/questions/5206859/java-trustmanager-behavior-
> on-expired-certificates
>
>
>
> What we got reading all flow, is that to solve our problem we should 
> implement a new X509TrustManager which creates our original instance 
> in its constructor, implements all methods as calls to the original 
> instance, and adds a call to checkValidity for each certificate in 
> certs[] inside checkServerTrusted.
>
> Did we get well ? If yes, it sounds to us as a hole in the security 
> and so a bug in Tomcat, is there any chance to have this behaviour 
> (refuse connection at expired certificates) as standard in later 
> Apache tomcat 7.0.x release ? Any of this community can support us ?

This is not a Tomcat bug.

If you tell Java to trust a certificate, it will do so and ignore the validity 
period.

I've looked into this in the past and short of implementing your own 
X509TrustManager I haven't yet found an API Tomcat could use to add an 
additional check on the trusted cert's validity.

A better general solution is to trust the CA(s) issuing the client certificates 
rather than the client certificates. Then, because the client cert is not in 
the trust store, Java checks it more thoroughly - including the validity dates.

It is also worth looking at using an OpenSSL based TLS connector. From what I 
recall of my previous testing OpenSSL did check the validity dates of trusted 
certs.

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



log4j in Tomcat 8.5

2017-02-02 Thread George Stanchev
Hi,

I am transitioning from Tomcat 7.0 to Tomcat 8.5 and I was wondering what do I 
need to do to use log4j in 8.5. Reading this bug [1], it states that the 
support for the for log4j has been dropped since it is EOLed. Now, there is a 
comment on this issue from Mark that says that it is applied against version 9, 
but this bug was referenced from the changelog for 8.5 [2] that states:


Correct a regression in the fix for 58588 that removed the entire 
org.apache.juli package from the embedded JARs rendering them unusable. (markt)


which implies it has been applied to 8.5. So my question is, can I make Tomcat 
8.5 use log4j?

George




[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58588
[2] http://tomcat.apache.org/tomcat-8.5-doc/changelog.html


RE: NullPointerExceptions from Coyote over SSL

2016-07-27 Thread George Stanchev
Peter,

Depending at which slot you plug in BC in the Security context it might or it 
might not get used depending on the cipher suites used by you SSL connection. 
JSSE will ask Java for crypto implementation from the list of JCE providers and 
if your BC is high on the list, it will get used. It definitely can affect your 
SSL if you're using JSSE+JCE...

George

-Original Message-
From: Peter Robbins [mailto:peter.robb...@jamfsoftware.com] 
Sent: Monday, July 25, 2016 3:25 PM
To: Tomcat Users List 
Subject: Re: NullPointerExceptions from Coyote over SSL

> If you also have tomcat-native installed…
No tomcat-native in any environment I saw, but I’ll make sure we check on that 
config.

We’re not knowingly plugging Bouncy Castle into the Tomcat SSL mix at all. We 
only use it in application logic after registering it with 
Security.addProvider() in a context listener. We then only ever access the 
BouncyCastle Provider by getting it by name, so not too sure what it would have 
to do with the SSL implementation.

We didn’t add any configuration to specify any value for sslImplementationName 
previously, so it should have just been using 
org.apache.tomcat.util.net.jsse.JSSEImplementation anyway. Being a JCE 
implementation, Bouncy Castle Doesn’t provide an SSL implementation, so I’m not 
sure how that could get mixed in at all.

I wish I could add more that we found, but at this point I’m just updating the 
list so that maybe someone else can work around the same thing we have. Thanks 
for the help!

Peter

On 7/25/16, 3:29 PM, "Rémy Maucherat"  wrote:

>You are potentially changing two things at the same time here. You 
>were/are using boutycastle. If you also have tomcat-native installed, 
>Tomcat would try to use OpenSSL with JSSE. I don't have any idea how 
>that interacts with boutycastle, se we're probably not supporting it 
>(it is never tested, and now we provide OpenSSL over which we have some 
>control and basically does the same thing in a better way).


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



RE: sadfasdf

2016-04-19 Thread George Stanchev
It could be someone’s kids. I know mine has done similar damage. With tablets 
and iphones hosting parent’s work pluce junior’s entertainment it could have 
happened. Let us be gentle :)

From: Nick Childs [mailto:nchi...@ramsoft.com]
Sent: Tuesday, April 19, 2016 8:55 PM
To: Tomcat Users List 
Subject: RE: sadfasdf

LOL, really!?


Regards,

Nick Childs
Information Technology Manager
[logo]
9480 Utica Avenue, Suite 612
Rancho Cucamonga, CA 91730
Phone: 909.481.5800 x115
Cell: 909.717.4078
Skype: nchilds.ramsoft
Email: nchi...@ramsoft.com

DISCLAIMER:
In order to comply with HIPAA regulations we ask that provide just the patient 
ID or accession number. Please keep in mind that communications via email over 
the internet are not secure, so we ask not include personal identifying 
information such as patient name, birth date, or personal medical information 
in any case updates or emails you send us.

From: l...@bsoft.com.cn [mailto:l...@bsoft.com.cn]
Sent: Tuesday, April 19, 2016 7:45 PM
To: Tomcat Users List >
Subject: sadfasdf

asdfasdfasdfasf


-
力瓦依丁・库尔班
Mobile:18130819208
qq:895791034
WeChat:lee_vayi
Email:l...@bsoft.com.cn
Company:Bsoft software Company




RE: Understanding how to controlling what data is written to log4j appenders

2016-03-10 Thread George Stanchev
If you run tomcat via the windows server wrapper, you can

"%TOMCAT_EXE%" //US//%TOMCAT_SERVICE_NAME% --StdOutput "%TOMCAT_CONSOLE_LOG%" 
--StdError "%TOMCAT_CONSOLE_LOG%"

Which will redirect the stderr and stdoout to the corresponding log files

George

-Original Message-
From: Joleen Barker [mailto:oldenuf2no...@gmail.com] 
Sent: Thursday, March 10, 2016 5:48 PM
To: Tomcat Users List 
Subject: Re: Understanding how to controlling what data is written to log4j 
appenders

Thanks for the tips. I have to use the perl program for now to accomplish the 
task for the company but l'll continue to work this for the sake of learning 
and getting this changed through to application.

Joleen
On Mar 10, 2016 7:42 PM, "Konstantin Kolinko" 
wrote:

> 2016-03-11 2:49 GMT+03:00 Joleen Barker :
> > I wanted to let you know that I really tried at this and feel the
> changes I
> > made should be working and it is a matter of the developer hard 
> > coding
> the
> > log messages to go to the stdout/stderr and became lazy as one of 
> > the
> other
> > that commented had stated. I opened a ticket with the vendor but I 
> > have
> no
> > idea how long it will take. So I went the route of writing a small 
> > perl script to copy the catalina.out file to a file with the same 
> > name and the date and time appended on the file name and then next I 
> > open the existing catalina.out file to clear the contents and then 
> > close it again to start the next day with a clean log file. It isn't 
> > the way I wanted to go but I ran out of time. If the vendor decides 
> > to work with me, it would be great but I have a feeling they will not go 
> > back and change things.
> >
>
> On the logging page of the FAQ:
> https://wiki.apache.org/tomcat/FAQ/Logging#Q10
>
>
> By the way,
> 1) It is possible to run with a debugger and put a breakpoint into 
> java.io.PrintStream.println(String).  I doubt that the PrintStream 
> class is used much anywhere except to implement System.out/System.err.
> https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
>
> 2) It is possible to search the class files for the message text. The 
> classes store it in UTF-8, and jar files are just zip archives.
>
>
> > So are you suggesting to remove the ConsoleAppender from the 
> > log4j.properties that the vendor has in the WEB-INF/classes directory?
>
> Yes.
>
> The same for Tomcat own log configuration,
>
> http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Considerations_fo
> r_production_usage
>
> (Just mentioning for completeness. IIRC you have already reconfigured 
> Tomcat own logging.)
>
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


RE: AJP protocol auto-switching default

2016-03-10 Thread George Stanchev


-Original Message-
From: Rémy Maucherat [mailto:r...@apache.org] 
Sent: Thursday, March 10, 2016 4:41 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: AJP protocol auto-switching default

2016-03-11 0:38 GMT+01:00 George Stanchev <gstanc...@serena.com>:

> > Perhaps I am overlooking something, but the documentation for AJP 
> > [1] states for "protocol"
> >
> > 
> > The standard protocol value for an AJP connector is AJP/1.3 which 
> > uses an auto-switching mechanism to select either a Java based 
> > connector or an APR/native based connector. If the PATH (Windows) or 
> > LD_LIBRARY_PATH (on most unix systems) environment variables contain 
> > the Tomcat native library, the native/APR connector will be used. If 
> > the native library cannot be found, the Java based connector will be
> used.
> > 
> >
> > The text above doesn't describe what is the auto-selected protocol 
> > when a Java based connector is selected. My guess is that 
> > "org.apache.coyote.ajp.AjpNioProtocol" will be auto-selected since 
> > BIO is on its way out but since the documentation doesn't explicitly 
> > state it, it leaves the reader to wonder.
> >
> > George
> >
> >
> >
> > [1] https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html
>
> 
> Tomcat 7 uses either java.io or APR as the default.
> 
>
>
> The documentation states later:
>
> To use an explicit protocol rather than rely on the auto-switching 
> mechanism described above, the following values may be used:
> org.apache.coyote.ajp.AjpProtocol - blocking Java connector 
> org.apache.coyote.ajp.AjpNioProtocol - non blocking Java connector.
> org.apache.coyote.ajp.AjpAprProtocol - the APR/native connector.
> Custom implementations may also be used.
>
> Which one of the non-Apr protocols above is "java.io"?
>


It is org.apache.coyote.ajp.AjpProtocol.


Thanks! That means my gut feeling was wrong and the documentation should be 
fixed to imply the default selection. Should I fire a BZ issue?



RE: AJP protocol auto-switching default

2016-03-10 Thread George Stanchev
> Perhaps I am overlooking something, but the documentation for AJP [1] 
> states for "protocol"
>
> 
> The standard protocol value for an AJP connector is AJP/1.3 which uses 
> an auto-switching mechanism to select either a Java based connector or 
> an APR/native based connector. If the PATH (Windows) or 
> LD_LIBRARY_PATH (on most unix systems) environment variables contain 
> the Tomcat native library, the native/APR connector will be used. If 
> the native library cannot be found, the Java based connector will be used.
> 
>
> The text above doesn't describe what is the auto-selected protocol 
> when a Java based connector is selected. My guess is that 
> "org.apache.coyote.ajp.AjpNioProtocol" will be auto-selected since BIO 
> is on its way out but since the documentation doesn't explicitly state 
> it, it leaves the reader to wonder.
>
> George
>
>
>
> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html


Tomcat 7 uses either java.io or APR as the default.



The documentation states later:

To use an explicit protocol rather than rely on the auto-switching mechanism 
described above, the following values may be used:
org.apache.coyote.ajp.AjpProtocol - blocking Java connector
org.apache.coyote.ajp.AjpNioProtocol - non blocking Java connector.
org.apache.coyote.ajp.AjpAprProtocol - the APR/native connector.
Custom implementations may also be used.

Which one of the non-Apr protocols above is "java.io"?

George



AJP protocol auto-switching default

2016-03-10 Thread George Stanchev
Perhaps I am overlooking something, but the documentation for AJP [1] states 
for "protocol"


The standard protocol value for an AJP connector is AJP/1.3 which uses an 
auto-switching mechanism to select either a Java based connector or an 
APR/native based connector. If the PATH (Windows) or LD_LIBRARY_PATH (on most 
unix systems) environment variables contain the Tomcat native library, the 
native/APR connector will be used. If the native library cannot be found, the 
Java based connector will be used.


The text above doesn't describe what is the auto-selected protocol when a Java 
based connector is selected. My guess is that 
"org.apache.coyote.ajp.AjpNioProtocol" will be auto-selected since BIO is on 
its way out but since the documentation doesn't explicitly state it, it leaves 
the reader to wonder.

George



[1] https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html


RE: Windows Authentication

2016-03-04 Thread George Stanchev
It does not look like HTTP Basic. Did you try different browsers? IE, Chrome, 
FF? Do you get same behavior with all? Is the user logging in member of the 
domain your IWA is set up to?

If you set up a 3rd party IWA provider (such as Waffle), does it act the same 
on all 3 browsers? There was a recent issue with Waffle that one of my 
developers submitted that was dealing with similar issues [1]. You might want 
to go over that thread to see it can give you pointers.


[1] https://github.com/dblock/waffle/issues/268

-Original Message-
From: Chanchal Kariwala [mailto:chanchal.kariw...@seclore.com] 
Sent: Friday, March 04, 2016 2:52 AM
To: Tomcat Users List 
Subject: Re: Windows Authentication

But how does the browser decide on Basic Auth?

Usually 401 Response contains WWW-Authenticate: Basic realm="MyREALM" to 
indicate Basic Auth

Thanks,
Chanchal R. Kariwala
Product Engineer
Seclore Technology
chanchal.kariw...@seclore.com
www.seclore.com



On Fri, Mar 4, 2016 at 3:16 PM, André Warnier (tomcat) 
wrote:

> On 04.03.2016 10:11, Chanchal Kariwala wrote:
>
>> I tries what you asked and I have observed the following
>>
>> 1. Browser sends a request for the resource Server replies with HTTP 
>> 401 and WWW-Authenticate: Negotiate in Response Headers
>>
>
> Fine.
>
>
>> 2. Browser sends a new request with the following in Request Headers
>> Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBg
>>
>>
> Also seems fine. (But difficult to tell, as these tokens are "opaque" by
> design).
>
> Server replies again with HTTP 401 and WWW-Authenticate: Negotiate in
>> Response Headers
>>
>>
> But this does not seem ok. It seems that the browser and server are
> failing to agree on an authentication method, and dropping down to HTTP
> Basic.
>
>
> 3. At this point the browser shows HTTP Basic Auth form and sends the
>> following in Headers
>> Authorization: Negotiate
>> YIIK1QYGKwYBBQUCoIIKyTCCCsWgMDAuBgkqhkiC9xIBAgIGCSqGS (*Really huge
>> value, much much longer than the first one*)
>>
>> Now the Server replies with HTTP 200 and the following in headers
>> WWW-Authenticate: Negotiate oYHzMIHwoAMKAQChCwYJKoZIhvcSAQICom0
>> Set-Cookie: JSESSIONID=541FE2EDD35690BBDE99..; Path=/webapp/; HttpOnly
>>
>> So yes WIA is failing..
>> Can you help me out with the next step in debugging?
>>
>>
> I think at this point, you need to go to your Windows network sysadmins,
> with the information above, and ask them what is going on.
> There are just too many possible reasons, in the Windows Domain
> environment, why this could fail. (browser, browser version, workstation OS
> version, browser settings, Domain Controller settings, Domain networkn
> policies, membership of Domain or not, etc.).
>
>
>>
>>
>> Thanks,
>> Chanchal R. Kariwala
>> Product Engineer
>> Seclore Technology
>> chanchal.kariw...@seclore.com
>> www.seclore.com
>>
>>
>>
>> On Fri, Mar 4, 2016 at 1:20 PM, André Warnier (tomcat) 
>> wrote:
>>
>> On 04.03.2016 07:16, Chanchal Kariwala wrote:
>>>
>>> I am using Tomcat 8.0.32 and I have followed the guide given at

  -


 https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html#Tomcat_instance_(Windows_server)
  -


 https://dzone.com/articles/do-not-publish-configuring-tomcat-single-sign-on-w

 Windows AD Auth is working i.e. when I access the site, I am asked for
 credentials and when I enter the correct credentials, the restricted
 resource is displayed.

 However my question is why the browser is asking for credentials? Why
 isn't
 it accessing TGT Cache in the OS to fetch the user's credentials?

 I have enabled Integrated Windows Auth in IE Settings. I have added the
 site in Intranet Sites and set "Logon by Current User" in Custom Level
 setting for Intranet.



 Hi.
>>>
>>> The real *key* to debugging such issues, is to use some plugin or add-on
>>> to the browser, to enable the capture and visualisation of the HTTP
>>> dialog
>>> back and forth between the browser and the server.
>>> Since you are using IE, I suggest "Fiddler2".
>>> Install it, close your browser, re-open the browser, start Fiddler2 in
>>> capture mode, and then do an access to the webserver.  When prompted for
>>> an
>>> id/pw, enter them.
>>> Then stop Fiddler2 and examine the HTTP exchanges, starting with your
>>> initial request to the webserver.
>>>
>>> You are correct in thinking that, normally, the login should happen
>>> automatically in the background, and you should never see this browser
>>> login dialog.
>>> WIA authentication is a multiple-step process between the browser and the
>>> webserver, and in the background between the webserver and a Domain
>>> Controller.
>>> That the login dialog appears in your case, means :
>>> 1) that the integrated WIA failed
>>> 2) that the Domain is configured to allow HTTP Basic authentication in a
>>> 

RE: Relative redirects in light of recent changes

2016-02-10 Thread George Stanchev
> > However, with useRelativeRedirects="false" I see
> >
> > GET http://hostname/myapp?m=n=p
> >   ==> 302: "http://hostname/login?a=b=d;
> >
> > The questions I have are 2: First, what happened with the trailing slash
> redirect. I vaguely remember discussions around it but I couldn't find them
> on the mailing list search index. And secondly but more importantly, in 
> 7.0.64,
> the HttpServletRequest.sendRedirect() would use the application name to
> form the Location header value (as in .../myapp/login...) whereas in 7.0.67
> the name of the application is missing from the absolute redirect.
> >
> > Is there any way to work around this and to have 7.0.67 behave like 7.0.64?
> 
> Setting mapperContextRootRedirectEnabled="true" on the Context should
> fix it.
> 
> Mark
> 
> Thanks Mark. So if I understand correctly, 7.0.68 will return to adding the
> trailing slash automatically just like 7.0.64 did. That for now can be worked
> around by setting that attribute above on the context for now.
> 
> With the trailing slash optional though, the code in
> "org.apache.catalina.connector.Response#toAbsolute(String)" still seems will
> yield wrong redirect URLs for the case where someone is running with trailing
> slash redirect disabled:
> 
> String relativePath = request.getDecodedRequestURI();
> int pos = relativePath.lastIndexOf('/');
> ...
> } else {
> encodedURI = urlEncoder.encodeURL(relativePath, 0, 
> pos);
> }
> 
> In case of relativePath being "/myapp" (which will be the case when somone
> runs with traliling-slash-redirect being turned off), encodedURI will be "".
> 
> So it seems to me either TC should *always* force those trailing-slash-
> redirects or fix the code above to correctly calculate the encodedURI from
> the relativePath...

Tomcat is generating 404 if I make a GET on [1] but succeeding on [2]. No 
mapper attributes are set on the context. I think I am missing something 
fundamental here but I don't know what. Servlet is mapped as /login in the 
deployment descriptor. Is there any reference where I can read up on this stuff?

[1] http://hostname/myapp/login/?a=b=d
[2] http://hostname/myapp/login?a=b=d


RE: Relative redirects in light of recent changes

2016-02-09 Thread George Stanchev

> However, with useRelativeRedirects="false" I see
> 
> GET http://hostname/myapp?m=n=p 
>   ==> 302: "http://hostname/login?a=b=d;
> 
> The questions I have are 2: First, what happened with the trailing slash 
> redirect. I vaguely remember discussions around it but I couldn't find them 
> on the mailing list search index. And secondly but more importantly, in 
> 7.0.64, the HttpServletRequest.sendRedirect() would use the application name 
> to form the Location header value (as in .../myapp/login...) whereas in 
> 7.0.67 the name of the application is missing from the absolute redirect.
> 
> Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

Setting mapperContextRootRedirectEnabled="true" on the Context should fix it.

Mark


Thanks Mark. So if I understand correctly, 7.0.68 will return to adding the 
trailing slash automatically just like 7.0.64 did. That for now can be worked 
around by setting that attribute above on the context for now.

With the trailing slash optional though, the code in 
"org.apache.catalina.connector.Response#toAbsolute(String)" still seems will 
yield wrong redirect URLs for the case where someone is running with trailing 
slash redirect disabled:

String relativePath = request.getDecodedRequestURI();
int pos = relativePath.lastIndexOf('/');
...
} else {
encodedURI = urlEncoder.encodeURL(relativePath, 0, pos);
}

In case of relativePath being "/myapp" (which will be the case when somone runs 
with traliling-slash-redirect being turned off), encodedURI will be "".

So it seems to me either TC should *always* force those 
trailing-slash-redirects or fix the code above to correctly calculate the 
encodedURI from the relativePath...

George


RE: Relative redirects in light of recent changes

2016-02-08 Thread George Stanchev

In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
defaults it to "true"), I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "login?a=b=d"

Now, this is expected behavior given the fix for [1]

[1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917


I reread my email, and it is incorrect that is expected behavior. I guess an 
expected behavior would be 

GET http://hostname/myapp?m=n=p 
  ==> 302: "myapp/login?a=b=d"

unless I am missing something badly...

George



Relative redirects in light of recent changes

2016-02-08 Thread George Stanchev
Hi,

Recent changes to Tomcat altered the behavior of our applications a bit so I've 
got couple of questions. The versions in questions are 7.0.64 and 7.0.67. I am 
aware of which is also described in the changelog for 7.0.67.

I have a filter acts on application "/myapp" that does a redirect in the 
following manner:

httpResponse.sendRedirect("login?a=b=d")

In Tomcat 7.0.65 I can see the following flow (the text after the 302 below is 
the value of the "Location" header as seen by network sniffer):

GET http://hostname/myapp?m=n=p  
  ==> 302: "http://hostname/myapp/?m=n=p;
GET http://hostname/myapp/?m=n=p 
  ==> 302: "http://hostname/myapp/login?a=b=d;

The first redirect adds a trailing slash after "myapp", the second is generated 
by my redirect

In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
defaults it to "true"), I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "login?a=b=d"

Now, this is expected behavior given the fix for [1]

However, with useRelativeRedirects="false" I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "http://hostname/login?a=b=d;

The questions I have are 2: First, what happened with the trailing slash 
redirect. I vaguely remember discussions around it but I couldn't find them on 
the mailing list search index. And secondly but more importantly, in 7.0.64, 
the HttpServletRequest.sendRedirect() would use the application name to form 
the Location header value (as in .../myapp/login...) whereas in 7.0.67 the name 
of the application is missing from the absolute redirect.

Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

George

[1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917
[2] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html



RE: Relative redirects in light of recent changes

2016-02-08 Thread George Stanchev


Hi,

Recent changes to Tomcat altered the behavior of our applications a bit so I've 
got couple of questions. The versions in questions are 7.0.64 and 7.0.67. I am 
aware of which is also described in the changelog for 7.0.67.

I have a filter acts on application "/myapp" that does a redirect in the 
following manner:

httpResponse.sendRedirect("login?a=b=d")

In Tomcat 7.0.65 I can see the following flow (the text after the 302 below is 
the value of the "Location" header as seen by network sniffer):

GET http://hostname/myapp?m=n=p  
  ==> 302: "http://hostname/myapp/?m=n=p;
GET http://hostname/myapp/?m=n=p 
  ==> 302: "http://hostname/myapp/login?a=b=d;

The first redirect adds a trailing slash after "myapp", the second is generated 
by my redirect

In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
defaults it to "true"), I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "login?a=b=d"

Now, this is expected behavior given the fix for [1]

However, with useRelativeRedirects="false" I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "http://hostname/login?a=b=d;

The questions I have are 2: First, what happened with the trailing slash 
redirect. I vaguely remember discussions around it but I couldn't find them on 
the mailing list search index. And secondly but more importantly, in 7.0.64, 
the HttpServletRequest.sendRedirect() would use the application name to form 
the Location header value (as in .../myapp/login...) whereas in 7.0.67 the name 
of the application is missing from the absolute redirect.

Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

George

[1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917
[2] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html



Stepped through the code, and what I thought it is an irrelevant question (what 
happened to the trailing slash redirect) might hold the key to the problem.

In org.apache.catalina.connector.Response#toAbsolute(String 
location="login?a=b=d")
...
boolean leadingSlash = location.startsWith("/"); // evaluates to false since 
it’s a relative URI
...
if (!leadingSlash) { // false so we go in
String relativePath = request.getDecodedRequestURI(); // 
evaluates to "/myapp"
int pos = relativePath.lastIndexOf('/'); // evaluates to 0
...
encodedURI = urlEncoder.encodeURL(relativePath, 0, pos); // pos is 0 so 
encodedURI is empty
...
redirectURLCC.append(encodedURI);  // " http://hostname + "" => same URL
redirectURLCC.append('/');
redirectURLCC.append(location, 0, location.length()); final: 
"http://hostname/login?a=b=d; which is a wrong URL...

"http://hostname/myapp/?m=n=p; (with trailing slash before ?) works just fine.

So my question becomes - how do I make it add the trailing slash as in 7.0.64...

George





RE: Unable to find IIS Tomcat Connector 1.2.41 dll

2016-02-03 Thread George Stanchev
You might want to explore this thread:

http://marc.info/?l=tomcat-user=145399491702444=2

which also points to this thread

http://tomcat.markmail.org/message/lyxmf5zof5csf6bn

Regards,
George

-Original Message-
From: McKenzie, Mitch [mailto:mmcken...@markelcorp.com] 
Sent: Wednesday, February 03, 2016 3:41 PM
To: users@tomcat.apache.org
Subject: Unable to find IIS Tomcat Connector 1.2.41 dll

I can find the 1.2.40 here:



http://mirror.symnds.com/software/Apache/tomcat/tomcat-connectors/jk/binaries/windows/



Any idea where I can find the 1.2.41 dll?



Thank you.



Mitch



This message has been scanned for malware by Websense. www.websense.com

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



RE: client ssl renegotiation after invalidating session

2016-02-01 Thread George Stanchev
Yeah I forgot to mention that this works for NIO and BIO connectors. Not sure 
about the APR. And been there in regards to the caching in the browser. There 
is nothing I have found either...

George


-Original Message-
From: Gael Abadin [mailto:gael.aba...@imatia.com] 
Sent: Monday, February 01, 2016 2:17 AM
To: Tomcat Users List
Subject: Re: client ssl renegotiation after invalidating session

Thank you very much for your reply,

I tried your solution on APR, NIO and BIO connectors but it seems my problem 
comes from somewhere else.

From what I could gather, it is a matter of browser SSL credentials store 
mechanism, and it doesn't seem to have a solution yet (even the suggested
window.crypto.logout() for Firefox doesn't work for me. Firefox doesn't seem to 
implement that function on its latest version):

http://stackoverflow.com/questions/10487205/https-client-certificate-logout-relogin
:

http://stackoverflow.com/questions/10229027/how-to-trigger-ssl-rehandshake-on-a-web-browser


For the time being I'll just warn the users that they are not being truly 
logged out until they close all browser windows.


2016-01-29 18:56 GMT+01:00 George Stanchev <gstanc...@serena.com>:

>
> 
> -Original Message-
> From: Gael Abadin [mailto:gael.aba...@imatia.com]
> Sent: Friday, January 29, 2016 10:33 AM
> To: Tomcat Users List
> Subject: client ssl renegotiation after invalidating session
>
> I want to invalidate the client ssl cert authentication after the user 
> logs out of my application.
>
> There is nothing about it in the docs and google just digs out this 
> unanswered old thread from this users list in 2007:
>
>
> https://mail-archives.apache.org/mod_mbox/tomcat-users/200706.mbox/%3C
> 306958.89260...@web36804.mail.mud.yahoo.com%3E
>
> Does anybody know if there is any way to do it?
> 
>
> Depends what your version of Tomcat is. Since we skipped from 5.5 to 
> 7.0 I don't know if 6 has this attribute. For 5.5 we used reflection 
> to dig into the Request object and dig the SSLSessionManager which was 
> kind of annoying since things shifted underground and we had to 
> readjust for different releases of 5.5
>
>
>
> private static boolean
> invalidateTomcat7AndAboveSSLSession(HttpServletRequest httpRequest) {
> String serverInfo =
> FedSrvServlet.getServletContainerServerInfo();
>
> if (serverInfo == null) {
> log.error("Failed to determine server version");
> return false;
> }
>
> boolean compatibleTomcat =
> (serverInfo.indexOf("Tomcat") > 0 &&
> serverInfo.indexOf("7.0") > 0) ||
> (serverInfo.indexOf("Tomcat") > 0 &&
> serverInfo.indexOf("8.0") > 0) ||
> (serverInfo.indexOf("Tomcat") > 0 &&
> serverInfo.indexOf("9.0") > 0);
>
> if (compatibleTomcat) {
> // Invalidate the SSL Session
> (org.apache.tomcat.util.net.SSLSessionManager)
> Method invalidateSessionMethod = null;
> Object mgr =
> httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr");
> if (mgr != null) {
> try {
> invalidateSessionMethod = 
> mgr.getClass().getMethod("invalidateSession");
> if (invalidateSessionMethod ==
> null) {
> log.error("Failed to 
> reset SSL session: Method invalidateSessionMethod =
> mgr.getClass().getMethod(\"invalidateSession\") failed to return method");
> }
>
> invalidateSessionMethod.setAccessible(true);
> } catch (Throwable t) {
> log.error("Failed to reset SSL
> session: " + t.getMessage(), t);
> }
>
> // Invalidate the session
> try {
>
> invalidateSessionMethod.invoke(mgr);
> log.trace("SSL session reset 
> successfully");
> return true;
> } catch (Throwable t) {
> log.error("Failed to reset SSL
> session: invalidateSession() threw exception: " + t.getMessage(), t);
> }
> } els

RE: client ssl renegotiation after invalidating session

2016-01-29 Thread George Stanchev


-Original Message-
From: Gael Abadin [mailto:gael.aba...@imatia.com] 
Sent: Friday, January 29, 2016 10:33 AM
To: Tomcat Users List
Subject: client ssl renegotiation after invalidating session

I want to invalidate the client ssl cert authentication after the user logs out 
of my application.

There is nothing about it in the docs and google just digs out this unanswered 
old thread from this users list in 2007:

https://mail-archives.apache.org/mod_mbox/tomcat-users/200706.mbox/%3c306958.89260...@web36804.mail.mud.yahoo.com%3E

Does anybody know if there is any way to do it?


Depends what your version of Tomcat is. Since we skipped from 5.5 to 7.0 I 
don't know if 6 has this attribute. For 5.5 we used reflection to dig into the 
Request object and dig the SSLSessionManager which was kind of annoying since 
things shifted underground and we had to readjust for different releases of 5.5



private static boolean invalidateTomcat7AndAboveSSLSession(HttpServletRequest 
httpRequest) {
String serverInfo = 
FedSrvServlet.getServletContainerServerInfo();

if (serverInfo == null) {
log.error("Failed to determine server version");
return false;
}

boolean compatibleTomcat =
(serverInfo.indexOf("Tomcat") > 0 && 
serverInfo.indexOf("7.0") > 0) ||
(serverInfo.indexOf("Tomcat") > 0 && 
serverInfo.indexOf("8.0") > 0) ||
(serverInfo.indexOf("Tomcat") > 0 && 
serverInfo.indexOf("9.0") > 0);

if (compatibleTomcat) {
// Invalidate the SSL Session 
(org.apache.tomcat.util.net.SSLSessionManager)
Method invalidateSessionMethod = null;
Object mgr = 
httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr");
if (mgr != null) {
try {
invalidateSessionMethod = 
mgr.getClass().getMethod("invalidateSession");
if (invalidateSessionMethod == null) {
log.error("Failed to reset SSL 
session: Method invalidateSessionMethod = 
mgr.getClass().getMethod(\"invalidateSession\") failed to return method");
}

invalidateSessionMethod.setAccessible(true);
} catch (Throwable t) {
log.error("Failed to reset SSL session: 
" + t.getMessage(), t);
}

// Invalidate the session
try {
invalidateSessionMethod.invoke(mgr);
log.trace("SSL session reset 
successfully");
return true;
} catch (Throwable t) {
log.error("Failed to reset SSL session: 
invalidateSession() threw exception: " + t.getMessage(), t);
}
} else {
log.error("Failed to reset SSL session: 
httpRequest.getAttribute(\"javax.servlet.request.ssl_session_mgr\") call failed 
to return session manager object");
}
}

return false;
}

Hope this helps.

George


RE: AW: AW: Suppress or replace WWW-Authorization header

2015-10-28 Thread George Stanchev

On 28.10.2015 17:42, Torsten Rieger wrote:
> -Ursprüngliche Nachricht-
> Von: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Gesendet: Mittwoch, 28. Oktober 2015 16:45
> An: Tomcat Users List 
> Betreff: Re: AW: Suppress or replace WWW-Authorization header
>
> You can choose between a pop-up or an HTML FORM
>
> This one looks like this in web.xml :
>
>
>  FORM
>  webapp global realm
>  
>/login.jsp
>/error_login.jsp
>  
>
>
>
>
>
> 2015-10-28 16:28 GMT+01:00 Torsten Rieger :
>
>> -Ursprüngliche Nachricht-
>> Von: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Gesendet: Mittwoch, 28. Oktober 2015 15:39
>> An: Tomcat Users List 
>> Betreff: Re: AW: Suppress or replace WWW-Authorization header
>>
>> Torsten,
>>
>> On 10/28/15 8:19 AM, Torsten Rieger wrote:
>>> I have a legacy java-SOAP-client that only supports BASIC 
>>> authentication (send the Authorization: Basic... header) and a 
>>> AngularJS application that consumes a REST-service (also sending the
>>> Authorization: Basic header).
>>>
>>> The server supports two kinds of deployment: Standalone with an 
>>> embedded Jetty-server and as war-file for app-servers (most of them 
>>> are tomcat-server). I try to suppress the browser BASIC-login-dialog 
>>> for the REST-service-calls from AngularJS.
>>> On Jetty I modify the 401-responses and replace the "WWW-Authenticate"
>>> header by anything else than "BASIC" and that works, now I try to 
>>> find a solution for the deployment on tomcat servers.
>>>
>>> Rewrite (unset header in responses) with an apache proxy in front of 
>>> the tomcat is unfortunately not a solution I can implement.
>>>
>>> So I'm looking for a solution to remove or modify the headers in 401 
>>> responses on application server level.
>>
>> So you just want to disable HTTP BASIC authentication? Why not just 
>> remove the  from web.xml and disable authentication entirely?
>>
>> Are you saying that when you connect using a REST client, the client 
>> shows a login dialog in a web browser? That sounds ... weird. The 
>> REST client should see the WWW-Authenticate header and either (a) 
>> fail or
>> (b) re-try with credentials you have provided to it.
>>
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>> No, container BASIC authentication should be enabled, the container 
>> should handle the authentication, but the browser should not show his 
>> ugly default login dialog when I request resources from the 
>> REST-service with wrong credentials.
>> When the REST-client (web-application in the browser) receives a 
>> failed login with a WWW-Authenticate header, the default dialog of 
>> the browser will be shown... that’s what I want to suppress.
>>
>> When I remove the (a)  or (b)   sending 
>> requests with credentials will not work anymore (a: 403 forbidden; b:
>> deployment fails). But that's not a solution because the rest-service 
>> should be still protected and I need to authenticate via "Authentication:
>> Basic ."
>> header send credentials, but I don't want to show the ugly 
>> browser-dialog to the users.
>>
>> Using a AngularJS Client with REST-services based on tomcat should be 
>> a common use-case, it could not be that I'm the first one who wants a 
>> custom login-screen. :-/
>>


Torsten,
the people answering on this list are generally competent and helpful.
But they are not magicians.  You seem (so far) to be asking something 
impossible.
1) if the server sends to the client an authentication header saying HTTP 
Basic, then the client will popup a builtin HTTP Basic dialog (which you do not 
want)
2) if the server sends to the client an authentication header saying something 
else, then the client cannot handle it

1 + 2 = solution impossible

You mentioned before that with another server than Tomcat, you solved this 
apparently impossible problem.  Can you tell us how ?

Or else, can you tell us which authentication methods, /apart/ from HTTP Basic, 
the client does support ?


Perhaps the OP wants this page [1]. It describes a technique which appears to 
do what he wants.

George


[1] https://www.freelock.com/2008/06/technical-note-http-auth-with-ajax

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



RE: Tomcat Server and PHP Extensions

2015-10-28 Thread George Stanchev
You need Apache, not Tomcat

-Original Message-
From: Chris Thompson [mailto:cthomp...@conveyor-dynamics.com] 
Sent: Wednesday, October 28, 2015 5:20 PM
To: users@tomcat.apache.org
Subject: Tomcat Server and PHP Extensions

Does Tomcat Server support PHP extensions?

I am looking at installing TeamPass on our system and it requires PHP.

Thanks,
Christopher


-
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: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-15 Thread George Stanchev
Aurélien,

I added good_run.pcap and bad_run.pcap to that dropbox location [1]. 

I also think this needs to be looked at by MS engineers. I am following up on 
my support case but really not getting anywhere...

George

[1] https://www.dropbox.com/sh/az1r3agxx4w8r7e/AACRGedBG3G5oh4-qE9652WNa?dl=0
-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Thursday, October 15, 2015 7:43 AM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

George,

I'm not sure we can find any solution, but can we have a look at a pcap capture 
?
Esmond Pitt was posting sometimes, that would be a challenge for him.

2015-10-15 4:33 GMT+02:00 Christopher Schultz 
:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Aurélien,
>
> On 10/14/15 5:59 PM, Aurélien Terrestris wrote:
> > Still no solutions, I suppose..
> >
> > Did you enable the SSLv2 Hello as suggested by Chris, and what's the 
> > result ? I tested a small client with Java 8, by adding 
> > -Djdk.tls.client.protocols="SSLv2Hello,TLSv1.2" at the command line, 
> > and I get my SSLv2 Hello.
>
> It looks like if you add SSLv2Hello to the list of protocols you'll 
> accept, you'll get an SSLv2Hello in there (abridged output):
>
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> ...
> main, WRITE: TLSv1.2 Handshake, length = 221 main, WRITE: SSLv2 client 
> hello message, length = 140 main, READ: TLSv1.2 Handshake, length = 81 
> main, READ: TLSv1.2 Handshake, length = 2779 main, READ: TLSv1.2 
> Handshake, length = 589 main, READ: TLSv1.2 Handshake, length = 4 
> main, WRITE: TLSv1.2 Handshake, length = 70 main, WRITE: TLSv1.2 
> Change Cipher Spec, length = 1 main, WRITE: TLSv1.2 Handshake, length 
> = 40 main, READ: TLSv1.2 Change Cipher Spec, length = 1 main, READ: 
> TLSv1.2 Handshake, length = 40
>
> You just have to use a custom SSLSocketFactory that sets the protocols 
> you want to enable on the (client) socket. If one of the protocols you 
> use is "SSLv2Hello".
>
> Oddly enough, when *not* specifying SSLv2Hello, you'll get this 
> (abridged output):
>
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> ...
> main, WRITE: TLSv1.2 Handshake, length = 221 main, READ: TLSv1.2 
> Handshake, length = 89 main, READ: TLSv1.2 Handshake, length = 2779 
> main, READ: TLSv1.2 Handshake, length = 589 main, READ: TLSv1.2 
> Handshake, length = 4 main, WRITE: TLSv1.2 Handshake, length = 70 
> main, WRITE: TLSv1.2 Change Cipher Spec, length = 1 main, WRITE: 
> TLSv1.2 Handshake, length = 40 main, READ: TLSv1.2 Change Cipher Spec, 
> length = 1 main, READ: TLSv1.2 Handshake, length = 40
>
> When the SSLv2Hello "protocol" isn't enabled, you don't get the "main, 
> WRITE" and "main, READ"
>
> Note that I'm not trying anything with a client certificate, here. I 
> hope that helps somewhat.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWHxCIAAoJEBzwKT+lPKRYCNQQAMJx3cHj3Rl8ieX+2cANmXfW
> fHr0MPkHNIcbzpX5WWJaEqfhnYqQTk9TiY7rKxwjo3OtJtEG1bkm9tqeq4pzHJcX
> oQ03/wMOKrNqqGoILcpdWgRpc0jylsx1GouJ2qmmCNvZO1fBdBhtAE49dvg4Hd+c
> uOzet5CizkTIfbu/i2Rb/szC9T/mopvicOsoS7oe1EE7sJZKL4BU3ayun5KvFXvr
> 0KbDRU0Btp3M0YcPP4R2MtExYROW9pwwb5UYJdmK8ZxHAsmhJsG8DzDQnywFEx3+
> cm2e0W5v5FMAAh3PBNqfl5VN/8uIlHkeLtCjDU0JCMCfguwTQbitPpyhatnRlE7z
> K8FfdZUC2zBprX1HnJl5aT02u3STzRsyL5DWlVAKPC/OAUEYFO26Ira1K86ACpww
> O7t6phwHfXdGIkT/GdT9i2DgGippj6/mAhgq6XUsAkVr9usK33pNP8q/jf/ORwq/
> Njf4d4vjRNw3W7UZ0w0NCgZ7dKdepC/x2sT6zugQugiLNQ+gHGQWfcOhrQsRsj8f
> qHGU1E+94g5oQCqb14KWoZv8bAA2WYAqgUK3DK2icsiCEFqWd6Yb6gYcvIGsbV9t
> g+Mtxfm5qjncCwHeyONd3uBWTjakZb7fIvk4di0pZcnZB7HFYx7/r0ndS+IRzUVS
> LJxWiHhKQZ32QvVKtBxe
> =zKZ4
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-14 Thread George Stanchev
Yeah it's in my msg below. Java logs it sequentially and I was looking at where 
the payload was created, not wher it was serialized [1]. I realized my mistake 
when I took a pcap and then had a closer look at the logs. I also know how this 
is handled in the JSSE code - the hello wrapper is handled by I/O layer, not by 
the handshaker...


I don't think https://www.ietf.org/rfc/rfc5246.txt 's Appendices E.1 and E.2 
refer to my situation. They talk about initial handshakes, which in my case go 
just fine.

Regarding the last remark, about 2 handshakes without data inbetween - it's not 
like I am handling raw sockets. In one case the clinet is HttpsUrlConnection, 
the other is the Apache HttpClient 3. Also, since I have put together an 
SChannel server I can see the data in between the handshakes making it 
through...

George


[1] 

*** ClientHello, TLSv1 <* I was looking here
RandomCookie:  
Session ID:  {}
Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA]
Compression Methods:  { 0 }
Extension renegotiation_info, renegotiated_connection: 
***
[write] MD5 and SHA1 hashes:  len = 52
...
main, WRITE: TLSv1 Handshake, length = 52
[write] MD5 and SHA1 hashes:  len = 47
...
main, WRITE: SSLv2 client hello message, length = 47  <* 
But it went out here where it got serialized
[Raw write]: length = 49
... 
[Raw read]: length = 5
: 16 03 01 02 E7 .
[Raw read]: length = 743
...main, READ: TLSv1 Handshake, length = 743
*** ServerHello, TLSv1

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Wednesday, October 14, 2015 3:59 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Still no solutions, I suppose..

Did you enable the SSLv2 Hello as suggested by Chris, and what's the result ? I 
tested a small client with Java 8, by adding 
-Djdk.tls.client.protocols="SSLv2Hello,TLSv1.2" at the command line, and I get 
my SSLv2 Hello.

From the TLS 1.2 RFC ( https://www.ietf.org/rfc/rfc5246.txt ) we know we must 
expect some problems like yours (Appendix E.1 & E.2). I'm not saying it's that 
kind of things for sure, but this is what they suggest :

"Interoperability with such buggy servers is a complex topic beyond the scope 
of this document, and may require multiple connection attempts by the client."

And that's what HttpUrl class does, a retry.


I am not sure that we can blindly trust the JSSE Ref Guide , but it's saying 
that the renegotiation (for your client cert) has to happen after some data was 
already been sent to each other. My question is : are you sure you are not 
doing 2 handshakes without sending data between them ?

See :
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization
*"Encrypted data*
The client and the server communicate using the symmetric encryption algorithm 
and the cryptographic hash function negotiated during the client hello and 
server hello, and using the secret key that the client sent to the server 
during the client key exchange. The handshake can be renegotiated at this time. 
See the next section for details."






2015-10-14 4:56 GMT+02:00 George Stanchev <gstanc...@serena.com>:

> So this time I spoke too soon. I was relying on Java to dump in its 
> debug trace. Running rawcap/wireshark does reveal that Java indeed 
> wraps the
> TLSv1.2 hello payload in SSLv2Hello record envelope which that legacy 
> protocol enables. The Java piece of code that I quoted was for the 
> content of the ClientHello record, not how it is wrapped which happens 
> later when the record is being serialized to the socket...
>
> Anyways, thanks to all for the tip but it doesn't make a 
> difference...still bad mac record...
>
> George
>
> -Original Message-
> From: George Stanchev [mailto:gstanc...@serena.com]
> Sent: Tuesday, October 13, 2015 3:56 PM
> To: Tomcat Users List
> Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> May be I am mistaken. I will give jtouch a try, thanks for the 
> pointers...at this point I am grasping at straws :)
>
> Thanks Aurelien!
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:52 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> "Another route to try the SSLv2Hello is to hack and recompile the JSSE.
> It's on my agenda to learn to do that if possible without rebuilding 
> the whole JRE since for some obscure reason Oracle compiles JSSE with 
> no debug info (and it is not included in the srcs distributed with the 
> JRE) on it which makes

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
So this time I spoke too soon. I was relying on Java to dump in its debug 
trace. Running rawcap/wireshark does reveal that Java indeed wraps the TLSv1.2 
hello payload in SSLv2Hello record envelope which that legacy protocol enables. 
The Java piece of code that I quoted was for the content of the ClientHello 
record, not how it is wrapped which happens later when the record is being 
serialized to the socket...

Anyways, thanks to all for the tip but it doesn't make a difference...still bad 
mac record...

George

-Original Message-
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Tuesday, October 13, 2015 3:56 PM
To: Tomcat Users List
Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

May be I am mistaken. I will give jtouch a try, thanks for the pointers...at 
this point I am grasping at straws :)

Thanks Aurelien!

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
Sent: Tuesday, October 13, 2015 3:52 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"Another route to try the SSLv2Hello is to hack and recompile the JSSE.
It's on my agenda to learn to do that if possible without rebuilding the whole 
JRE since for some obscure reason Oracle compiles JSSE with no debug info (and 
it is not included in the srcs distributed with the JRE) on it which makes 
debugging and inspecting local vars really hard..."

No, it's not needed. I use jtouch.sourceforge.net and it's working well for 
trying SSLv2 hello's. From the network captures, I see that it's working.
Not making advertisement for my software here, but,.. ;)







2015-10-13 23:20 GMT+02:00 George Stanchev <gstanc...@serena.com>:

> Just as a side note, https.protocols is read by HttpsUrlConnection 
> which feeds it down through setEnabledProtocols() on the SSL socket. "
> jdk.tls.client.protocols" is read directly by JSSE and does the same 
> thing...
>
> Another route to try the SSLv2Hello is to hack and recompile the JSSE.
> It's on my agenda to learn to do that if possible without rebuilding 
> the whole JRE since for some obscure reason Oracle compiles JSSE with 
> no debug info (and it is not included in the srcs distributed with the
> JRE) on it which makes debugging and inspecting local vars really hard...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:13 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> Maybe writing too fast..
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> As suggested before, by writing your own client OR by trying this hack.
> From the JSSE Ref Guide 5, we know how to the customize the protocol ( 
> https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefG
> uide.html#InstallationAndCustomization
> ) by setting a system property (https.protocol). Although they are no 
> more talking about this in the Ref Guide 8 ( 
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunPro
> viders.html#SunJSSEProvider
> ) I would give it a try as I know that the documentation is poorly written.
> I suggested 10 years ago a change in the API doc about the enabled 
> protocols, and they didn't change anything although they said they would.
>
>
>
> "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  
> (Will not send, but will accept SSLv2Hellos)""
>
> I believe they mean "by default" as for the client side. Poorly 
> written, probably.
>
>
>
> 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:
>
> > "How do you force Java 8 to use SSLv2Hello?"
> >
> > You can do this when writing your own Java client : calling the 
> > SSLSocketFactory to create an SSLSocket and configure with 
> > setEnabledProtocols ( 
> > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.ht
> > ml
> > #setEnabledProtocols-java.lang.String:A-
> > )
> >
> > If you have some IIS server on internet which reproduces the 
> > problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write a small 
> > client.
> >
> >
> >
> >
> > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:
> >
> >> George,
> >>
> >> do you have any network capture that we can see ?
> >>
> >> 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:
> >>
> >>> >> It might be doable with OpenSSL s_client or something. Tough t

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
Hi Chris,

How do you force Java 8 to use SSLv2Hello? So far I am unable to force it to go 
down to use SSLv2Hello. It would've been nice to be able to control the first 
handshake message version (TLSv1 or TLSv1.2 or SSLv2Hello), but I have not been 
able to do that...

George

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, October 13, 2015 7:42 AM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/9/15 12:46 PM, George Stanchev wrote:
> One more clarification: on point [6] below I stated that Java is able 
> to recover with a retry on a cached connection. Unfortunately that is 
> only valid for higher level classes like HttpUrlConnection which makes 
> 1 retry on IOException (and only on a GET and some other conditions). 
> The lower-level sockets just throw and that’s it...

Can you confirm whether using SSLv2Hello also solves the problem? Or do you 
have a requirement that nothing less than TLSv1 may even handshake properly?

- -chris

> -Original Message- From: George Stanchev 
> [mailto:gstanc...@serena.com] Sent: Friday, October 09, 2015 10:40 AM 
> To: Tomcat Users List Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67:
> SEND TLSv1 ALERT: fatal, description = bad_record_mac
> 
> Just for the record, https.protocols is a property used by the 
> HttpsUrlConnection class. If your app is using a client that doesn't 
> rely on the internal Oracle HTTP client, it's better to use " 
> jdk.tls.client.protocols" which is read directly by the socket/SSL 
> classes. Apache Http Client is one client that does use sockets 
> directly instead of HttpsUrlConnection.
> 
> 
> Also, I want to mention that we have finally been able to isolate a 
> really nasty problem with Java SSL implementation and Windows's SSPI 
> based SChannel acting as a server. The issue we ran into is very 
> similar as to what the OP reported, that’s why I asked him a while ago 
> on a separate thread about keystores if the server is IIS-based. The 
> issue that we ran into might sound esoteric but our product ran into 
> it very often. We have a configuration where we lock our 
> intracomponent communication via 2way SSL. We have Java Tomcat-based 
> server components that talk to IIS based native components via web 
> services over HTTP which we secure with 2way SSL. When we upgraded to 
> JRE 8 we started getting those connection resets in Tomcat when we 
> enabled the 2way SSL. Those were on the
> Java->IIS calls that work over regular SSL. On the java side, if
> you turn on the ssl debug on, you'd see connection reset IOException 
> thrown, and on the Windows side, you'd see " The following fatal alert 
> was generated: 20. The internal error state is 960." In the System 
> event log. This error is "
> TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug 
> database found a close resemblance to this issue:
> https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter 
> couldn't reproduce it and also was against another Oracle component 
> Java Web Download or something like this. So we started working with 
> Oracle but the intermittent and hard-to-reproduce nature of this issue 
> hampered the investigation. As the OP mentioned below, there are 
> apocryphal reports for this all over the web but people cannot 
> troubleshoot it very well. Anyway here are my findings. In order for 
> the issue to arise all those conditions must be met:
> 
> [1] The client must start with ClientHello TLSv1.2 [2] The server must 
> respond with ServerHello TLSv1 (so the server should not have
> TLS1.2 enabled) [3] The cipher key exchange must NOT be ECDHE. I have 
> not tried DHE as I could not make Windows take it. According to this 
> doc [1] it should have several DHE key exchange ciphers available but 
> I could not make it work. RSA key exchange exhibits the issue. I have 
> been using “TLS_RSA_WITH_AES_256_CBC_SHA” to reproduce. [4] The 
> initial connection must not be 2way-SSL [5] The server must upgrade 
> the connection after encrypted payload is read.
> In case of IIS, it has 2way SSL setting on a Virtual Directory. The 
> initial handshake is not 2way SSL, once the HTTP request is read, it 
> determines that the requested resource (/gsoap) is 2way SSL-protected 
> and upgrades the connection to 2way SSL. [6] The server must kill the 
> connection abruptly when error happens. This is important as if the 
> server terminates the connection gracefully and keeps it around Java 
> is able to recover since it reuses the cached connection. IIS does 
> exactly this. [7] The server must be Windows 7, Win2k8, Win2k8-R2, 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
Hi Chris,

[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  (Will not 
send, but will accept SSLv2Hellos)"

I've opened support case both MS and already there is a bug filed with Oracle 
on this and really, to be absolutely certain if the issue is in Java or 
SChannel, one would have to write a non-Java client that that mimics the 
handshake messages send from Java with something like OpenSSL or NSS or 
whatever and see if the bug replicates. Writing a Java/Java server client could 
still leave some doubts as one can argue the code reuse could mask the problem 
- it works but the bug on the client side is hidden by the server containing 
similar/same bug so the MACs check out...

Unfortunately I don't have the time to invest in this more than I already had. 
And if MS support engineers can pass it on to someone from the windows core 
team may be we can have some movement forward. 

George


[1] 
http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html

-Original Message-----
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Tuesday, October 13, 2015 10:26 AM
To: Tomcat Users List
Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Hi Chris,

How do you force Java 8 to use SSLv2Hello? So far I am unable to force it to go 
down to use SSLv2Hello. It would've been nice to be able to control the first 
handshake message version (TLSv1 or TLSv1.2 or SSLv2Hello), but I have not been 
able to do that...

George

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, October 13, 2015 7:42 AM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/9/15 12:46 PM, George Stanchev wrote:
> One more clarification: on point [6] below I stated that Java is able 
> to recover with a retry on a cached connection. Unfortunately that is 
> only valid for higher level classes like HttpUrlConnection which makes
> 1 retry on IOException (and only on a GET and some other conditions). 
> The lower-level sockets just throw and that’s it...

Can you confirm whether using SSLv2Hello also solves the problem? Or do you 
have a requirement that nothing less than TLSv1 may even handshake properly?

- -chris

> -Original Message- From: George Stanchev 
> [mailto:gstanc...@serena.com] Sent: Friday, October 09, 2015 10:40 AM
> To: Tomcat Users List Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67:
> SEND TLSv1 ALERT: fatal, description = bad_record_mac
> 
> Just for the record, https.protocols is a property used by the 
> HttpsUrlConnection class. If your app is using a client that doesn't 
> rely on the internal Oracle HTTP client, it's better to use "
> jdk.tls.client.protocols" which is read directly by the socket/SSL 
> classes. Apache Http Client is one client that does use sockets 
> directly instead of HttpsUrlConnection.
> 
> 
> Also, I want to mention that we have finally been able to isolate a 
> really nasty problem with Java SSL implementation and Windows's SSPI 
> based SChannel acting as a server. The issue we ran into is very 
> similar as to what the OP reported, that’s why I asked him a while ago 
> on a separate thread about keystores if the server is IIS-based. The 
> issue that we ran into might sound esoteric but our product ran into 
> it very often. We have a configuration where we lock our 
> intracomponent communication via 2way SSL. We have Java Tomcat-based 
> server components that talk to IIS based native components via web 
> services over HTTP which we secure with 2way SSL. When we upgraded to 
> JRE 8 we started getting those connection resets in Tomcat when we 
> enabled the 2way SSL. Those were on the
> Java->IIS calls that work over regular SSL. On the java side, if
> you turn on the ssl debug on, you'd see connection reset IOException 
> thrown, and on the Windows side, you'd see " The following fatal alert 
> was generated: 20. The internal error state is 960." In the System 
> event log. This error is "
> TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug 
> database found a close resemblance to this issue:
> https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter 
> couldn't reproduce it and also was against another Oracle component 
> Java Web Download or something like this. So we started working with 
> Oracle but the intermittent and hard-to-reproduce nature of this issue 
> hampered the investigation. As the OP mentioned below, there are 
> apocryphal reports for this all over the web but people cannot 
> troubleshoot it very well. Anyway here are my findings. In order for 
> the issue to arise all those conditi

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
>> It might be doable with OpenSSL s_client or something. Tough to replicate 
>> Java's behavior with a non-Java tool, though.

I tried hard with the s_client but it can limit the protocols to one or another 
but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java 8 does. 
Either TLSv1 or TLSv1.2 but not both. Neither can curl which is also on top of 
openssl.

Today, I spent 2.5 hours with a lemming from MS getting basically nowhere. I 
really need an engineer, but they give me those clueless support people that is 
wasting mine and their time. If someone knows how to escalate or a forum where 
MS developers hang out, I would appreciate it. The support person I got today 
was clueless, went over a script and any attempt to explain a little more 
technical details led to total confusion and rebooting the script to beginning. 
Totally frustrating. At least with Oracle I got to talk with an actual 
engineer...

George


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, October 13, 2015 2:03 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/13/15 12:35 PM, George Stanchev wrote:
> [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. 
> (Will not send, but will accept SSLv2Hellos)"

Interesting. This absolutely makes sense, though, since SSL should just die. :)

> I've opened support case both MS and already there is a bug filed with 
> Oracle on this and really, to be absolutely certain if the issue is in 
> Java or SChannel, one would have to write a non-Java client that that 
> mimics the handshake messages send from Java with something like 
> OpenSSL or NSS or whatever and see if the bug replicates.

It might be doable with OpenSSL s_client or something. Tough to replicate 
Java's behavior with a non-Java tool, though.

> Writing a Java/Java server client could still leave some doubts as one 
> can argue the code reuse could mask the problem - it works but the bug 
> on the client side is hidden by the server containing similar/same bug 
> so the MACs check out...
> 
> Unfortunately I don't have the time to invest in this more than I 
> already had. And if MS support engineers can pass it on to someone 
> from the windows core team may be we can have some movement forward.

Okay. Thanks for your work so far.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
+r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF
WGDHUsSBZIYTFq5mc7VO
=eyUN
-END PGP SIGNATURE-

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



RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
Hi Aurelien,

https://www.dropbox.com/sh/az1r3agxx4w8r7e/AACRGedBG3G5oh4-qE9652WNa?dl=0

It's not a pcap but rather javax.debug logger capture which is similar. I can 
do pcap but since java dumps the stream along with handshake messages 
description, I haven't bothered to capture it. This folder also contains the 
test Java client and an SSPI echo server that emulates the problem and has the 
SSPI calls to demonstrate the issue. "cood capture.txt" is when you run with 
TLSv1-only. "bad capture.txt" is when you run with defaults...If you run the 
java client you need to update

final String targetURL = 
"https://rm9485:443/gsoap/gsoap_ssl.dll?sbminternalservices72;;

to point to the correct machine. Uncommenting 
//System.setProperty("jdk.tls.client.protocols", "TLSv1"); makes the call 
succeed. The SSLServer on the native side will return SEC_E_DECRYPT_FAILURE 
from AcceptSecurityContext() when the TLS connection is upgraded to 2way ssl 
after ClientCertVerify's changing of cipher specs. I spent time in the Java 
handshaker and while I don't understand it enough, I saw the failure right 
after it flushes the  running MAC down the stream onto the server. At this 
point SSPI fails the call with bad_mac_record which is behind the code 
SEC_E_DECRYPT_FAILURE...

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 2:23 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

George,

do you have any network capture that we can see ?

2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:

> >> It might be doable with OpenSSL s_client or something. Tough to
> replicate Java's behavior with a non-Java tool, though.
>
> I tried hard with the s_client but it can limit the protocols to one 
> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
> like Java
> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
> is also on top of openssl.
>
> Today, I spent 2.5 hours with a lemming from MS getting basically nowhere.
> I really need an engineer, but they give me those clueless support 
> people that is wasting mine and their time. If someone knows how to 
> escalate or a forum where MS developers hang out, I would appreciate 
> it. The support person I got today was clueless, went over a script 
> and any attempt to explain a little more technical details led to 
> total confusion and rebooting the script to beginning. Totally 
> frustrating. At least with Oracle I got to talk with an actual engineer...
>
> George
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, October 13, 2015 2:03 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> George,
>
> On 10/13/15 12:35 PM, George Stanchev wrote:
> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
> > (Will not send, but will accept SSLv2Hellos)"
>
> Interesting. This absolutely makes sense, though, since SSL should 
> just die. :)
>
> > I've opened support case both MS and already there is a bug filed 
> > with Oracle on this and really, to be absolutely certain if the 
> > issue is in Java or SChannel, one would have to write a non-Java 
> > client that that mimics the handshake messages send from Java with 
> > something like OpenSSL or NSS or whatever and see if the bug replicates.
>
> It might be doable with OpenSSL s_client or something. Tough to 
> replicate Java's behavior with a non-Java tool, though.
>
> > Writing a Java/Java server client could still leave some doubts as 
> > one can argue the code reuse could mask the problem - it works but 
> > the bug on the client side is hidden by the server containing 
> > similar/same bug so the MACs check out...
> >
> > Unfortunately I don't have the time to invest in this more than I 
> > already had. And if MS support engineers can pass it on to someone 
> > from the windows core team may be we can have some movement forward.
>
> Okay. Thanks for your work so far.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
> +r2e20At1qCyey

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to my 
understanding does the same as the system property "jdk.tls.client.protocols". 
It gives the JSSE a pool of protocols to choose from but it will be up to JSSE 
to select the ClientHello version. I might have missed something but I spent 
quite a bit of time in the Handshaker and related classes in the JDK and 
couldn't see anything that can change that...

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 2:55 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"How do you force Java 8 to use SSLv2Hello?"

You can do this when writing your own Java client : calling the 
SSLSocketFactory to create an SSLSocket and configure with setEnabledProtocols (
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
)

If you have some IIS server on internet which reproduces the problem, I'll try 
with JTouch ( jtouch.sourceforge.net ) or write a small client.




2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:

> George,
>
> do you have any network capture that we can see ?
>
> 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:
>
>> >> It might be doable with OpenSSL s_client or something. Tough to
>> replicate Java's behavior with a non-Java tool, though.
>>
>> I tried hard with the s_client but it can limit the protocols to one 
>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
>> like Java
>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
>> is also on top of openssl.
>>
>> Today, I spent 2.5 hours with a lemming from MS getting basically 
>> nowhere. I really need an engineer, but they give me those clueless 
>> support people that is wasting mine and their time. If someone knows 
>> how to escalate or a forum where MS developers hang out, I would appreciate 
>> it.
>> The support person I got today was clueless, went over a script and 
>> any attempt to explain a little more technical details led to total 
>> confusion and rebooting the script to beginning. Totally frustrating. 
>> At least with Oracle I got to talk with an actual engineer...
>>
>> George
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Tuesday, October 13, 2015 2:03 PM
>> To: Tomcat Users List
>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
>> description = bad_record_mac
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> George,
>>
>> On 10/13/15 12:35 PM, George Stanchev wrote:
>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>> > (Will not send, but will accept SSLv2Hellos)"
>>
>> Interesting. This absolutely makes sense, though, since SSL should 
>> just die. :)
>>
>> > I've opened support case both MS and already there is a bug filed 
>> > with Oracle on this and really, to be absolutely certain if the 
>> > issue is in Java or SChannel, one would have to write a non-Java 
>> > client that that mimics the handshake messages send from Java with 
>> > something like OpenSSL or NSS or whatever and see if the bug replicates.
>>
>> It might be doable with OpenSSL s_client or something. Tough to 
>> replicate Java's behavior with a non-Java tool, though.
>>
>> > Writing a Java/Java server client could still leave some doubts as 
>> > one can argue the code reuse could mask the problem - it works but 
>> > the bug on the client side is hidden by the server containing 
>> > similar/same bug so the MACs check out...
>> >
>> > Unfortunately I don't have the time to invest in this more than I 
>> > already had. And if MS support engineers can pass it on to someone 
>> > from the windows core team may be we can have some movement forward.
>>
>> Okay. Thanks for your work so far.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
>> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
>> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
>> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
>> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
>> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
Aurlien,

Try the dropbox location in my prev messages. It contains a sample echo server 
you can use to test. It is a Visual Studio 2013 project. In case you don’t have 
that, I've uploaded x64 executables under SSLServer_executbale.zip. It is 
pretty much self contained, it has the redist DLLs, the server cert, all...

It eliminates the need of IIS as it does the same thing - accept connection, 
read payload, upgrade to 2 way ssl...

It generates output like this [1]

The line " Decrypt error from SCHANNEL, Client ID: 
a1cefeb8-bad3-4903-8dbe-fdea347f666e" is emitted when bad record mac is caught 
on the server side...

George



[1]


Read: 1093 bytes from 192.168.2.164:41525
Read: 165 bytes from 192.168.2.164:41525
Read: 90 bytes from 192.168.2.164:41525
Decrypt error from SCHANNEL, Client ID: a1cefeb8-bad3-4903-8dbe-fdea347f666e
Removing Dead Connection, Client ID: a1cefeb8-bad3-4903-8dbe-fdea347f666e
Active Connections: 0
New Connection from 192.168.2.164:41526 with Client ID: a94811d3-0872-4b63-a429-
97f980fdc42d
Read: 89 bytes from 192.168.2.164:41526
Sent: 145 bytes to 192.168.2.164:41526
Read: 6 bytes from 192.168.2.164:41526
Read: 53 bytes from 192.168.2.164:41526
Handshake Success, Client ID: a94811d3-0872-4b63-a429-97f980fdc42d
Read: 213 bytes from 192.168.2.164:41526
Message Client ID: SSL renegotiation: request client cert
Handshake Success, Client ID: a94811d3-0872-4b63-a429-97f980fdc42d
Sent: 37 bytes to 192.168.2.164:41526
Read: 133 bytes from 192.168.2.164:41526
Sent: 805 bytes to 192.168.2.164:41526
Read: 1093 bytes from 192.168.2.164:41526
Read: 165 bytes from 192.168.2.164:41526
Read: 90 bytes from 192.168.2.164:41526
Sent: 90 bytes to 192.168.2.164:41526
Handshake Success, Client ID: a94811d3-0872-4b63-a429-97f980fdc42d

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 2:55 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"How do you force Java 8 to use SSLv2Hello?"

You can do this when writing your own Java client : calling the 
SSLSocketFactory to create an SSLSocket and configure with setEnabledProtocols (
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
)

If you have some IIS server on internet which reproduces the problem, I'll try 
with JTouch ( jtouch.sourceforge.net ) or write a small client.




2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:

> George,
>
> do you have any network capture that we can see ?
>
> 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:
>
>> >> It might be doable with OpenSSL s_client or something. Tough to
>> replicate Java's behavior with a non-Java tool, though.
>>
>> I tried hard with the s_client but it can limit the protocols to one 
>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
>> like Java
>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
>> is also on top of openssl.
>>
>> Today, I spent 2.5 hours with a lemming from MS getting basically 
>> nowhere. I really need an engineer, but they give me those clueless 
>> support people that is wasting mine and their time. If someone knows 
>> how to escalate or a forum where MS developers hang out, I would appreciate 
>> it.
>> The support person I got today was clueless, went over a script and 
>> any attempt to explain a little more technical details led to total 
>> confusion and rebooting the script to beginning. Totally frustrating. 
>> At least with Oracle I got to talk with an actual engineer...
>>
>> George
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Tuesday, October 13, 2015 2:03 PM
>> To: Tomcat Users List
>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
>> description = bad_record_mac
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> George,
>>
>> On 10/13/15 12:35 PM, George Stanchev wrote:
>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>> > (Will not send, but will accept SSLv2Hellos)"
>>
>> Interesting. This absolutely makes sense, though, since SSL should 
>> just die. :)
>>
>> > I've opened support case both MS and already there is a bug filed 
>> > with Oracle on this and really, to be absolutely certain if the 
>> > issue is in Java or SChannel, one would have to write a non-Java 
>> > client that that mimics the handshake messages send from Java with 
>> > something like OpenSSL or NSS or whatever and see if th

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
Just as a side note, https.protocols is read by HttpsUrlConnection which feeds 
it down through setEnabledProtocols() on the SSL socket. " 
jdk.tls.client.protocols" is read directly by JSSE and does the same thing...

Another route to try the SSLv2Hello is to hack and recompile the JSSE. It's on 
my agenda to learn to do that if possible without rebuilding the whole JRE 
since for some obscure reason Oracle compiles JSSE with no debug info (and it 
is not included in the srcs distributed with the JRE) on it which makes 
debugging and inspecting local vars really hard...

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 3:13 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Maybe writing too fast..

"How do you force Java 8 to use SSLv2Hello?"

As suggested before, by writing your own client OR by trying this hack.
From the JSSE Ref Guide 5, we know how to the customize the protocol ( 
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) by setting a system property (https.protocol). Although they are no more 
talking about this in the Ref Guide 8 ( 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
) I would give it a try as I know that the documentation is poorly written.
I suggested 10 years ago a change in the API doc about the enabled protocols, 
and they didn't change anything although they said they would.



"[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  (Will not 
send, but will accept SSLv2Hellos)""

I believe they mean "by default" as for the client side. Poorly written, 
probably.



2015-10-13 22:55 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:

> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the 
> SSLSocketFactory to create an SSLSocket and configure with 
> setEnabledProtocols (
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html
> #setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, 
> I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:
>
>> George,
>>
>> do you have any network capture that we can see ?
>>
>> 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:
>>
>>> >> It might be doable with OpenSSL s_client or something. Tough to
>>> replicate Java's behavior with a non-Java tool, though.
>>>
>>> I tried hard with the s_client but it can limit the protocols to one 
>>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
>>> like Java
>>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
>>> is also on top of openssl.
>>>
>>> Today, I spent 2.5 hours with a lemming from MS getting basically 
>>> nowhere. I really need an engineer, but they give me those clueless 
>>> support people that is wasting mine and their time. If someone knows 
>>> how to escalate or a forum where MS developers hang out, I would appreciate 
>>> it.
>>> The support person I got today was clueless, went over a script and 
>>> any attempt to explain a little more technical details led to total 
>>> confusion and rebooting the script to beginning. Totally 
>>> frustrating. At least with Oracle I got to talk with an actual engineer...
>>>
>>> George
>>>
>>>
>>> -Original Message-
>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>>> Sent: Tuesday, October 13, 2015 2:03 PM
>>> To: Tomcat Users List
>>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
>>> description = bad_record_mac
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> George,
>>>
>>> On 10/13/15 12:35 PM, George Stanchev wrote:
>>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>>> > (Will not send, but will accept SSLv2Hellos)"
>>>
>>> Interesting. This absolutely makes sense, though, since SSL should 
>>> just die. :)
>>>
>>> > I've opened support case both MS and already there is a bug filed 
>>> > with Oracle on this and really, to be absolutely certain if the 
>>> > issue is in Java or SChan

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
From the source of truth: sun.security.ssl.ClientHandshaker.java of the latest 
JDK 8 update 60

this.enabledProtocols = [SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]
this. maxProtocolVersion = TLSv1.2


// Not a TLS1.2+ handshake
// For SSLv2Hello, HandshakeHash.reset() will be called, so we
// cannot call HandshakeHash.protocolDetermined() here. As it does
// not follow the spec that HandshakeHash.reset() can be only be
// called before protocolDetermined.
// if (maxProtocolVersion.v < ProtocolVersion.TLS12.v) {
// handshakeHash.protocolDetermined(maxProtocolVersion);
// }

// create the ClientHello message
ClientHello clientHelloMessage = new ClientHello(
sslContext.getSecureRandom(), maxProtocolVersion,
sessionId, cipherSuites);


I just stepped through the code, there is absolutely no way to override this 
without hacking JSSE...

/sigh

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 3:41 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to my 
understanding does the same as the system property "jdk.tls.client.protocols". 
It gives the JSSE a pool of protocols to choose from but it will be up to JSSE 
to select the ClientHello version. I might have missed something but I spent 
quite a bit of time in the Handshaker and related classes in the JDK and 
couldn't see anything that can change that..."

Sorry, but I believe that no. To understand, you need to look to the old Ref 
Guide ( 
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) which in "Annex A" says that you context.getInstance() takes one argument 
called "protocol" while sslsocket.setEnabledProtocols() takes a list of 
protocols including the SSLv2Hello.
If you are about to write a TLS client using a SSLv2Hello, you will call
getInstance("TLS") and setEnabledProtocols("SSLv2").

I hope things are more understandable :)




2015-10-13 23:12 GMT+02:00 George Stanchev <gstanc...@serena.com>:

> Ok, may be you are ahead of me on this one, but setEnabledProtocols(), 
> to my understanding does the same as the system property 
> "jdk.tls.client.protocols". It gives the JSSE a pool of protocols to 
> choose from but it will be up to JSSE to select the ClientHello 
> version. I might have missed something but I spent quite a bit of time 
> in the Handshaker and related classes in the JDK and couldn't see anything 
> that can change that...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 2:55 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the 
> SSLSocketFactory to create an SSLSocket and configure with 
> setEnabledProtocols (
>
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html
> #setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, 
> I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:
>
> > George,
> >
> > do you have any network capture that we can see ?
> >
> > 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:
> >
> >> >> It might be doable with OpenSSL s_client or something. Tough to
> >> replicate Java's behavior with a non-Java tool, though.
> >>
> >> I tried hard with the s_client but it can limit the protocols to 
> >> one or another but it canot mix-and-match (hello 1.2, ok we will do 
> >> 1.0) like Java
> >> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl 
> >> which is also on top of openssl.
> >>
> >> Today, I spent 2.5 hours with a lemming from MS getting basically 
> >> nowhere. I really need an engineer, but they give me those clueless 
> >> support people that is wasting mine and their time. If someone 
> >> knows how to escalate or a forum where MS developers hang out, I 
> >> would
> appreciate it.
> >> The support person I got today was clueless, went over a script and 
> >> any attempt to explain a little more technical details led to total 
> >> con

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-13 Thread George Stanchev
May be I am mistaken. I will give jtouch a try, thanks for the pointers...at 
this point I am grasping at straws :)

Thanks Aurelien!

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 3:52 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"Another route to try the SSLv2Hello is to hack and recompile the JSSE.
It's on my agenda to learn to do that if possible without rebuilding the whole 
JRE since for some obscure reason Oracle compiles JSSE with no debug info (and 
it is not included in the srcs distributed with the JRE) on it which makes 
debugging and inspecting local vars really hard..."

No, it's not needed. I use jtouch.sourceforge.net and it's working well for 
trying SSLv2 hello's. From the network captures, I see that it's working.
Not making advertisement for my software here, but,.. ;)







2015-10-13 23:20 GMT+02:00 George Stanchev <gstanc...@serena.com>:

> Just as a side note, https.protocols is read by HttpsUrlConnection 
> which feeds it down through setEnabledProtocols() on the SSL socket. "
> jdk.tls.client.protocols" is read directly by JSSE and does the same 
> thing...
>
> Another route to try the SSLv2Hello is to hack and recompile the JSSE.
> It's on my agenda to learn to do that if possible without rebuilding 
> the whole JRE since for some obscure reason Oracle compiles JSSE with 
> no debug info (and it is not included in the srcs distributed with the 
> JRE) on it which makes debugging and inspecting local vars really hard...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:13 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> Maybe writing too fast..
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> As suggested before, by writing your own client OR by trying this hack.
> From the JSSE Ref Guide 5, we know how to the customize the protocol ( 
> https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefG
> uide.html#InstallationAndCustomization
> ) by setting a system property (https.protocol). Although they are no 
> more talking about this in the Ref Guide 8 ( 
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunPro
> viders.html#SunJSSEProvider
> ) I would give it a try as I know that the documentation is poorly written.
> I suggested 10 years ago a change in the API doc about the enabled 
> protocols, and they didn't change anything although they said they would.
>
>
>
> "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  
> (Will not send, but will accept SSLv2Hellos)""
>
> I believe they mean "by default" as for the client side. Poorly 
> written, probably.
>
>
>
> 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:
>
> > "How do you force Java 8 to use SSLv2Hello?"
> >
> > You can do this when writing your own Java client : calling the 
> > SSLSocketFactory to create an SSLSocket and configure with 
> > setEnabledProtocols ( 
> > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.ht
> > ml
> > #setEnabledProtocols-java.lang.String:A-
> > )
> >
> > If you have some IIS server on internet which reproduces the 
> > problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write a small 
> > client.
> >
> >
> >
> >
> > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris <aterrest...@gmail.com>:
> >
> >> George,
> >>
> >> do you have any network capture that we can see ?
> >>
> >> 2015-10-13 22:10 GMT+02:00 George Stanchev <gstanc...@serena.com>:
> >>
> >>> >> It might be doable with OpenSSL s_client or something. Tough to
> >>> replicate Java's behavior with a non-Java tool, though.
> >>>
> >>> I tried hard with the s_client but it can limit the protocols to 
> >>> one or another but it canot mix-and-match (hello 1.2, ok we will 
> >>> do 1.0) like Java
> >>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl 
> >>> which is also on top of openssl.
> >>>
> >>> Today, I spent 2.5 hours with a lemming from MS getting basically 
> >>> nowhere. I really need an engineer, but they give me those 
> >>> clueless support people that is wasting mine and their time. If 
> >>> someone knows how to escalate or a forum where MS develop

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-09 Thread George Stanchev
Just for the record, https.protocols is a property used by the 
HttpsUrlConnection class. If your app is using a client that doesn't rely on 
the internal Oracle HTTP client, it's better to use " jdk.tls.client.protocols" 
which is read directly by the socket/SSL classes. Apache Http Client is one 
client that does use sockets directly instead of HttpsUrlConnection.


Also, I want to mention that we have finally been able to isolate a really 
nasty problem with Java SSL implementation and Windows's SSPI based SChannel 
acting as a server. The issue we ran into is very similar as to what the OP 
reported, that’s why I asked him a while ago on a separate thread about 
keystores if the server is IIS-based. The issue that we ran into might sound 
esoteric but our product ran into it very often. We have a configuration where 
we lock our intracomponent communication via 2way SSL. We have Java 
Tomcat-based server components that talk to IIS based native components via web 
services over HTTP which we secure with 2way SSL. When we upgraded to JRE 8 we 
started getting those connection resets in Tomcat when we enabled the 2way SSL. 
Those were on the Java->IIS calls that work over regular SSL. On the java side, 
if you turn on the ssl debug on, you'd see connection reset IOException thrown, 
and on the Windows side, you'd see " The following fatal alert was generated: 
20. The internal error state is 960." In the System event log. This error is " 
TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug database found a 
close resemblance to this issue: 
https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter couldn't 
reproduce it and also was against another Oracle component Java Web Download or 
something like this. So we started working with Oracle but the intermittent and 
hard-to-reproduce nature of this issue hampered the investigation. As the OP 
mentioned below, there are apocryphal reports for this all over the web but 
people cannot troubleshoot it very well. Anyway here are my findings. In order 
for the issue to arise all those conditions must be met:

[1] The client must start with ClientHello TLSv1.2
[2] The server must respond with ServerHello TLSv1 (so the server should not 
have TLS1.2 enabled)
[3] The cipher key exchange must NOT be ECDHE. I have not tried DHE as I could 
not make Windows take it. According to this doc [1] it should have several DHE 
key exchange ciphers available but I could not make it work. RSA key exchange 
exhibits the issue. I have been using “TLS_RSA_WITH_AES_256_CBC_SHA” to 
reproduce.
[4] The initial connection must not be 2way-SSL
[5] The server must upgrade the connection after encrypted payload is read. In 
case of IIS, it has 2way SSL setting on a Virtual Directory. The initial 
handshake is not 2way SSL, once the HTTP request is read, it determines that 
the requested resource (/gsoap) is 2way SSL-protected and upgrades the 
connection to 2way SSL.
[6] The server must kill the connection abruptly when error happens. This is 
important as if the server terminates the connection gracefully and keeps it 
around Java is able to recover since it reuses the cached connection. IIS does 
exactly this.
[7] The server must be Windows 7, Win2k8, Win2k8-R2, Win8. Might be other 
versions affected but bug is not evident on Win2k12 or Win2k12-R2 or Win10. 
Perhaps it was fixed, perhaps those versions support TLSv1.2

It might sound complicated but it is not, it is very common. All you have to do 
is to have a Virtual Directory in IIS that requires 2way SSL and is set to 
"want". RSA-based key exchanges are one of the most commonly used ciphers. The 
Windows platforms we tested with are still widely used in the enterprises while 
the adoption rate of win2k12+ is still lagging (from our experience with our 
customers). And you have equal "chance" of cipher support between Windows 
servers and Java 8 clients to land on RSA based cipher (which exhibits the 
issue) or ECDHE key exchange that is ok. Again, it might sound too complicated 
but it was blocker for us to ship our product.

For us, to work around this issue is for the 2way SSL to turn off TLSv1.2 (via 
"-Djdk.tls.client.protocols=TLSv1" or RSA key exchange algorithm (via the java 
security properties) on affected systems which fixes it.

I have a lot more technical details that I am not sharing here. I have sent 
them to Oracle so hopefully that gets resolved, but my guess is that is really 
an SSPI/SChannel issue in which case someone needs to work with Microsoft and I 
don't know if my company can do that. It boils down to - when all these 
conditions are met, is Java creating a bad MAC or SChannel fails to verify that 
MAC correctly on SSL handshake step X.

Hopefully this can help someone else, as we have spent quite a bit of time on 
this issue.

George


TL;DR: There is a nasty bug in Java or Windows when calling SSPI-based app over 
2way SSL that you can work around by turning off TLSv1.2 or RSA 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-10-09 Thread George Stanchev
One more clarification: on point [6] below I stated that Java is able to 
recover with a retry on a cached connection. Unfortunately that is only valid 
for higher level classes like HttpUrlConnection which makes 1 retry on 
IOException (and only on a GET and some other conditions). The lower-level 
sockets just throw and that’s it...

-Original Message-
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Friday, October 09, 2015 10:40 AM
To: Tomcat Users List
Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Just for the record, https.protocols is a property used by the 
HttpsUrlConnection class. If your app is using a client that doesn't rely on 
the internal Oracle HTTP client, it's better to use " jdk.tls.client.protocols" 
which is read directly by the socket/SSL classes. Apache Http Client is one 
client that does use sockets directly instead of HttpsUrlConnection.


Also, I want to mention that we have finally been able to isolate a really 
nasty problem with Java SSL implementation and Windows's SSPI based SChannel 
acting as a server. The issue we ran into is very similar as to what the OP 
reported, that’s why I asked him a while ago on a separate thread about 
keystores if the server is IIS-based. The issue that we ran into might sound 
esoteric but our product ran into it very often. We have a configuration where 
we lock our intracomponent communication via 2way SSL. We have Java 
Tomcat-based server components that talk to IIS based native components via web 
services over HTTP which we secure with 2way SSL. When we upgraded to JRE 8 we 
started getting those connection resets in Tomcat when we enabled the 2way SSL. 
Those were on the Java->IIS calls that work over regular SSL. On the java side, 
if you turn on the ssl debug on, you'd see connection reset IOException thrown, 
and on the Windows side, you'd see " The following fatal alert was generated: 
20. The internal error state is 960." In the System event log. This error is " 
TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug database found a 
close resemblance to this issue: 
https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter couldn't 
reproduce it and also was against another Oracle component Java Web Download or 
something like this. So we started working with Oracle but the intermittent and 
hard-to-reproduce nature of this issue hampered the investigation. As the OP 
mentioned below, there are apocryphal reports for this all over the web but 
people cannot troubleshoot it very well. Anyway here are my findings. In order 
for the issue to arise all those conditions must be met:

[1] The client must start with ClientHello TLSv1.2 [2] The server must respond 
with ServerHello TLSv1 (so the server should not have TLS1.2 enabled) [3] The 
cipher key exchange must NOT be ECDHE. I have not tried DHE as I could not make 
Windows take it. According to this doc [1] it should have several DHE key 
exchange ciphers available but I could not make it work. RSA key exchange 
exhibits the issue. I have been using “TLS_RSA_WITH_AES_256_CBC_SHA” to 
reproduce.
[4] The initial connection must not be 2way-SSL [5] The server must upgrade the 
connection after encrypted payload is read. In case of IIS, it has 2way SSL 
setting on a Virtual Directory. The initial handshake is not 2way SSL, once the 
HTTP request is read, it determines that the requested resource (/gsoap) is 
2way SSL-protected and upgrades the connection to 2way SSL.
[6] The server must kill the connection abruptly when error happens. This is 
important as if the server terminates the connection gracefully and keeps it 
around Java is able to recover since it reuses the cached connection. IIS does 
exactly this.
[7] The server must be Windows 7, Win2k8, Win2k8-R2, Win8. Might be other 
versions affected but bug is not evident on Win2k12 or Win2k12-R2 or Win10. 
Perhaps it was fixed, perhaps those versions support TLSv1.2

It might sound complicated but it is not, it is very common. All you have to do 
is to have a Virtual Directory in IIS that requires 2way SSL and is set to 
"want". RSA-based key exchanges are one of the most commonly used ciphers. The 
Windows platforms we tested with are still widely used in the enterprises while 
the adoption rate of win2k12+ is still lagging (from our experience with our 
customers). And you have equal "chance" of cipher support between Windows 
servers and Java 8 clients to land on RSA based cipher (which exhibits the 
issue) or ECDHE key exchange that is ok. Again, it might sound too complicated 
but it was blocker for us to ship our product.

For us, to work around this issue is for the 2way SSL to turn off TLSv1.2 (via 
"-Djdk.tls.client.protocols=TLSv1" or RSA key exchange algorithm (via the java 
security properties) on affected systems which fixes it.

I have a lot more technical det

RE: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

2015-10-06 Thread George Stanchev
Mark,

What are the possible issues with renegotiation? We're on NIO connectors, is 
there anything known?

George

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, October 05, 2015 8:32 AM
To: Tomcat Users List
Subject: Re: Demand CLIENT-CERT only on certain pages but demand SSL in all 
pages

On 05/10/2015 12:05, Gael Abadin wrote:
> Hello, fellow users.
> 
> I've been trying to configure tomcat to request client certificate 
> authentication on a single page, while serving every other SSL page 
> without requesting a client certificate (before or after 
> authentication). Depending on the configuration I use, one of 2 things 
> happen: either I get a request for a client certificate on ANY HTTPS 
> page I visit first, or I do not get a request at all, never, even when 
> I launch the browser and go straight to the protected page 
> (/my-app-name/public/login/login.xhtml).
> 
> Am I doing something wrong or is this kind of configuration just not 
> possible?

That should be possible but you'll need two security constraints. One to 
require TLS everywhere and one for the pages where you require authentication.

You may also hit issues with which connectors support renegotiation (don't use 
APR).

Mark

> 
> Here is my web.xml security constraint and login config (I've also 
> tried ommitin ):
> 
>   
> 
>   Protected Context
>   /public/login/*
> 
> 
>   CONFIDENTIAL
> 
>   
>   
> CLIENT-CERT
>   
> 
> 
> And here is my server.xml config (I've also tried clientAuth="false" 
> and
> clientAuth="true"):
> 
>   shutdown="SHUTDOWN">
>className="org.apache.catalina.startup.VersionLoggerListener"/>
> 
>   
>className="org.apache.catalina.core.AprLifecycleListener"/>
>   
>   
>   
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
> />
> 
>   
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> name="UserDatabase" pathname="conf/tomcat-users.xml"
> type="org.apache.catalina.UserDatabase"/>
>   
> 
>   
> 
>  redirectPort="443"/>
> 
>  port="443" protocol="org.apache.coyote.http11.Http11Protocol"
> scheme="https" secure="true" sslProtocol="TLS"/>
> 
> 
> 
> 
>   
>  resourceName="UserDatabase"/>
>   
>unpackWARs="true">
>  directory="logs" pattern="%h %l %u %t %r %s %b"
> prefix="localhost_access_log." suffix=".txt"/>
>  reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web"/>
>   
> 
>   
> 
> 
> It is my first Tomcat SSL client cert set up so I must be missing 
> something. Hope you may help me see it :-)
> 
> Cheers,
> 


-
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.55 Not loading truststore or keystore

2015-09-01 Thread George Stanchev
Hi Diarmuid,

We have run similar issue with client cert SSL. Is your 3rd party web service 
hosted on Windows/IIS? 

George

-Original Message-
From: dmccrthy [mailto:dmccr...@gmail.com] 
Sent: Tuesday, September 01, 2015 11:07 AM
To: Tomcat Users List
Subject: Tomcat 7.0.55 Not loading truststore or keystore

Hi All,

I am having trouble getting Tomcat to load a truststore and keystore.  This 
seems to be a basic configuration issue but I can't figure out what the problem 
is. Any insights would be gratefully received.

The scenario is:

* A 3rd party web application is deployed in Tomcat
* The 3rrd party web application is making outbound HTTPS connections to a 3rd 
party web service
* Tomcat JVM parameters are configured with

   -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks
   -Djavax.net.ssl.trustStorePassword=
   -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks
   -Djavax.net.ssl.keyStorePassword=
   -Dhttps.protocols="TLSv1"
   -Djavax.net.debug=ALL

* Both truststore and keystore are JKS
* Mutual authentication is used for the SSL handshake
* There are no errors in the Tomcat logs to indicate a problem with the 
truststore and keystore
* The Tomcat logs show the server-side certificate being downloaded but not 
reporting the expected lines

  Found trusted certificate:
  matching alias: 

  Or for the keystore, I am expecting to see a log that it is loading the 
keystore (example below), but there is no sign that the keystore is being 
loaded. I got the log extract below from a standalone java client which 
successfully connects using MA to the remote service.

  keyStore is : c:\temp\DWCHASSMESA002.pfx
  keyStore type is : PKCS12
  keyStore provider is :
  init keystore
  init keymanager of type SunX509

  ***
  found key for : dwchassmesa002
  chain [0] = [

* The Tomcat logs show that the SSL handshake gets as far as the 
ClientKeyExchange, but there is no client certificate sent and the handshake 
terminates with "Software caused connection abort: recv failed".
On DataPower the error is that the client is not sending the certificate.


http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:


[read] MD5 and SHA1 hashes:  len = 9
: 0D 00 00 05 02 01 02 00   00   .
*** ServerHelloDone
[read] MD5 and SHA1 hashes:  len = 4
: 0E 00 00 00
*** Certificate chain
***
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1 hashes:  
len = 269


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]: length 
= 274
: 16 03 01 01 0D 0B 00 00   03 00 00 00 10 00 01 02  


0110: 2E 32  .2
SESSION KEYGEN:
PreMaster Secret:


http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48 http-bio-8080-exec-2, 
waiting for close_notify or alert: state 1 http-bio-8080-exec-2, Exception 
while waiting for close
java.net.SocketException: Software caused connection abort: recv failed 
http-bio-8080-exec-2, handling exception: java.net.SocketException:
Software caused connection abort: recv failed %% Invalidated:  [Session-163, 
TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called close() 
http-bio-8080-exec-2, called closeInternal(true) http-bio-8080-exec-2, called 
closeSocket(

We are using the software below on the client environment:

* Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
* Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
* JCE Unlimited Security: No
* Apache Tomcat/7.0.55
* Microsoft Windows Server 2008 R2 Enterprise 64-bit

Analysis Steps
==

1) Openssl connects with MA parameters connects with no errors

openssl s_client -tls1 -connect server-dns-name:15305 -CAfile 
server-cert-with-intermediate-and-root-in-one-file.cer -cert 
client-public-key.cer -key client-private-key.key -pass 
pass:client-private-key-password

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1
Cipher: AES256-SHA
Session-ID:
893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F
Session-ID-ctx:
Master-Key:
89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B468AF81B19BC27FD9C7D3EBC46280B9A608E5517D447C
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1441125595
   Timeout   : 7200 (sec)
Verify return code: 0 (ok)

2) A standalone Java program with a couple of lines to open a HTTPS connection 
to the 3rd party certificate works.  This uses the same truststore and keystore
3) SoapUI works using the same truststore and keystore
4) Our 3rd party vendor can connect
5) I have googled various phrases like "Tomcat JVM not loading truststore".  
There are hundreds of examples 

RE: [OT] Re: Filter behaviour

2015-06-29 Thread George Stanchev
For SOAP, you *MUST* send back 500 or 400 with your SOAP fault back.

[1] http://www.w3.org/TR/soap12-part2/#tabresstatereccodes

-Original Message-
From: Leo Donahue [mailto:donahu...@gmail.com] 
Sent: Saturday, June 27, 2015 11:45 PM
To: Tomcat Users List
Subject: [OT] Re: Filter behaviour

On Sat, Jun 27, 2015 at 8:37 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 
  public void doFilter(ServletRequest request, ServletResponse
 response,
  FilterChain chain) throws IOException, ServletException
  {
  boolean iAmNotAuthorized = true;
 
  if (iAmNotAuthorized)
  {
  // generate the HTTP Servlet Response for a 403 status code
  HttpServletResponse httpResponse = (HttpServletResponse) 
  response;
  //httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
  httpResponse.setStatus(HttpServletResponse.SC_FORBIDDEN);
  httpResponse.setHeader(WWW-Authenticate, Basic);

 WWW-Authenticate header is usually used with 401 response.

 It is unusual to use it with 403 one, though the spec does not forbid 
 it. (I am not sure how browsers react here, though)

 http://tools.ietf.org/html/rfc7235#section-4.1


 Best regards,
 Konstantin Kolinko


http://tools.ietf.org/html/rfc7231#section-6.5.3

And we may send a 404 to hide the existence of a forbidden target.  It's 
misleading.  That seems to open the door for any kind of response, or no 
response.

I am on the fence about sending 401 or 403 responses from a web service.
They both indicate something is there, you just can't get to it.

The 401 alludes that something is wrong with your username/password.

The 403 is more vague.  You may have the right username and password (and I'm 
not going to bother to tell you), but your account may not have the correct 
role associated with using this service, so rather than say anymore, I'll just 
let you know you are forbidden.  Users have no idea, other than there is 
something good at the end of this request for me to be forbidden.

From the perspective of troubleshooting customer requests to your published web 
service, developers can log the unsuccessful attempt (Authentication or
Authorization) and review the log files for answers to trouble shooting, but 
sending back a status code doesn't seem to always make sense depending on what 
types of application clients your customers are using.

For example:

Suppose you call a SOAP web service that takes an object as a parameter and 
that service returns another type of object.  When customers expect an object, 
they may get a HTTP status code of 401 or 403 if they botched sending the 
correct username/password in the authentication header.  And maybe, their 
password is merely expired.  In situations like those, it seems more reasonable 
to send back a Soap Fault of some kind as defined in the schema.  The message 
could be as simple as: Authorization failed.

It seems easier for clients to know that a soap web service may throw a 
ClientAuthorizationException for example, rather than parse out a HTTP status 
code response?

I don't know though.

Leo


RE: [OT] Re: Filter behaviour

2015-06-29 Thread George Stanchev
Yeah, you're right. I don't see *MUST* in my reference either. They *must* /pun 
intended/ have dropped the language for SOAP 1.2. A little vague, with this 
table, though the table implicitly states that it *MUST* be 400 or 500 since 
there is no other code that and it is a complete table.

I said *MUST* because SOAP 1.1 explicitly states it [1]:


In case of a SOAP error while processing the request, the SOAP HTTP server 
MUST issue an HTTP 500 Internal Server Error response and include a SOAP 
message in the response containing a SOAP Fault element (see section 4.4) 
indicating the SOAP processing error.


George

[1] http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383529

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Monday, June 29, 2015 8:56 AM
To: Tomcat Users List
Subject: Re: [OT] Re: Filter behaviour

George Stanchev wrote:
 For SOAP, you *MUST* send back 500 or 400 with your SOAP fault back.
 
 [1] http://www.w3.org/TR/soap12-part2/#tabresstatereccodes

Not to start a fight on SOAP on this Tomcat forum, but in the wording of the 
section referenced above, I definitely do not see that you *MUST* send a 5xx or 
4xx Status Code back.
One should start reading a bit earlier, at 7.5.2.2 Receiving.
The gist seems to be : send a 2xx code back, along with a SOAP envelope 
containing the SOAP fault, or if you cannot, then use one of the HTTP error 
codes below.
But sending /only/ a HTTP error code is, in my view, confusing for the client, 
because it would not be able to distinguish between a HTTP transport error, and 
a service-level error.

 
 -Original Message-
 From: Leo Donahue [mailto:donahu...@gmail.com] 
 Sent: Saturday, June 27, 2015 11:45 PM
 To: Tomcat Users List
 Subject: [OT] Re: Filter behaviour
 
 On Sat, Jun 27, 2015 at 8:37 AM, Konstantin Kolinko knst.koli...@gmail.com
 wrote:
 
 public void doFilter(ServletRequest request, ServletResponse
 response,
 FilterChain chain) throws IOException, ServletException
 {
 boolean iAmNotAuthorized = true;

 if (iAmNotAuthorized)
 {
 // generate the HTTP Servlet Response for a 403 status code
 HttpServletResponse httpResponse = (HttpServletResponse) 
 response;
 //httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
 httpResponse.setStatus(HttpServletResponse.SC_FORBIDDEN);
 httpResponse.setHeader(WWW-Authenticate, Basic);
 WWW-Authenticate header is usually used with 401 response.

 It is unusual to use it with 403 one, though the spec does not forbid 
 it. (I am not sure how browsers react here, though)

 http://tools.ietf.org/html/rfc7235#section-4.1


 Best regards,
 Konstantin Kolinko


 http://tools.ietf.org/html/rfc7231#section-6.5.3
 
 And we may send a 404 to hide the existence of a forbidden target.  It's 
 misleading.  That seems to open the door for any kind of response, or no 
 response.
 
 I am on the fence about sending 401 or 403 responses from a web service.
 They both indicate something is there, you just can't get to it.
 
 The 401 alludes that something is wrong with your username/password.
 
 The 403 is more vague.  You may have the right username and password (and 
 I'm not going to bother to tell you), but your account may not have the 
 correct role associated with using this service, so rather than say anymore, 
 I'll just let you know you are forbidden.  Users have no idea, other than 
 there is something good at the end of this request for me to be forbidden.
 
 From the perspective of troubleshooting customer requests to your published 
 web service, developers can log the unsuccessful attempt (Authentication or
 Authorization) and review the log files for answers to trouble shooting, but 
 sending back a status code doesn't seem to always make sense depending on 
 what types of application clients your customers are using.
 
 For example:
 
 Suppose you call a SOAP web service that takes an object as a parameter and 
 that service returns another type of object.  When customers expect an 
 object, they may get a HTTP status code of 401 or 403 if they botched sending 
 the correct username/password in the authentication header.  And maybe, their 
 password is merely expired.  In situations like those, it seems more 
 reasonable to send back a Soap Fault of some kind as defined in the schema.  
 The message could be as simple as: Authorization failed.
 
 It seems easier for clients to know that a soap web service may throw a 
 ClientAuthorizationException for example, rather than parse out a HTTP status 
 code response?
 
 I don't know though.
 
 Leo
 
 -
 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

RE: Forcing SSL Renotiation

2015-06-26 Thread George Stanchev
Hi Chris,

Agree on point 2  3. Since we are in control of the application server, we 
have the luxury of managing the SSL engine and the Security Manager settings. I 
guess I should've provided a link to the ssl-howto doc [1] that describes that 
solution. I went the reflection way to avoid having to link with Tomcat in our 
build scripts. There is discussion [2] on this issue referenced by [1].

Regarding 1 - I also found it odd but I guess that’s not mandated by the 
standard so they have to return something. It is better to return abstraction 
than concrete JSSE object in case the underlying implementation changes. BTW 
why is this not working with OpenSSL/native? Is there a technical reason or 
just not implemented?

George

[1] https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=22679

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, June 26, 2015 10:06 AM
To: Tomcat Users List
Subject: Re: Forcing SSL Renotiation

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 6/26/15 10:04 AM, George Stanchev wrote:
 You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we use 
 the following code. Not sure if it will work on 6. For a long time 
 until very recently we were stuck on 5.5 and the attribute below is 
 not available. So I had to write a reflection introspection to drill 
 down to the SSLSessionManager held by the Tomcat objects under the 
 server request.
 
 Keep in mind the client cert implementation on the browsers is not 
 uniform in behavior (in respect of resetting a session and letting the 
 user chose another cert on relogin). We support FF, Chrome and IE and 
 by far so far IE has been the most consistent. Later releases of 
 Chrome cache the smartcard connection and resubmit the same cert on 
 reconnect and nothing you can do on the server can change this (as far 
 as I know). The JS-side crypto support (to reset the state) is poor, 
 FF-specific and unreliable. Firefox has it's own set of issues.

A couple of things:

1. I find it odd that Tomcat is using the javax.servlet namespace for an 
implementation-specific class. I would argue this doesn't belong under the key 
that's currently being used.

2. The SSLSessionManager seems to be unique to JSSE-based implementations of 
TLS in Tomcat, which means that this technique isn't going to work if you are 
using tcnative and OpenSSL-based crypto.

3. This code isn't going to work under a SecurityManager unless you make 
arrangements to configure the privileges for your code properly.

- -chris

 // Invalidate the SSL Session
 (org.apache.tomcat.util.net.SSLSessionManager) Method 
 invalidateSessionMethod = null; Object mgr = 
 httpRequest.getAttribute(javax.servlet.request.ssl_session_mgr);
 if (mgr != null) { try { invalidateSessionMethod = 
 mgr.getClass().getMethod(invalidateSession); if 
 (invalidateSessionMethod == null) { log.error(Failed to reset SSL
 session: Method invalidateSessionMethod =
 mgr.getClass().getMethod(\invalidateSession\) failed to return 
 method); } invalidateSessionMethod.setAccessible(true); } catch 
 (Throwable t) { log.error(Failed to reset SSL session:  + 
 t.getMessage(), t); }
 
 // Invalidate the session try {
 invalidateSessionMethod.invoke(mgr); log.trace(SSL session reset 
 successfully); return true; } catch (Throwable t) { log.error(Failed 
 to reset SSL session: invalidateSession() threw
 exception:  + t.getMessage(), t); }
 
 -Original Message- From: Steffen Heil (Mailinglisten) 
 [mailto:li...@steffen-heil.de] Sent: Friday, June 26, 2015 2:43 AM
 To: Tomcat Users List Subject: Forcing SSL Renotiation
 
 Hi
 
 
 My tomcat installation offers pages through https only. So when 
 accessing these pages, an ssl connection is established. Later on, a 
 user may decide to log in, hence hitting a page, that requires 
 client certificates, and the browser pops up a selection dialog for a 
 certificate. Once chosen, the server recognized the user by its 
 certificate, and everything is fine. So far, so good.
 
 Now I have 2 problems:
 
 1. When clicking logout in the application, the server terminates 
 its internal session for that user, but the ssl connection is not 
 terminated. That means, as soon as anyone clicks login again, the old 
 certificate is reused. So the user cannot login using another 
 certificate.
 
 2. The second problem with that is, that if the certificate was on a 
 smartcard and that card was removed, that cannot be detected.
 
 Is there any way to tell tomcat to tell the browser to drop the tls 
 session state and restart?
 
 
 Regards, Steffen
 
 
 -

 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVjXhSAAoJEBzwKT

RE: Forcing SSL Renotiation

2015-06-26 Thread George Stanchev
Hi Steffen

You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we use the 
following code. Not sure if it will work on 6. For a long time until very 
recently we were stuck on 5.5 and the attribute below is not available. So I 
had to write a reflection introspection to drill down to the SSLSessionManager 
held by the Tomcat objects under the server request.

Keep in mind the client cert implementation on the browsers is not uniform in 
behavior (in respect of resetting a session and letting the user chose another 
cert on relogin). We support FF, Chrome and IE and by far so far IE has been 
the most consistent. Later releases of Chrome cache the smartcard connection 
and resubmit the same cert on reconnect and nothing you can do on the server 
can change this (as far as I know). The JS-side crypto support (to reset the 
state) is poor, FF-specific and unreliable. Firefox has it's own set of issues.

George



[1]

// Invalidate the SSL Session 
(org.apache.tomcat.util.net.SSLSessionManager)
Method invalidateSessionMethod = null;
Object mgr = 
httpRequest.getAttribute(javax.servlet.request.ssl_session_mgr);
if (mgr != null) {
try {
invalidateSessionMethod = 
mgr.getClass().getMethod(invalidateSession);
if (invalidateSessionMethod == null) {
log.error(Failed to reset SSL 
session: Method invalidateSessionMethod = 
mgr.getClass().getMethod(\invalidateSession\) failed to return method);
}

invalidateSessionMethod.setAccessible(true);
} catch (Throwable t) {
log.error(Failed to reset SSL session: 
 + t.getMessage(), t);
}

// Invalidate the session
try {
invalidateSessionMethod.invoke(mgr);
log.trace(SSL session reset 
successfully);
return true;
} catch (Throwable t) {
log.error(Failed to reset SSL session: 
invalidateSession() threw exception:  + t.getMessage(), t);
}

-Original Message-
From: Steffen Heil (Mailinglisten) [mailto:li...@steffen-heil.de] 
Sent: Friday, June 26, 2015 2:43 AM
To: Tomcat Users List
Subject: Forcing SSL Renotiation

Hi


My tomcat installation offers pages through https only. So when accessing these 
pages, an ssl connection is established.
Later on, a user may decide to log in, hence hitting a page, that requires 
client certificates, and the browser pops up a selection dialog for a 
certificate.
Once chosen, the server recognized the user by its certificate, and everything 
is fine.
So far, so good.

Now I have 2 problems:

1. When clicking logout in the application, the server terminates its 
internal session for that user, but the ssl connection is not terminated.
That means, as soon as anyone clicks login again, the old certificate is reused.
So the user cannot login using another certificate.

2. The second problem with that is, that if the certificate was on a smartcard 
and that card was removed, that cannot be detected.

Is there any way to tell tomcat to tell the browser to drop the tls session 
state and restart?


Regards,
  Steffen



RE: useServerCipherSuitesOrder in 7.0.62

2015-06-24 Thread George Stanchev
Hi Christopher,

(Apologies for top posting, I cannot find a way to switch to  quote for 
Outook)

Having an utility is interesting idea but it will not address the regular 
expression rules that OpenSSL support. For example, I was porting Mozilla's 
Server Side TLS ciphers [1] to our 7.0.62 the other day and at the end you have:

...:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

So after mapping all the explicit ones before, I had to go and look for rest of 
AES suites, then exclude the export suites, ignore the RC4s, etc, etc.I did it, 
kinda but it was pain in the neck and it is really not the same rule list. 

Can you point me to the code where 8 and the trunk deal with this? It is not 
really that big of a deal to not have it since once you set your list you don't 
touch it until the next security scare, but since it is security related, I 
thought it would benefit people to be able to have more flexibility on the 
cipher definitions and might be worth backporting.

Regards,
George

[1] 
https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, June 24, 2015 8:37 AM
To: Tomcat Users List
Subject: Re: useServerCipherSuitesOrder in 7.0.62

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 6/15/15 10:08 AM, George Stanchev wrote:
 Is there any chance for the OpenSSL-style ciphers to be backported to 
 the 7 release line?

I'm not sure. The biggest problem with the OpenSSL-style ciphers is maintaining 
the mapping, which might change with every release of Java and/or OpenSSL. 
Maintaining it in Tomcat's trunk and 8 is already double the work... adding 
Tomcat 7 is even more work.

I think what might make sense is to wrap a command-line program around the 
trunk/8.0.x utility that does the mapping to build something like OpenSSL's 
ciphers command, but that dumps-out JSSE-style cipher suites .

Then that could be used independently of any version of Tomcat for those 
versions that don't directly-support the openssl-style cipher suites 
configuration.

What do you think?

Another possibility would be to maintain the mapping somewhere other than code 
(where it currently is), and then share that mapping between the various 
versions, perhaps using svn external links. Then the maping gets updated in a 
single place and all supporting versions of Tomcat can pick it up.

I'll defer to markt who mostly wrote the OpenSSL-JSSE bridge code to decide if 
that might work.

- -chris

 -Original Message- From: George Stanchev 
 [mailto:gstanc...@serena.com] Sent: Saturday, June 13, 2015 11:41 AM 
 To: Tomcat Users List Subject: RE: useServerCipherSuitesOrder in 
 7.0.62
 
 Thanks Konstantin,
 
 I apologize for the shortsightness. I guess I must have had a space in 
 the search dialog. Thanks for the answers!
 
 Cheers,
 
 George
 
 -Original Message- From: Konstantin Kolinko 
 [mailto:knst.koli...@gmail.com] Sent: Saturday, June 13, 2015 7:26 AM 
 To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 
 7.0.62
 
 2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com:
 Hi,
 
 I was looking at [1] and it looks the new attribute is available in 
 7.0.61 onwards as per Violeta's comment. However I cannot find this 
 new attribute in the HTTP connector documentation [2] nor the 
 changelog [3]. Can someone confirm or deny the availability of this 
 attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62.
 
 
 #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60).
 
 useServerCipherSuitesOrder is mentioned in [2] (in SSL Support
 - BIO and NIO section).
 
 Note that this feature requires running with Java 8.
 
 
 As a follow up question, I seem to remember that 8.0.latest supports 
 OpenSSL-style list for the HTTP connector ciphers
 attribute. Does 7.0.62 also support this or it wasn't backported?
 
 
 It was not backported.
 
 Relevant classes are in package
 org.apache.tomcat.util.net.jsse.openssl:
 
 OpenSSLCipherConfigurationParser etc.
 
 
 [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] 
 https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] 
 https://tomcat.apache.org/tomcat-7.0-doc/changelog.html
 
 Best regards, Konstantin Kolinko
 
 -


 
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
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVisCdAAoJEBzwKT+lPKRYDlAP/iKygYxuv7ie4h2HG16FUu3H
3EJ/f3mAVfsG/Z+Kwd3nGuC44vFTyLENWoRp0fBM6

RE: useServerCipherSuitesOrder in 7.0.62

2015-06-15 Thread George Stanchev
Is there any chance for the OpenSSL-style ciphers to be backported to the 7 
release line?

-Original Message-
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Saturday, June 13, 2015 11:41 AM
To: Tomcat Users List
Subject: RE: useServerCipherSuitesOrder in 7.0.62

Thanks Konstantin,

I apologize for the shortsightness. I guess I must have had a space in the 
search dialog. Thanks for the answers!

Cheers,

George

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Saturday, June 13, 2015 7:26 AM
To: Tomcat Users List
Subject: Re: useServerCipherSuitesOrder in 7.0.62

2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com:
 Hi,

 I was looking at [1] and it looks the new attribute is available in 7.0.61 
 onwards as per Violeta's comment. However I cannot find this new attribute in 
 the HTTP connector documentation [2] nor the changelog [3]. Can someone 
 confirm or deny the availability of this attribute 
 (useServerCipherSuitesOrder) in Tomcat 7.0.62.


#55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60).

useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and 
NIO section).

Note that this feature requires running with Java 8.


 As a follow up question, I seem to remember that 8.0.latest supports 
 OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 
 also support this or it wasn't backported?


It was not backported.

Relevant classes are in
package org.apache.tomcat.util.net.jsse.openssl:

OpenSSLCipherConfigurationParser etc.


 [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988
 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
 [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Best regards,
Konstantin Kolinko

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



RE: useServerCipherSuitesOrder in 7.0.62

2015-06-13 Thread George Stanchev
Thanks Konstantin,

I apologize for the shortsightness. I guess I must have had a space in the 
search dialog. Thanks for the answers!

Cheers,

George

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Saturday, June 13, 2015 7:26 AM
To: Tomcat Users List
Subject: Re: useServerCipherSuitesOrder in 7.0.62

2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com:
 Hi,

 I was looking at [1] and it looks the new attribute is available in 7.0.61 
 onwards as per Violeta's comment. However I cannot find this new attribute in 
 the HTTP connector documentation [2] nor the changelog [3]. Can someone 
 confirm or deny the availability of this attribute 
 (useServerCipherSuitesOrder) in Tomcat 7.0.62.


#55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60).

useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and 
NIO section).

Note that this feature requires running with Java 8.


 As a follow up question, I seem to remember that 8.0.latest supports 
 OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 
 also support this or it wasn't backported?


It was not backported.

Relevant classes are in
package org.apache.tomcat.util.net.jsse.openssl:

OpenSSLCipherConfigurationParser etc.


 [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988
 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
 [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Best regards,
Konstantin Kolinko

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



useServerCipherSuitesOrder in 7.0.62

2015-06-13 Thread George Stanchev
Hi,

I was looking at [1] and it looks the new attribute is available in 7.0.61 
onwards as per Violeta's comment. However I cannot find this new attribute in 
the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm 
or deny the availability of this attribute (useServerCipherSuitesOrder) in 
Tomcat 7.0.62.

As a follow up question, I seem to remember that 8.0.latest supports 
OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also 
support this or it wasn't backported?

Thanks!

George


[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988
[2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
[3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html





RE: Problem specifying cipher suites in tomcat6

2015-05-29 Thread George Stanchev
Chris, thanks for sharing this. I've recently ran across a similar tool:

http://www.bolet.org/TestSSLServer/

That does the same thing as your code but may be a little bit more elaborate. 
It also has a source code on link. Since you has shared your code, I might as 
well share this - the more the better.

George

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, May 29, 2015 3:32 PM
To: Tomcat Users List
Subject: Re: Problem specifying cipher suites in tomcat6

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ramon,

On 5/29/15 4:42 PM, Ramon Pfeiffer wrote:
 On 29.05.2015 21:12, Christopher Schultz wrote:
 Ramon,
 
 On 5/29/15 3:32 AM, Ramon Pfeiffer wrote:
 Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
 From: Ramon Pfeiffer
 [mailto:ramon.pfeif...@uni-tuebingen.de] Subject: Problem 
 specifying cipher suites in tomcat6
 
 I'm currently trying to specify a list of cipher suites to be used 
 by my connector in Tomcat 6.0.24.
 
 Anybody can shed some light on what I did wrong?
 
 Using a version of Tomcat that's more than five years old is the 
 first thing - there have been many, many security fixes since then, 
 including some related to the ciphers attribute.
 You also need to tell us the JVM version, the platform you're 
 running on, and whether or not APR is in use for this Connector 
 (it's in the logs).
 
 Sadly, it's a system I inherited last year and now have the pleasure 
 to work with. I can't update Tomcat for I don't know what will 
 break.
 
 If you can't upgrade it, you are better-off shutting-down the 
 service, because there are security vulnerabilities in there.
 
 So, ask your boss which is worse: shuttering the project, or getting 
 a new version of Tomcat into a testing environment?
 
 Shutting it down is not an option. So I guess next week will be... 
 interesting.
 
 The important thing is this: Will the connector work in this 
 configuration after I updated Tomcat? Or is the issue completely 
 unrelated? Where are the ciphers shown by ssllabs taken from? Is the 
 cipher attribute ignored?

Lots of things have been fixed/added in more recent versions of Tomcat 6.0.x. 
Please give a quick test against Tomcat 6.0.latest: you don't even need to 
deploy your own web application on it; just configure it for SSL and hit the 
default web application (the Tomcat documentation), or the examples, or 
whatever.

SSLLabs picks the ciphers it wants to check for; usually a group of good 
ciphers to make sure that you can support the latest-and-greatest ciphers, plus 
a bunch of them that are known to be broken (like most SSL-only ones).

This tool may help you test, because it's a whole lot faster than SSLLabs' 
tests:
http://markmail.org/message/tz4z44nfjl7sy2lj

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaNqzAAoJEBzwKT+lPKRYyyIP/AxaJNDI8C98lGUGP4bqOFsm
ZSxcfQG44mAFwBAMkW2oxfCCD7MDb8y9jQT5qyEv+eEgLd9kFjG1UOXogDKAm6dI
d8lh10FSI/Wk4o7OMuWl7nCE8APzUAMCojJz3RxvMvJwFpyP6Te7Zl8baNHXUl2U
zir68R9fTjT/UT9Wps6+gg5UWS/v08gzeBarizdk3QHtQrgXJamF9aLgJ+L7g3rX
cJbxVKUBinznnDFZ3Z3r5RAM1dXRrVvUkKHzewBHtZSOzlXFEnj+vmw2XCu1rrph
wdJURfX19KuONjGfkzLw5c3geL9nOwBfBP0D62DsivP2kdcpNCt7N/szFvB6ICUQ
FcCGI57KGCGYGG3EF9SmbFrb0YORO5iR149SEXeoLzWz5O7rlqK5NClPOiyITIv2
n4yrbq7PlXZny3d9IRx801fhpetRKmmtRLHau+SmR4nf79VN/le7uee/Sehx+2bO
WGyQZG+UO8brLozVvtNYutFVOphfO1YKOACKZfBmzCD1zGmEG8O1/9ApeMzlsnjE
Bpg9fXS3YgPEKDSXFtS6wafz+CH+JuSHAhpkUVQ1I7XMHa/SGIVHAeRi4FCUZo6i
8iRnMVbD+4R8F6NupRvFQ7qeOnfI4E7wDfGYjW7sUd2XF/yVFsRALBiHaExCVp0g
dG8GnIcirHHy+w3GwbUj
=YI9Z
-END PGP SIGNATURE-

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



RE: Problem specifying cipher suites in tomcat6

2015-05-29 Thread George Stanchev
I don't see where he blamed the developers for anything. The poster even 
admitted it was their fault. I think it is reasonable to warn the OP that any 
change can result in issue. Even if you're doing everything correctly, there is 
a change of running in a new Tomcat issue or a regression or what not.

We as developers know that corner cases that have 1% of happening occur 50% of 
the time ;-)

Any application server upgrade should be tested before deployed...

My 2c

George

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Friday, May 29, 2015 12:12 PM
To: Tomcat Users List
Subject: Re: Problem specifying cipher suites in tomcat6

Sean Dawson wrote:
 I had significant problems trying to uncover a change in tomcat7 that 
 broke our app when upgrading from 42 to 57, for a couple weeks over 
 Christmas holidays.
 
 Turns out it was something we shouldn't have been doing -

you mean, apart from top-posting here ?

but it was
 definitely a change in tomcat (51 or so) that resulted in the issue(s).
 
 Just something to keep in mind.
 

Well yes, but in all truth, if you were doing something which you should not 
have been doing - and bonus points for admitting it - then you cannot really 
blame the tomcat developers for making a change which broke it, even over 
Christmas, can you ?

At the contrary, you should be grateful : the fact that the change pointed out 
the bad thing in your code, may have prevented the later advent of a nuclear 
war.  That would have been even less fun over Christmas.

As a concession, maybe George's post below could have been prefixed with If 
your code is well-behaved, ..


 
 On Fri, May 29, 2015 at 11:43 AM, George Sexton geor...@mhsoftware.com
 wrote:
 

 On 5/29/2015 5:16 AM, David kerber wrote:

 On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:

 Sadly, it's a system I inherited last year and now have the pleasure to
 work with. I can't update Tomcat for I don't know what will break.

 There's a fair chance that you can update to the latest version of TC 6
 without anything breaking, but of course that's not guaranteed.

 I can think of very few instances where a change in Tomcat broke my app.
 The only one I can really remember was a change that I initiated :)


 --
 George Sexton
 *MH Software, Inc.*
 Voice: 303 438 9585
 http://www.mhsoftware.com

 


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



Tomcat Connectors release

2015-05-14 Thread George Stanchev
Hello,

What is the schedule for Connectors release? Is a release scheduled when a 
critical mass of issues fixed or a major problem is resolved or a regular 
time-based release?

George


Issue with a principal and remote_user

2015-04-17 Thread George Stanchev
I posted this on the dev list but I must have placed it on the wrong list...

I am running IIS+jk_connect+Tomcat 7.0.59 but this issue was replicated on 
Tomcat 5.5.36. We are using a security filter from a 3rd party that is failing 
to engage while requests are sent over AJP via jk_connect. I was able to trace 
the issue to the 3rd party checking for previously authenticated principal via 
HttpServletRequest.getUserPrincipal(). Regular call via HTTP connector returns 
null. Call over jk_connect returns CoyotePrinciapal object but the getName() on 
it is . The whole issue starts in the jk_isapi_plugin.c where 

GET_SERVER_VARIABLE_VALUE(REMOTE_USER, s-remote_user);

This macro is defined as

#define GET_SERVER_VARIABLE_VALUE(name, place)  \
  do {  \
    (place) = dup_server_value(private_data-lpEcb, \
   (name),  \
   private_data-p);   \
  } while(0)

dup_server_value is

static char *dup_server_value(LPEXTENSION_CONTROL_BLOCK lpEcb,
  const char *name, jk_pool_t *p)
{    DWORD sz = HDR_BUFFER_SIZE;
    char buf[HDR_BUFFER_SIZE];
    char *dp;

    if (lpEcb-GetServerVariable(lpEcb-ConnID, (LPSTR)name, buf, sz))
    return jk_pool_strdup(p, buf);

and jk_pool_strdup starts as

char *jk_pool_strdup(jk_pool_t *p, const char *s)
{
    char *rc = NULL;
   if (s  p) {
    size_t size = strlen(s);

    if (!size) {
    return ;
    }

So essentially GetServerVariable(REMOTE_USER, buf, sz) returns TRUE and sets 
buf[0]=0 and sz to 0 indicating no REMOTE_USER is present. However, this is 
converted to  by jk_pool_strdup and sent over AJP to Tomcat as a remote_user 
with size of 0 bytes.


Since a remote_user field IS sent to Tomcat, it creates a CoyotePrincipal 
object with a principal name of empty string.

There is a problem somewhere: two requests over two connectors generate two 
different principal objects (null and empty CoyotePrincipal). If I'd to put a 
finger, I would say the issue is with the IIS connector converting empty 
REMOTE_USER value to  instead of NULL and thus sending empty remote_user  
to Tomcat. But a case can be made for Tomcat's AJP processor to check if the 
incoming remote_user value is  and not create a phoney CoyotePrincipal either

I'd like to raise an issue but I want to submit it into the correct component.

George



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