date:20210524

RE: Tomcat SSL stops working after an undetermined amount of time

2021-05-24 Thread Mysore, Raghunath

Hi Ezsra, 
   This is an answer to your query -  " Why is Tomcat not using 
the TLSv1.2 protocol?" 
I assume you are using Oracle JDK v8u281 
You may want to review the following line in the file :  /jre/lib/security/ 
java.security
jdk.tls.disabledAlgorithms=??
The following old SSL versions are listed here. 
Examples :  SSLv3, TLSv1, TLSv1.1 etc 
This, in my opinion, will ensure Tomcat will honor TLS1.2 protocol (by 
eliminating others ) 
Also are you observing that Safari browser is giving good response, while 
Chrome is causing the SSL issue ? 

Hope this helps,
-Raghu 

-Original Message-
From: Ed Rouse  
Sent: Monday, May 24, 2021 2:26 PM
To: Tomcat Users List 
Subject: RE: Tomcat SSL stops working after an undetermined amount of time

This works for me. In server.xml:

From: Ezsra McDonald 
Sent: Monday, May 24, 2021 4:10 PM
To: Tomcat Users List 
Subject: Re: Tomcat SSL stops working after an undetermined amount of time

[External email: Use caution! Do not open attachments or click on links from 
unknown senders or unexpected emails.] Chris,

Thanks for your response.

These Tomcat servers are something I inherited. I do not know what this 
bouncycastle.crypto is. If it is making my setup complicated how do I get 
around it? Is it part of the org.apache.coyote.http11.Http11NioProtocol?
What would you recommend I use instead? My end goal is to just enable TLS/SSL 
on the connectors.

--Ez

On Mon, May 24, 2021 at 1:56 PM Christopher Schultz < 
ch...@christopherschultz.net> wrote:

> Ezsra,
>
> On 5/24/21 10:30, Ezsra McDonald wrote:
> > I am enabling SSL debugging this morning. I did catch this in the 
> > log for an instance that started erroring out this morning. Seems 
> > like it may be too generic to help solve my problem. Here it is:
> >
> > 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51] 
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> > java.lang.NullPointerException
> > at 
> > org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
> > Source)
> > at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown 
> > Source)
>
> Oh. You are using BouncyCastle. I've never tried to do that. I'm not 
> sure how well BC will work with Tomcat. We don't officially support 
> that configuration, but that doesn't mean we won't try to help.
>
> There will be a presentation at this year's ApacheCon @Home 2021 about 
> configuring Tomcat for FIPS and it will include how to configure 
> Tomcat with BC (including FIPS). Obviously, you don't want to wait 
> around until the conference to get things working, but perhaps the 
> presenter is lurking on the list ... ?
>
> I don't have an email address for the presenter, so I can't give you a 
> reference. :/
>
> -chris
>
> -
> To unsubscribe, e-mail: 
> users-unsubscr...@tomcat.apache.org ache.org> For additional commands, e-mail: 
> users-h...@tomcat.apache.org
>
>

RE: Tomcat SSL stops working after an undetermined amount of time

2021-05-24 Thread Ed Rouse

This works for me. In server.xml:









From: Ezsra McDonald 
Sent: Monday, May 24, 2021 4:10 PM
To: Tomcat Users List 
Subject: Re: Tomcat SSL stops working after an undetermined amount of time

[External email: Use caution! Do not open attachments or click on links from 
unknown senders or unexpected emails.]
Chris,

Thanks for your response.

These Tomcat servers are something I inherited. I do not know what this
bouncycastle.crypto is. If it is making my setup complicated how do I get
around it? Is it part of the org.apache.coyote.http11.Http11NioProtocol?
What would you recommend I use instead? My end goal is to just enable
TLS/SSL on the connectors.

--Ez


On Mon, May 24, 2021 at 1:56 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Ezsra,
>
> On 5/24/21 10:30, Ezsra McDonald wrote:
> > I am enabling SSL debugging this morning. I did catch this in the log for
> > an instance that started erroring out this morning. Seems like it may be
> > too generic to help solve my problem. Here it is:
> >
> > 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> > java.lang.NullPointerException
> > at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
> > Source)
> > at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)
>
> Oh. You are using BouncyCastle. I've never tried to do that. I'm not
> sure how well BC will work with Tomcat. We don't officially support that
> configuration, but that doesn't mean we won't try to help.
>
> There will be a presentation at this year's ApacheCon @Home 2021 about
> configuring Tomcat for FIPS and it will include how to configure Tomcat
> with BC (including FIPS). Obviously, you don't want to wait around until
> the conference to get things working, but perhaps the presenter is
> lurking on the list ... ?
>
> I don't have an email address for the presenter, so I can't give you a
> reference. :/
>
> -chris
>
> -
> To unsubscribe, e-mail: 
> users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: 
> users-h...@tomcat.apache.org
>
>

Re: Tomcat SSL stops working after an undetermined amount of time

2021-05-24 Thread Ezsra McDonald

Chris,

Thanks for your response.

These Tomcat servers are something I inherited. I do not know what this
bouncycastle.crypto is. If it is making my setup complicated how do I get
around it?  Is it part of the org.apache.coyote.http11.Http11NioProtocol?
What would you recommend I use instead? My end goal is to just enable
TLS/SSL on the connectors.

--Ez


On Mon, May 24, 2021 at 1:56 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Ezsra,
>
> On 5/24/21 10:30, Ezsra McDonald wrote:
> > I am enabling SSL debugging this morning. I did catch this in the log for
> > an instance that started erroring out this morning. Seems like it may be
> > too generic to help solve my problem. Here it is:
> >
> > 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> > java.lang.NullPointerException
> > at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
> > Source)
> > at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)
>
> Oh. You are using BouncyCastle. I've never tried to do that. I'm not
> sure how well BC will work with Tomcat. We don't officially support that
> configuration, but that doesn't mean we won't try to help.
>
> There will be a presentation at this year's ApacheCon @Home 2021 about
> configuring Tomcat for FIPS and it will include how to configure Tomcat
> with BC (including FIPS). Obviously, you don't want to wait around until
> the conference to get things working, but perhaps the presenter is
> lurking on the list ... ?
>
> I don't have an email address for the presenter, so I can't give you a
> reference. :/
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat SSL stops working after an undetermined amount of time

2021-05-24 Thread Christopher Schultz


Ezsra,

On 5/24/21 10:30, Ezsra McDonald wrote:

I am enabling SSL debugging this morning. I did catch this in the log for
an instance that started erroring out this morning. Seems like it may be
too generic to help solve my problem. Here it is:

24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
Source)
at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)


Oh. You are using BouncyCastle. I've never tried to do that. I'm not 
sure how well BC will work with Tomcat. We don't officially support that 
configuration, but that doesn't mean we won't try to help.


There will be a presentation at this year's ApacheCon @Home 2021 about 
configuring Tomcat for FIPS and it will include how to configure Tomcat 
with BC (including FIPS). Obviously, you don't want to wait around until 
the conference to get things working, but perhaps the presenter is 
lurking on the list ... ?


I don't have an email address for the presenter, so I can't give you a 
reference. :/


-chris

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

Re: Tomcat SSL stops working after an undetermined amount of time

2021-05-24 Thread Ezsra McDonald

I was unable to identify the issue with debug enabled. I started looking
closer at the error I was getting in the various browsers. Apparently the
SSL is working. The browsers are blocking it because the server is using
something other than TLSv1.2 or better. I was able to prove this using
Safari. When I enabled the older TLS options I was able to connect. The odd
thing is that I have the connector configured for TLSv1.2. So, that is
where I need to concentrate my efforts now. Why is tomcat not using the
TLSv1.2 protocol?

As a refresher, I have the following configured for the connector.


A SSLscan of the server port shows the following requests were accepted.
Some are TLSv1.2.

sslscan target.host.com:8080|grep Accepted
Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
Accepted  TLS11  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLS11  256 bits  DHE-RSA-AES256-SHA
Accepted  TLS11  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLS11  128 bits  DHE-RSA-AES128-SHA
Accepted  TLS12  256 bits  ECDHE-RSA-AES256-GCM-SHA384
Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA384
Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLS12  256 bits  DHE-RSA-AES256-GCM-SHA384
Accepted  TLS12  256 bits  DHE-RSA-AES256-SHA256
Accepted  TLS12  256 bits  DHE-RSA-AES256-SHA
Accepted  TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256
Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA256
Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLS12  128 bits  DHE-RSA-AES128-GCM-SHA256
Accepted  TLS12  128 bits  DHE-RSA-AES128-SHA256
Accepted  TLS12  128 bits  DHE-RSA-AES128-SHA

--Ez

On Mon, May 24, 2021 at 9:30 AM Ezsra McDonald 
wrote:

> I am enabling SSL debugging this morning. I did catch this in the log for
> an instance that started erroring out this morning. Seems like it may be
> too generic to help solve my problem. Here it is:
>
> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> java.lang.NullPointerException
> at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
> Source)
> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)
> at java.security.Signature$Delegate.engineSign(Signature.java:1382)
> at java.security.Signature.sign(Signature.java:698)
> at
> sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.(CertificateVerify.java:931)
> at
> sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1105)
> at
> sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1098)
> at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:420)
> at
> sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1096)
> at
> sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1032)
> at
> sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:716)
> at
> sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:683)
> at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)
> at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
> at
> sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:983)
> at
> sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:970)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:917)
> at
> org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:432)
> at
> org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:496)
> at
> org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:237)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1611)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:748)
>
>
> I will let you know what I find in the debug. It may be a while because
> the instance works fine initially.
>
> -- Ez
>
>
> On Thu, May 20, 2021 at 10:55 AM 
> wrote:
>
>> It's "ssl,handshake."
>>
>>
>> > -Original Message-
>> > From: Ezsra McDonald 
>> > Sent: Thursday, May 20, 2021 10:43 AM
>> > To: Tomcat Users List 
>> > Subject: Re: Tomcat SSL stops working after an undetermined amount of
>> > time
>> >
>> > Mark,
>> >
>> > Thanks for your response.
>> >
>> > I did not see anything in the

Re: [External] Re: Zip file upload corruption on Linux

2021-05-24 Thread Mark Thomas


On 24/05/2021 14:22, Scott,Tim wrote:

Hi Mark,

From: Mark Thomas wrote:


import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.apache.commons.fileupload.servlet.ServletRequestContext;



You are using Commons FileUpload so this issue needs to be raised with

the Apache Commons project.


Alternatively, in Tomcat 9 file upload support is available via the

Servlet API. You could try switching to that (and any bugs would then be
a Tomcat issue).

I replaced "org.apache.commons.fileupload." with 
"org.apache.tomcat.util.http.fileupload." and tried again.

I found no change in behaviour: Leaving file.encoding to default to UTF-8 still 
corrupted the content. Setting it to ISO-8859-1 again resolved it.

Was that the Servlet API you were meaning?


No. You should be able to use HttpServletRequest.getPart()

Mark


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

Re: Tomcat SSL stops working after an undetermined amount of time

2021-05-24 Thread Ezsra McDonald

I am enabling SSL debugging this morning. I did catch this in the log for
an instance that started erroring out this morning. Seems like it may be
too generic to help solve my problem. Here it is:

24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
Source)
at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)
at java.security.Signature$Delegate.engineSign(Signature.java:1382)
at java.security.Signature.sign(Signature.java:698)
at
sun.security.ssl.CertificateVerify$T13CertificateVerifyMessage.(CertificateVerify.java:931)
at
sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.onProduceCertificateVerify(CertificateVerify.java:1105)
at
sun.security.ssl.CertificateVerify$T13CertificateVerifyProducer.produce(CertificateVerify.java:1098)
at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:420)
at
sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1096)
at
sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1032)
at
sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:716)
at
sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:683)
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:983)
at
sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:970)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:917)
at
org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:432)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:496)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:237)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1611)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)


I will let you know what I find in the debug. It may be a while because the
instance works fine initially.

-- Ez


On Thu, May 20, 2021 at 10:55 AM 
wrote:

> It's "ssl,handshake."
>
>
> > -Original Message-
> > From: Ezsra McDonald 
> > Sent: Thursday, May 20, 2021 10:43 AM
> > To: Tomcat Users List 
> > Subject: Re: Tomcat SSL stops working after an undetermined amount of
> > time
> >
> > Mark,
> >
> > Thanks for your response.
> >
> > I did not see anything in the logs. This morning I added '
> > -Djava.net.debug=handshake' to my configuration. I did not see any SSL
> > debug information in my logs. Perhaps I did this wrong or need to use a
> > different argument?
> >
> > I expected the debug to be in the access log. Should I be looking
> elsewhere?
> > I also checked other logs that had timestamps for after the instance was
> > restarted.
> >
> > -- Ez
> >
> > On Thu, May 20, 2021 at 3:05 AM Mark Thomas  wrote:
> >
> > > On 19/05/2021 20:42, Ezsra McDonald wrote:
> > > > Environment:
> > > > OS: CentOS 7
> > > > Apache: apache-tomcat-8.5.65
> > > > Java: jdk1.8.0_281
> > > >
> > > > Greetings,
> > > >
> > > > I recently enabled SSL on my Tomcat server HTTP connectors.
> > > > Something odd is happening. After some undetermined amount of time
> > > > the connector stops responding appropriately to requests. My browser
> > > > returns the following
> > > > message:
> > > >
> > > > "An error occurred during a connection to target.host.com:8080. SSL
> > > > received a malformed Alert record.
> > > >
> > > > Error code: SSL_ERROR_RX_MALFORMED_ALERT "
> > > > I do not see anything in the logs to clue me in on what is happening.
> > > >
> > > > I have the following configured for the connector.
> > > >  > > > port="${http.port}"
> > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > maxThreads="50" enableLookups="false" acceptCount="100"
> > > > server="Apache"
> > > > SSLEnabled="true" scheme="https" secure="true"
> > > > clientAuth="false" sslProtocol="TLSv1.2"
> > > > keystoreFile="/opt/tomcat/ssl/tomcat_ssl.jks"
> > > > keyAlias="tomcat"
> > > > keystorePass="**"
> > > > connectionTimeout="2"/>
> > > >
> > > > When I restart the instance everything works fine for a while.
> > > > Later,
> > > when
> > > > I try to look at the tomcat manager, SSL is no longer functioning
> > > properly.
> > > >
> > > > Any

Re: Tomcat 9 and FIP-140 mode

2021-05-24 Thread Robert Hicks

Follow on question as we are in the weeds on this now.

OpenSSL is in FIPS mode. The JDK is in FIPS mode. I think Tomcat is as the
Listener has SSLEngine="on" and FIPSMODE="on" but I am still getting the
following errors:

failed to set property [FIPSMODE] to [on]

In reading around, does the connector for the Http11AprProtocol need to be
configured as well? It is currently commented out but the section on
"configure the server.xml" here leads me to believe it needs to be:

https://stackoverflow.com/questions/34022646/how-to-make-tomcat-fips-mode-enabling

--
Bob


On Mon, Aug 24, 2020 at 2:49 PM Robert Hicks  wrote:

>
>
> On Mon, Aug 24, 2020 at 12:48 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Robert,
>>
>> On 8/24/20 11:04, Robert Hicks wrote:
>> > Maybe it's just better to straight up ask. I've found a couple of
>> > Google searches but nothing for Tomcat 9 and the information seems
>> > sporadic, incomplete, or contradictory.
>> >
>> > How do you enable FIPS-140 for Tomcat 9 (using JDK 8)?
>>
>> The Sun/Oracle-provided crypto providers should already be FIPS-140
>> certified, as long as you use them in the proper configuration.
>>
>> There is nothing Tomcat-specific about enabling FIPS for the SunJCE
>> provider because it needs to be done at the JRE-level.
>>
>> This document is WebLogic-centric, but it shows how to enable FIPS-140
>> mode for the whole JVM and therefore isn't WebLogic-specific, either:
>>
>> https://docs.oracle.com/middleware/1213/wls/SECMG/fips.htm
>>
>> Tomcat includes code for ensuring that OpenSSL is in FIPS-mode when
>> that module is in use, but we don't do anything about the built-in
>> providers. Given the information in that document above, it looks like
>> it's possible to trigger a test to determine whether FIPS is indeed
>> active; perhaps Tomcat could initiate such a test as a sanity-check if
>> FIPS-mode is "required" (through some as-yet-determined configuration
>> option).
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9D71kACgkQHPApP6U8
>> pFhcyQ//e5GXmD6jxAJYAlqfnDyrHVWQQO7TrFQxfHiJ/pvbqrFjvB230rchyRLm
>> DuWQ0C7dRMdiCLGvie3Q4KcBTkFrivlP4pckqfIihP0aETeZITFkGaWUu269ZoVD
>> ZScWxVHwLtfEf0/NR8a8g9ttjcntO7dm44BeqtOJQVST2/ti8EMZGizjx+YJREOE
>> L10CdPrUNTvoCd8s/UzThEnCBes96GjZAUid9cum1xQuyw8k3nzCNuJizNW6cE7c
>> 7BQlnXqCBqyRYloa2vJIMQ4jsNzuMsqHFQKG9UXI4ocszn/YAdSs5Zg/PFsXwwmj
>> RxSVzYJ3JUW7kg20+PNjGQ9GQFTYXtgXGManxZiOAWoiy3UR+152tiz08tfBYxBV
>> SeALsJpOKKe3+loZgUhTURsgh8qj1UC8FrfUOAr8cLmMR+HZqMvhBUcgJrv2LKi1
>> pdLarO2c/zg2O6QUwoE03qgtkKJ5ifPNOTl5hWrPFy4AQMzX+cCX2v4SkpyzV0Ty
>> gXJSJ+5b0pVwCwrf6KMi3UvJZhT+gHNttJJE/vXIZaGlft+aWvXrd3qpYcy8IND8
>> JSstrM573yCNbguYHMiT8Aa6P8jfY4enyMEkgcX/gm0LnOekCrzUl8hq5XQ/y1eo
>> g+g7pI7Dyln3FyRiUmKOp9gjND9QtFe/awvAemSvr9WRprr766k=
>> =N6LM
>> -END PGP SIGNATURE-
>>
>
> Thanks Chris!
>
> Bob
>

RE: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-24 Thread Yeggy Javadi

Hi,
I restarted tomcat so PID has changed to 143152; I do not know how to trigger 
tomcat GC, I just restart it to reset the lsof to 0.
Please see outputs below:

# ps -ef | grep tomcat
root  143152   1  0 May22 ?00:26:44 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  153962  153912  0 10:00 pts/100:00:00 grep --color=auto tomcat

# lsof -p 143152 | wc -l
41043

# lsof -p 143152 | grep "protocol: TCPv6"| wc -l
40487

# netstat -p -a -n --inet6 | grep 143152
tcp6   0  0 :::8443 :::*LISTEN  
143152/java
tcp6   0  0 :::443  :::*LISTEN  
143152/java
tcp6   0  0 127.0.0.1:8005  :::*LISTEN  
143152/java
tcp6   0  0 :::1099 :::*LISTEN  
143152/java
tcp6   0  0 :::80   :::*LISTEN  
143152/java
tcp6   0  0 :::36081:::*LISTEN  
143152/java
tcp6   0  0 10.4.3.55:60736 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60732 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60728 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:8010.197.255.10:55446 ESTABLISHED 
143152/java
tcp6   1  0 10.4.3.55:55958 10.4.3.55:11576 CLOSE_WAIT  
143152/java
tcp6   0  0 10.4.3.55:53682 172.22.21.48:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48622 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60748 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   1  0 10.4.3.55:55956 10.4.3.55:11576 CLOSE_WAIT  
143152/java
tcp6   0  0 10.4.3.55:40574 172.22.21.47:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48620 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:53782 172.22.21.48:443ESTABLISHED 
143152/java
tcp6   0  1 10.4.3.55:49808 10.12.3.78:443  SYN_SENT
143152/java
tcp6   0  0 10.4.3.55:60730 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60750 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60742 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60746 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48624 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60734 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60226 172.22.22.192:443   ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:52312 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:57302 127.0.0.1:11753 ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60738 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60740 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:8010.197.255.10:55444 ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:46976 127.0.0.1:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:40540 172.22.21.47:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:52310 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60726 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0669 10.4.3.55:60744 10.4.3.55:9300  ESTABLISHED 
143152/java

# lsof -a -p 143152 -T s -i6
COMMANDPID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
java143152 root   58u  IPv6 13816226  0t0  TCP *:http (LISTEN)
java143152 root   63u  IPv6 13816230  0t0  TCP *:https (LISTEN)
java143152 root   82u  IPv6 13816325  0t0  TCP 
localhost.localdomain:mxi (LISTEN)
java143152 root   84u  IPv6 13874431  0t0  TCP 
localhost.localdomain:52310->localhost.localdomain:postgres (ESTABLISHED)
java143152 root   86u  IPv6 13848367  0t0  TCP

RE: [External] Re: Zip file upload corruption on Linux

2021-05-24 Thread Scott,Tim

Hi Mark,

From: Mark Thomas wrote:

> import org.apache.commons.fileupload.disk.DiskFileItemFactory;
> import org.apache.commons.fileupload.servlet.ServletFileUpload;
> import org.apache.commons.fileupload.servlet.ServletRequestContext;

> You are using Commons FileUpload so this issue needs to be raised with 
the Apache Commons project.

> Alternatively, in Tomcat 9 file upload support is available via the 
Servlet API. You could try switching to that (and any bugs would then be 
a Tomcat issue).

I replaced "org.apache.commons.fileupload." with 
"org.apache.tomcat.util.http.fileupload." and tried again.

I found no change in behaviour: Leaving file.encoding to default to UTF-8 still 
corrupted the content. Setting it to ISO-8859-1 again resolved it.

Was that the Servlet API you were meaning?

Thanks,
Tim

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

Re: [External] Re: Zip file upload corruption on Linux

2021-05-24 Thread Mark Thomas


On 24/05/2021 12:08, Scott,Tim wrote:

Hi Mark,

Thanks for the prompt response.


On 24/05/2021 10:58, Scott,Tim wrote:

Hi experts,

First time poster, here, so I know I'm risking not providing nearly
enough of the right information. Please let me know what I can send to
help you help me further through this.



How are you reading the uploaded file? Please provide the code that does this.

I am reading the InputStream as below:
(merged from two classes, untested, incomplete)

import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.apache.commons.fileupload.servlet.ServletRequestContext;


You are using Commons FileUpload so this issue needs to be raised with 
the Apache Commons project.


Alternatively, in Tomcat 9 file upload support is available via the 
Servlet API. You could try switching to that (and any bugs would then be 
a Tomcat issue).


Mark




import javax.servlet.http.HttpServletRequest;
import java.io.InputStream;
import org.apache.commons.fileupload.FileItem;

ServletRequestContext requestContext = new ServletRequestContext(/* 
HttpServletRequest  */ request);
FileItemFactory factory = new DiskFileItemFactory();
FileUpload fileUpload = new ServletFileUpload(factory);
List entries = fileUpload.parseRequest(requestContext); // <<< this 
call generates the temp file
InputStream inputStream;
for (FileItem item : entries)
{
if (!item.isFormField())
{
   inputStream = item.getInputStream();
   }
}
...
byte[] buffer = new byte[BINARY_BUFFER_SIZE];
bolean eof = false;
while (!eof)
{
int count = inputStream.read(buffer);
if (count == -1)
{
eof = true;
...
   }
   ...
}

Similarly, I am not writing the temp file. I understand that this is done by 
DeferredFileOutputStream as part of the call to ServletFileUpload's 
parseRequest(); The temp file (if created) and the input stream already contain 
corrupted data.


The only way the default encoding should impact things is if the file bytes are 
being converted to String at some point.

Not by me, they're not!


That shouldn't normally happen for an uploaded file.

I agree, it shouldn't. That does not match, however, my finding that:
Using -Dfile.encoding=utf-8 on Windows corrupts the file.
Using -Dfile.encoding=ISO-8859-1 on Linux stops the file 
corruption.

Thanks,
Tim





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

RE: [External] Re: Zip file upload corruption on Linux

2021-05-24 Thread Scott,Tim

Hi Mark,

Thanks for the prompt response.

>On 24/05/2021 10:58, Scott,Tim wrote:
>> Hi experts,
>>
>> First time poster, here, so I know I'm risking not providing nearly
>> enough of the right information. Please let me know what I can send to
>> help you help me further through this.

>How are you reading the uploaded file? Please provide the code that does this.
I am reading the InputStream as below:
   (merged from two classes, untested, incomplete)

import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;
import org.apache.commons.fileupload.servlet.ServletRequestContext;
import javax.servlet.http.HttpServletRequest;
import java.io.InputStream;
import org.apache.commons.fileupload.FileItem;

ServletRequestContext requestContext = new ServletRequestContext(/* 
HttpServletRequest  */ request);
FileItemFactory factory = new DiskFileItemFactory();
FileUpload fileUpload = new ServletFileUpload(factory);
List entries = fileUpload.parseRequest(requestContext); // <<< this 
call generates the temp file
InputStream inputStream;
for (FileItem item : entries)
{
   if (!item.isFormField())
   {
  inputStream = item.getInputStream();
  }
   }
   ...
byte[] buffer = new byte[BINARY_BUFFER_SIZE];
bolean eof = false;
while (!eof)
{
int count = inputStream.read(buffer);
if (count == -1)
{
eof = true;
...
  }
  ...
   }

Similarly, I am not writing the temp file. I understand that this is done by 
DeferredFileOutputStream as part of the call to ServletFileUpload's 
parseRequest(); The temp file (if created) and the input stream already contain 
corrupted data.

> The only way the default encoding should impact things is if the file bytes 
> are being converted to String at some point.
Not by me, they're not!

> That shouldn't normally happen for an uploaded file.
I agree, it shouldn't. That does not match, however, my finding that:
   Using -Dfile.encoding=utf-8 on Windows corrupts the file.
   Using -Dfile.encoding=ISO-8859-1 on Linux stops the file 
corruption.

Thanks,
Tim

Re: Zip file upload corruption on Linux

2021-05-24 Thread Mark Thomas

On 24/05/2021 10:58, Scott,Tim wrote:

Hi experts,

First time poster, here, so I know I’m risking not providing nearly
enough of the right information. Please let me know what I can send to
help you help me further through this.

How are you reading the uploaded file? Please provide the code that does
this.

The only way the default encoding should impact things is if the file
bytes are being converted to String at some point. That shouldn't
normally happen for an uploaded file.

Mark

I’m using separate deployments of Tomcat 9 on Linux (RedHat 7) and
Windows for the same mature .war application.

Around Jan 2020 I found that uploads of ZIP files to the Linux Tomcat
were getting corrupted. The Windows upload worked fine. After much
digging I found this appears to relate to the file.encoding property.

Launching the Tomcat 9 service on Windows with “-Dfile.encoding=UTF-8”
(overriding the default of Cp1252) causes the Windows upload to corrupt
the data.

It would appear, therefore, that file.encoding is affecting binary file
uploads and I do not think it should. With this set to utf-8, I am
observing that invalid utf-8 characters are been replaced with “ef bf
bd” (the BOM/”unknown character” for UTF-8).

Is there a way to address this?

I believe source .jsp files are utf-8 encoded and I deal with utf-8 in
many parts of the application. I would rather add this encoding to the
Windows deployments than use, e.g., -Dfile.encoding=ISO-8859-1 on Linux.

Note also “If the draft JEP discussed in this post is implemented, the
default charset for file contents will be changed to UTF-8 even for
Windows.”

Ref:
https://dzone.com/articles/java-may-use-utf-8-as-its-default-charset

(March 1st, 2018)

I’ve put some details / “evidence” below should you wish to read further.

Thank you,

Tim

This morning, with Tomcat 9.0.45, I again captured a tcpdump to show
that the browser is sending the correct data. The temp file which Tomcat
created prior to passing the stream to my application is corrupted.

Part of the tcpdump submission is:

--WebKitFormBoundary37kBaouQxD4aoug5

Content-Disposition: form-data; name="file.ob_filename"; filename="MEP.zip"

Content-Type: application/x-zip-compressed

PK.`.Rtbl_Evidence.csv.Zks.H..[.=y.Do/..a.`..
.T..i..{..$c..3X.Q..

;..Q,.q..e.&..P$.X..0*.3The “89” and “b3” (no doubt an invalid utf-8 characters) have been
replaced with “ef bf bd”. This is repeated later for each subsequent
invalid utf-8 character.

In case this is relevant, I’m using Amazon’s Corretto JDK 11.0.4
(64-bit) on Linux (11.0.7 now on Windows) but I’ve observed this problem
with JDK8 and I can’t say when it started. I know it worked a few years
ago on Linux and Windows, but can’t dig out the version information for
then.

NB: Just updated to JDK 11.0.11 and it made no difference.

My extensive, repeated and varied searches merely confirm that my HTML
is OK, the form submission is as intended. Maybe the process for reading
the data is out of date but it works fine on Windows (Java is meant to
be a WORM language) and all the debugging I do shows that the data is
corrupt before my application sees it.

My JVM property file.encoding = UTF-8 on Linux and was Cp1252 on Windows.

Tim Scott

*OCLC* · Senior Software Engineer / Technical Product Manager

CityGate, 8 St. Mary’s Gate, Sheffield S1 4LW, UK

cc: IT file

OCLC COVID-19 resources: oc.lc/covid19-service-info

COVID-19: We’re in this together

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

Zip file upload corruption on Linux

2021-05-24 Thread Scott,Tim

Hi experts,

First time poster, here, so I know I'm risking not providing nearly enough of 
the right information. Please let me know what I can send to help you help me 
further through this.

I'm using separate deployments of Tomcat 9 on Linux (RedHat 7) and Windows for 
the same mature .war application.

Around Jan 2020 I found that uploads of ZIP files to the Linux Tomcat were 
getting corrupted. The Windows upload worked fine. After much digging I found 
this appears to relate to the file.encoding property.

Launching the Tomcat 9 service on Windows with "-Dfile.encoding=UTF-8" 
(overriding the default of Cp1252) causes the Windows upload to corrupt the 
data.

It would appear, therefore, that file.encoding is affecting binary file uploads 
and I do not think it should. With this set to utf-8, I am observing that 
invalid utf-8 characters are been replaced with "ef bf bd" (the BOM/"unknown 
character" for UTF-8).

Is there a way to address this?

I believe source .jsp files are utf-8 encoded and I deal with utf-8 in many 
parts of the application. I would rather add this encoding to the Windows 
deployments than use, e.g., -Dfile.encoding=ISO-8859-1 on Linux.

Note also "If the draft JEP discussed in this post is implemented, the default 
charset for file contents will be changed to UTF-8 even for Windows."
   Ref: 
https://dzone.com/articles/java-may-use-utf-8-as-its-default-charset (March 
1st, 2018)

I've put some details / "evidence" below should you wish to read further.

Thank you,
Tim


This morning, with Tomcat 9.0.45, I again captured a tcpdump to show that the 
browser is sending the correct data. The temp file which Tomcat created prior 
to passing the stream to my application is corrupted.

Part of the tcpdump submission is:

--WebKitFormBoundary37kBaouQxD4aoug5
Content-Disposition: form-data; name="file.ob_filename"; filename="MEP.zip"
Content-Type: application/x-zip-compressed

PK.`.Rtbl_Evidence.csv.Zks.H..[.=y.Do/..a.`..
 .T..i..{..$c..3X.Q..https://oc.lc/covid19-service-info>
[COVID-19: We're in this 
together]

Re: tomcat-embed-el JAR appears to violate EL spec causing ClassNotFoundException's

2021-05-24 Thread Mark Thomas

On 23/05/2021 22:40, Steve Storey wrote:

The spec at
https://docs.oracle.com/javaee/7/api/javax/el/ExpressionFactory.html#newInstance--
says:

Use the Services API (as detailed in the JAR specification).

The above is the key part.

If a
resource with the name of META-INF/services/javax.el.ExpressionFactory
exists, then its first line, if present, is used as the UTF-8 encoded name
of the implementation class.

The above is a (very) inaccurate summary of the Services API. I'll get
that sentence removed from the API Javadoc shortly.

but the tomcat-embed-el.jar file (as of 9.0.31 - "Add a META-INF/services
entry to jasper-el.jar so that the Expression Language implementation can
be discovered via the services API. (markt)") has the following file
content:

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

org.apache.el.ExpressionFactoryImpl

and thus having the licence header violates the spec.

No it doesn't. Please read the Services API specification.

When the class loader
situation means that a non-Tomcat javax.el.ExpressionFactory is resolving
which implementation to use (which happens in Wildfly but judging by
Google, also several other app servers), then it fails with a trace with
the following sort of root cause:

Caused by: java.lang.ClassNotFoundException: # Licensed to the Apache
Software Foundation (ASF) under one or more from [Module
"deployment.services-boot.war" from Service Module Loader]

Then you need to raise a bug for any application server that behaves
this way as it is not following the Services API specification.

In this specific case, it's the JBoss spec implementation at
https://github.com/jboss/jboss-jakarta-el-api_spec/blob/master/api/src/main/java/org/jboss/el/cache/FactoryFinderCache.java#L99
which reads the first line only,

Then you need to raise a bug with JBoss.

but the RI also does the same:
https://github.com/javaee/el-spec/blob/master/api/src/main/java/javax/el/FactoryFinder.java#L154

That is not the current reference implementation. The current reference
implementation is:

https://github.com/eclipse-ee4j/el-ri/blob/master/api/src/main/java/jakarta/el/FactoryFinder.java#L93

If you review the history for that file you'll find this:

https://github.com/eclipse-ee4j/el-ri/issues/118

and this:

https://github.com/eclipse-ee4j/el-ri/commit/6075bc9

so it's the Tomcat ExpressionFactory that appears to be more tolerant than
the specification allows rather than the others being buggy?

Nope. Tomcat is specification compliant and the others are buggy.

Assuming you agree that it's a spec violation,

I (speaking for the Tomcat developers on this point) do not agree.

do I raise a bugzilla myself or does one of the Tomcat developers?

In this case, neither. You need to raise a bug with JBoss and any other
app server where you have observed this behaviour.

Would an acceptable solution be to
simply move the licence header to be _after_ the first line ?

No. The acceptable solution is for the buggy app servers to fix their EL
implementation.

Mark

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

RE: Tomcat SSL stops working after an undetermined amount of time

RE: Tomcat SSL stops working after an undetermined amount of time

Re: Tomcat SSL stops working after an undetermined amount of time

Re: Tomcat SSL stops working after an undetermined amount of time

Re: Tomcat SSL stops working after an undetermined amount of time

Re: [External] Re: Zip file upload corruption on Linux

Re: Tomcat SSL stops working after an undetermined amount of time

Re: Tomcat 9 and FIP-140 mode

RE: apache-tomcat-8.5.59 too many open files on Linux 8

RE: [External] Re: Zip file upload corruption on Linux

Re: [External] Re: Zip file upload corruption on Linux

RE: [External] Re: Zip file upload corruption on Linux

Re: Zip file upload corruption on Linux

Zip file upload corruption on Linux

Re: tomcat-embed-el JAR appears to violate EL spec causing ClassNotFoundException's

15 matches

Site Navigation

Mail list logo

Footer information