Re: Tomcat won't use TLSv1.2

2020-03-06 Thread i...@flyingfischer.ch
Am 06.03.20 um 15:41 schrieb Christopher Schultz:
> Markus,
>
> On 3/5/20 13:44, i...@flyingfischer.ch wrote:
> > Try SSLProtocol="TLSv1.2" (mind the case) instead of
> > sslProtocol="-all +TLSv1.2".
>
> This is correct when using either OpenSSL or JSSE. "sslProtocol" will
> only work for JSSE configuration, and basically only allows a single
> value: "TLS".
>
> It's better to use  where it's always just "protocols".
>
> > Had this issue too. The connector parameters for SSL are a huge
> > mess and have been changed constantly.
>
> Really? Can you give an example? Other than the change from
>  to , everything has been pretty stable for
> ... decades.
>
> -chris
>
Well, yes. If I remember correctly this was:

    
    
    

Server is also built with TC native. Always using latest stable version
of TC 8.5. OpenJDK 64-Bit Server VM Zulu13.29+9-CA (build 13.0.2+6-MTS,
mixed mode, sharing).

Chrome could not cope with HTTP2 with this configuration. So I switched
back to HTTP1.1

    
    

TLSv1.2 only started to work after correcting sslProtocol to SSLProtocol.

Best
Markus



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



Re: Tomcat won't use TLSv1.2

2020-03-05 Thread i...@flyingfischer.ch




Am 05.03.20 um 23:10 schrieb rugman66 .:
> On Thu, Mar 5, 2020 at 10:44 AM i...@flyingfischer.ch
>  wrote:
>> Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all
>> +TLSv1.2".
>>
>> Had this issue too. The connector parameters for SSL are a huge mess and
>> have been changed constantly.
>>
>> Best
>> Markus
>>
>> Am 05.03.20 um 19:30 schrieb rugman66 .:
>>> Hello,
>>>
>>>
>>>
>>> I have both Apache and Tomcat running on the same RHEL. I have successfully
>>> configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use
>>> TLSv1.2. Tomcat for some reason
>>>
>>> will only use TLV 1.0, and that is no good. No matter what parameter I set
>>> in the server.xml sslProtocol directive it won’t change. Seems like it’s
>>> getting that directive somewhere else but I can't locate.
>>>
>>>
>>>
>>> >>
>>>  port="8443"
>>>
>>>  scheme="https"
>>>
>>>  secure="true"
>>>
>>>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>>>
>>>  SSLEnabled="true"
>>>
>>>  SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer"
>>>
>>>
>>> SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer"
>>>
>>>
>>> SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key"
>>>
>>>  SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW"
>>>
>>>  SSLHonorCipherOrder="true"
>>>
>>>  maxThreads="150"
>>>
>>>  clientAuth="false"
>>>
>>>  sslProtocol="-all +TLSv1.2"
>>>
>>> />
>>>
>>>
>>>
>>> OpenSSL 1.0.2d
>>>
>>> Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this
>>> time)
>>>
>>>
>>> Thank you for any insight.
>>>
>>> -John
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> Sorry, that last reply sent before I was done for some reason.
>
> Thanks Markus,
>
> One final issue. One version of the URL is still using TLS 1.0, and I
> need to disable or force it to TLS v1.2 and can't find where to do
> that.
>
> https://server.domain.com  (TLSv 1.2)
> https://server.domain.com/foo (Apache proxy TLSv1.2
> https://server.domain.com:8443 (TLS 1.0)
>
> Thanks
> -John
>

These three URLs do use two different connectors: on Port 443 and on
Port 8443.

Make sure you have configured both connectors accordingly.

Best
Markus




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



Re: Tomcat won't use TLSv1.2

2020-03-05 Thread i...@flyingfischer.ch
Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all
+TLSv1.2".

Had this issue too. The connector parameters for SSL are a huge mess and
have been changed constantly.

Best
Markus

Am 05.03.20 um 19:30 schrieb rugman66 .:
> Hello,
>
>
>
> I have both Apache and Tomcat running on the same RHEL. I have successfully
> configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use
> TLSv1.2. Tomcat for some reason
>
> will only use TLV 1.0, and that is no good. No matter what parameter I set
> in the server.xml sslProtocol directive it won’t change. Seems like it’s
> getting that directive somewhere else but I can't locate.
>
>
>
> 
>  port="8443"
>
>  scheme="https"
>
>  secure="true"
>
>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>
>  SSLEnabled="true"
>
>  SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer"
>
>
> SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer"
>
>
> SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key"
>
>  SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW"
>
>  SSLHonorCipherOrder="true"
>
>  maxThreads="150"
>
>  clientAuth="false"
>
>  sslProtocol="-all +TLSv1.2"
>
> />
>
>
>
> OpenSSL 1.0.2d
>
> Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this
> time)
>
>
> Thank you for any insight.
>
> -John
>


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



Re: secureRandom... using [SHA1PRNG] ..took (up to) 20 minutes

2019-12-30 Thread i...@flyingfischer.ch
apt-get install haveged
update-rc.d haveged defaults

Increases entropy pool and there for reduces start up time for Tomcat.

Markus


Am 30.12.19 um 11:22 schrieb Rainer Jung:
> It depends a bit on the major Java version you are using, but have a
> look at this page:
>
> https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-EntropySource
>
>
> Regards,
>
> Rainer
>
> Am 30.12.2019 um 05:01 schrieb Vince Stewart:
>> I started recently using my my java app with embedded Tomcat / 8.0.28
>> on a
>> debian VPS (DigitalOcean).
>>
>> Unfortunately, it can take up to 20 minutes to launch into action
>> from the
>> time you start execution. The issue relates to "Creation of SecureRandom
>> instance ... using SHA1PRNG".  Slowness has been described and
>> explained in
>> Stackoverflow.
>>
>> My tomcat has otherwise been so reliable that I have had no
>> motivation to
>> keep it upgraded.  Can anyone advise if some change will apply if I
>> upgrade
>> to the latest version 8.
>>
>> Otherwise, is there a configuration change I could employ.
>>
>> Many thanks,
>
> -
> 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.48: java.lang.StringIndexOutOfBoundsException

2019-11-24 Thread i...@flyingfischer.ch
Thanks for confirming and fixing.

Markus

Am 24.11.19 um 12:34 schrieb Mark Thomas:
> Thanks for providing the additional information.
>
> Confirmed. This is a regression in the fix for:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63815
>
> Yon can work-around this by reverting the addition of " in daemon.sh
> made in this commit:
> https://markmail.org/message/ouaatfznmjbrva23
>
> I'll get this fixed for the next release. The November release was
> fairly late. The December one should (hopefully) be nearer the beginning
> of the month.
>
> Also...
>
> On 24/11/2019 08:20, i...@flyingfischer.ch wrote:
>
>>>> built with
>>>>
>>>> commons-daemon-native
>>>> tomcat-native (./configure --with-apr=/usr/bin/apr-1-config
>>>> --with-java-home=$JAVA_HOME --with-ssl=yes
>>>> --prefix=/usr/share/tomcat8/$newVersion)
> Commons daemon doesn't depend on APR, nor on OpenSSL. That looks like a
> configure for Tomcat Native rather than Commons Daemon.
>
> 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 8.5.48: java.lang.StringIndexOutOfBoundsException

2019-11-24 Thread i...@flyingfischer.ch
Starting Tomcat with "service tomcat start | stop | restart" pointing to:

#!/bin/bash

### BEGIN INIT INFO
# Provides:    tomcat
# Required-Start:  $network
# Required-Stop:   $network
# Default-Start:   2 3 4 5
# Default-Stop:    0 1 6
# Short-Description: Start/Stop Tomcat server
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/share/tomcat/bin/daemon.sh

case $1 in
    start)
    $DAEMON --java-home /usr/lib/jvm/zulu-13-amd64/
--tomcat-user restrictedtomcatuser start
    ;;
    stop)
    $DAEMON --java-home /usr/lib/jvm/zulu-13-amd64/
--tomcat-user restrictedtomcatuser stop
    ;;
    restart)
    $0 stop
    $0 start
    ;;
    *)
    echo "Usage: $0 {start|stop|restart}"
esac

Markus


Am 23.11.19 um 20:44 schrieb Mark Thomas:
> On 23/11/2019 15:38, i...@flyingfischer.ch wrote:
>> openjdk version "13.0.1" 2019-10-15
>> OpenJDK Runtime Environment Zulu13.28+11-CA (build 13.0.1+10-MTS)
>> OpenJDK 64-Bit Server VM Zulu13.28+11-CA (build 13.0.1+10-MTS, mixed
>> mode, sharing)
> And how are you calling jsvc?
>
> From the stack trace it looks like an empty string is being passed as
> the class name.
>
> I wonder if this is related:
> https://markmail.org/message/ouaatfznmjbrva23
>
> Mark
>
>
>> Linux
>>
>> built with
>>
>> commons-daemon-native
>> tomcat-native (./configure --with-apr=/usr/bin/apr-1-config
>> --with-java-home=$JAVA_HOME --with-ssl=yes
>> --prefix=/usr/share/tomcat8/$newVersion)
>>
>> Markus
>>
>>
>> Am 23.11.19 um 11:37 schrieb Mark Thomas:
>>> On 23/11/2019 09:43, i...@flyingfischer.ch wrote:
>>>> After updating to Tomcat 8.5.49 starting TC on daemon fails with:
>>>>
>>>> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>>>> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
>>>> at java.base/java.lang.String.charAt(String.java:709)
>>>> at
>>>> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:136)
>>>> Cannot load daemon
>>>> Service exit with a return value of 3
>>>>
>>>> Did needto roll back to 8.5.47 which runs fine.
>>> Care to provide a few more details?
>>>
>>> Java version?
>>>
>>> Operating system?
>>>
>>> Steps to reproduce from a clean 8.5.49 install?
>>>
>>> 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
>


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



Re: Tomcat 8.5.48: java.lang.StringIndexOutOfBoundsException

2019-11-23 Thread i...@flyingfischer.ch
openjdk version "13.0.1" 2019-10-15
OpenJDK Runtime Environment Zulu13.28+11-CA (build 13.0.1+10-MTS)
OpenJDK 64-Bit Server VM Zulu13.28+11-CA (build 13.0.1+10-MTS, mixed
mode, sharing)

Linux

built with

commons-daemon-native
tomcat-native (./configure --with-apr=/usr/bin/apr-1-config
--with-java-home=$JAVA_HOME --with-ssl=yes
--prefix=/usr/share/tomcat8/$newVersion)

Markus


Am 23.11.19 um 11:37 schrieb Mark Thomas:
> On 23/11/2019 09:43, i...@flyingfischer.ch wrote:
>> After updating to Tomcat 8.5.49 starting TC on daemon fails with:
>>
>> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
>> at java.base/java.lang.String.charAt(String.java:709)
>> at
>> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:136)
>> Cannot load daemon
>> Service exit with a return value of 3
>>
>> Did needto roll back to 8.5.47 which runs fine.
> Care to provide a few more details?
>
> Java version?
>
> Operating system?
>
> Steps to reproduce from a clean 8.5.49 install?
>
> 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.48: java.lang.StringIndexOutOfBoundsException

2019-11-23 Thread i...@flyingfischer.ch
After updating to Tomcat 8.5.49 starting TC on daemon fails with:

java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
at java.base/java.lang.String.charAt(String.java:709)
at
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:136)
Cannot load daemon
Service exit with a return value of 3

Did needto roll back to 8.5.47 which runs fine.

Best
Markus

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



Re: Jakarta EE 9

2019-10-28 Thread i...@flyingfischer.ch
Am 28.10.19 um 15:39 schrieb Mark Thomas
>> If this is going to be disruptive and we cannot maintain compat, why
>> not 
>> go the extra step and explicitly move Tomcat code to
>> org.apache.tomcat.* 
>> for Tomcat 10? Git renames will work flawlessly for backports.
> It will break things for users that code against those APIs. It is a small 
> number but some do.
>
> Mark
Do you have any evidence based number on this matter? May be in turns
oout that this "small number" isn't as small as assumed...

Markus

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



Re: Bug with Tomcat-8.5 and Apache Commons FileUpload

2019-09-30 Thread i...@flyingfischer.ch
Thanks! Setting overheadDataThreshold="0" does fix the issue.

Without overheadDataThreshold the issue is very inconsistent:

Firefox 69.0.1 (64-Bit) on LNX and on other OS does result in the
described error below.

Very strange: Chrome on LNX mostly works, which means I got
intermittently once got "connection closed" with Chrome. On the second
retry the upload worked.
Even stranger: after a successful upload by Chrome it even works with FF
with the same file.

Markus

Am 30.09.19 um 20:49 schrieb Mark Thomas:
> That sounds like the client has tripped the overhead threshold protection.
>
> As a short term fix you probably want to see a lower value for:
> overheadDataThreshold
>
> see: http://tomcat.apache.org/tomcat-8.5-doc/config/http2.html
>
> possibly as low as zero.
>
> Longer term you should ideally look into why the client is sending
> small, non-final DATA frames since that as inefficient and has been
> identified as a potential DoS vector in some servers (not Tomcat but we
> block it as abusive behaviour anyway).
>
> Depending on what the client is doing, you may need to adjust the other
> over head thresholds as well. If you have a reproducible test case,
> enabling debug for http2 in logging.properties should shed some light on
> exactly what is going on.
>
> Mark
>
>
> On 30/09/2019 17:48, i...@flyingfischer.ch wrote:
>> I stumbled over a new problem which very likely appeared after
>> apache-tomcat-8.5.43 and between apache-tomcat-8.5.46
>>
>> Using Apache Commons FileUpload gives for some kind of PDF files:
>>
>> [https-openssl-apr-443-exec-15]
>> org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest
>> Failed to parse multipart request
>>
>> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
>> Processing of multipart/form-data request failed. java.io.IOException:
>> The socket associated with this connection has been closed.
>>
>> This only happens when using HTTP/2. Upload works when downgrading
>> tomcat to HTTP/1.
>>
>> There has been posted a similiar error report on Stackoverflow, which
>> indicates that the sizes of the files may be the reason:
>>
>> https://stackoverflow.com/questions/58118776/apache-commons-fileupload-problems-uploading-files-greater-than-100kb-using-htt
>>
>> Thanks for considering
>> Markus
>>
>>
>>
>> -
>> 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



Bug with Tomcat-8.5 and Apache Commons FileUpload

2019-09-30 Thread i...@flyingfischer.ch
I stumbled over a new problem which very likely appeared after
apache-tomcat-8.5.43 and between apache-tomcat-8.5.46

Using Apache Commons FileUpload gives for some kind of PDF files:

[https-openssl-apr-443-exec-15]
org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest
Failed to parse multipart request

org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. java.io.IOException:
The socket associated with this connection has been closed.

This only happens when using HTTP/2. Upload works when downgrading
tomcat to HTTP/1.

There has been posted a similiar error report on Stackoverflow, which
indicates that the sizes of the files may be the reason:

https://stackoverflow.com/questions/58118776/apache-commons-fileupload-problems-uploading-files-greater-than-100kb-using-htt

Thanks for considering
Markus



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



HttpClient 5.0 / Apache Tomcat

2019-09-27 Thread i...@flyingfischer.ch
In case anybody with advanced Docker skills is interested to help
improve compatibility tests between HttpClient 5.0 and Apache Tomcat:

http://mail-archives.apache.org/mod_mbox/hc-dev/201909.mbox/%3C0d30be42ab3743b48fd73122a4421d11d301761b.camel%40apache.org%3E

Best
Markus

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



Re: [ANN] Apache Tomcat 9.0.24 available

2019-08-19 Thread i...@flyingfischer.ch
Am 19.08.19 um 19:43 schrieb i...@flyingfischer.ch:
> Am 19.08.19 um 10:00 schrieb Mark Thomas:
>> The Apache Tomcat team announces the immediate availability of Apache
>> Tomcat 9.0.24.
>>
>> Apache Tomcat 9 is an open source software implementation of the Java
>> Servlet, JavaServer Pages, Java Unified Expression Language, Java
>> WebSocket and JASPIC technologies.
>>
>> Apache Tomcat 9.0.24 is a bugfix and feature release. The notable
>> changes compared to 9.0.22 include:
>>
>> - Expand Graal native image support to include JNDI, JSPs and JULI
>>
>> - Expand the HTTP/2 excessive overhead protection to cover various forms
>>   of abusive client behaviour and close the connection if any such
>>   behaviour is detected.
>>
>> - Security improvements to the Windows installer including a change in
>>   the default user from Local System to Local Service.
>>
>> Please refer to the change log for the complete list of changes:
>> http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
>>
>>
>> Downloads:
>> http://tomcat.apache.org/download-90.cgi
>>
>> Migration guides from Apache Tomcat 7.x and 8.x:
>> http://tomcat.apache.org/migration.html
>>
>> Enjoy!
>>
>> - The Apache Tomcat team
>>
> 
> 
> Released version is 9.0.24.
> 
> Unpacking Tomcat native in /bin gives a folder named:
> 
> tomcat-native-1.2.23-src
> 
> while this should be
> 
> tomcat-native-1.2.24-src
> 
> This may cause problems in automated update scripts.
> 
> Best Markus
> 

Another issue:

bin/commons-daemon-1.2.0-native-src/unix

does not contain the necessary script to run ./configure under linux

Present is only configure.in

Markus


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



Re: [ANN] Apache Tomcat 9.0.24 available

2019-08-19 Thread i...@flyingfischer.ch
Am 19.08.19 um 10:00 schrieb Mark Thomas:
> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat 9.0.24.
> 
> Apache Tomcat 9 is an open source software implementation of the Java
> Servlet, JavaServer Pages, Java Unified Expression Language, Java
> WebSocket and JASPIC technologies.
> 
> Apache Tomcat 9.0.24 is a bugfix and feature release. The notable
> changes compared to 9.0.22 include:
> 
> - Expand Graal native image support to include JNDI, JSPs and JULI
> 
> - Expand the HTTP/2 excessive overhead protection to cover various forms
>   of abusive client behaviour and close the connection if any such
>   behaviour is detected.
> 
> - Security improvements to the Windows installer including a change in
>   the default user from Local System to Local Service.
> 
> Please refer to the change log for the complete list of changes:
> http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
> 
> 
> Downloads:
> http://tomcat.apache.org/download-90.cgi
> 
> Migration guides from Apache Tomcat 7.x and 8.x:
> http://tomcat.apache.org/migration.html
> 
> Enjoy!
> 
> - The Apache Tomcat team
> 


Released version is 9.0.24.

Unpacking Tomcat native in /bin gives a folder named:

tomcat-native-1.2.23-src

while this should be

tomcat-native-1.2.24-src

This may cause problems in automated update scripts.

Best Markus

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



Re: Massive Startup Time after Server Reboot

2019-05-18 Thread i...@flyingfischer.ch
Sorry, you seem to be lost on a Windows Server...

...haveged won't help you in this situation.

Markus


Am 18.05.19 um 23:39 schrieb i...@flyingfischer.ch:
> Try
>
> apt-get install haveged
> update-rc.d haveged defaults
>
> This increases the system entropy for random generation and reduces boot
> time for Tomcat considerably.
>
> Markus
>
>
> Am 18.05.19 um 22:18 schrieb Rainer Jung:
>> Most likely it hangs waiting for enough entropy for random number
>> generator seeding.
>>
>> Try whether the problem goes away if you add
>>
>>   -Djava.security.egd=file:/dev/urandom
>>
>> to you process flags. If you are using older Java than Java 8 (not
>> possible for Tomcat 9 but just in case you also have older software
>> stacks running), then it would be
>>
>>   -Djava.security.egd=file:/dev/./urandom
>>
>> The cryptic /./ is not a typo, you would need it for Java before Java 8.
>>
>> If this doesn't help, then you should try capturing a few stack dumps
>> (thread dumps) during the long startup time. People here can help
>> interpret them.
>>
>> Regards,
>>
>> Rainer
>>
>> Am 18.05.2019 um 21:55 schrieb Jerry Malcolm:
>>> This is a weird one.  It started a few months ago.   I have TC 9
>>> running on Windows Server 16.  After I reboot the entire server,
>>> Tomcat takes forever on startup.  It normally starts in about 30
>>> seconds.  But after a server reboot it takes up to 15 minutes...
>>> chugging along at a snail's pace starting up all of the apps on all
>>> of the virtual hosts.  It always finally gets there with everything
>>> successfully running.  Other servers on the same box (Apache, JAMES,
>>> ISC BIND, MySQL) don't have any problem starting up.  CPU, Disk,
>>> Memory, etc. usages are barely showing on the performance graphs. 
>>> There's nothing in the Catalina log or system.err other than showing
>>> a couple of minute gap in the time stamp between each app as it
>>> starts up.  If I need to reboot again later, it boots again in about
>>> 30 sec as expected.
>>>
>>> First question... any ideas off the top of your head that might be
>>> causing this?
>>>
>>> Second question... is there any other logging I can turn on that
>>> might explain what TC is blocking on?
>>>
>>> Thanks.
>>>
>>> Jerry
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


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



Re: Massive Startup Time after Server Reboot

2019-05-18 Thread i...@flyingfischer.ch
Try

apt-get install haveged
update-rc.d haveged defaults

This increases the system entropy for random generation and reduces boot
time for Tomcat considerably.

Markus


Am 18.05.19 um 22:18 schrieb Rainer Jung:
> Most likely it hangs waiting for enough entropy for random number
> generator seeding.
>
> Try whether the problem goes away if you add
>
>   -Djava.security.egd=file:/dev/urandom
>
> to you process flags. If you are using older Java than Java 8 (not
> possible for Tomcat 9 but just in case you also have older software
> stacks running), then it would be
>
>   -Djava.security.egd=file:/dev/./urandom
>
> The cryptic /./ is not a typo, you would need it for Java before Java 8.
>
> If this doesn't help, then you should try capturing a few stack dumps
> (thread dumps) during the long startup time. People here can help
> interpret them.
>
> Regards,
>
> Rainer
>
> Am 18.05.2019 um 21:55 schrieb Jerry Malcolm:
>> This is a weird one.  It started a few months ago.   I have TC 9
>> running on Windows Server 16.  After I reboot the entire server,
>> Tomcat takes forever on startup.  It normally starts in about 30
>> seconds.  But after a server reboot it takes up to 15 minutes...
>> chugging along at a snail's pace starting up all of the apps on all
>> of the virtual hosts.  It always finally gets there with everything
>> successfully running.  Other servers on the same box (Apache, JAMES,
>> ISC BIND, MySQL) don't have any problem starting up.  CPU, Disk,
>> Memory, etc. usages are barely showing on the performance graphs. 
>> There's nothing in the Catalina log or system.err other than showing
>> a couple of minute gap in the time stamp between each app as it
>> starts up.  If I need to reboot again later, it boots again in about
>> 30 sec as expected.
>>
>> First question... any ideas off the top of your head that might be
>> causing this?
>>
>> Second question... is there any other logging I can turn on that
>> might explain what TC is blocking on?
>>
>> Thanks.
>>
>> Jerry
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


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



Re: Tomcat 9 Nio2+OpenSSL problem (very likely a bug)

2019-03-18 Thread i...@flyingfischer.ch
Am 18.03.19 um 16:43 schrieb Igor T:
>> Since 9.0.12 and 16 do the same, I wouldn't look at that at all. Something
>> simple like this works in the general case, there must be something
>> specific here. So it's Windows, which some unspecified OpenSSL version.
>>
>> Rémy
> That's not right. After many tests I've found out that 9.0.12 build
> comes with [OpenSSL 1.0.2o  27 Mar 2018], while 9.0.16 comes with
> [OpenSSL 1.1.1a  20 Nov 2018].
> The problem was localized to OpenSSL 1.1.1a on Nio2.
> Also it became clear that establishing of connection takes more time
> with OpenSSL 1.1.1a on Nio.
> So it looks like OpenSSL 1.1.1a build is much less optimized and buggy.
>
> So the question is: how to change OpenSSL version that is shipped with
> the latest tomcat build back to 1.0.2?
> Any feedback appreciated.
>

I did have to reset some installations to Tomcat 8.5.35 to avoid using
TC native latest two versions on Linux. We have seen some bugfixes in
the lastes TC native, which did slightly improve the situation. But TC
still tends to crash on some machines (Linux).

Some of the changes made in native after 8.5.35 are unstable.

Markus

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



Re: Tomcat memory growth while using TLS

2019-01-12 Thread i...@flyingfischer.ch
Am 11.01.19 um 18:23 schrieb Mark Thomas:
> Found it.
>
> The leak impacted NIO and NIO2 when used with OpenSSL.
>
> The bug is in Tomcat Native. I have a fix that I am currently testing.
> That fix should be in the next Tomcat Native release.
>
> For those interested in the technical details, Tomcat Native allocates
> some Native memory to track various attributes of each connection.
>
> In APR/Native this memory is allocated from a new APR memory pool that
> is associated with the connection. When the connection closes, the pool
> is destroyed and the memory freed. All is good.
>
> In NIO[2]+OpenSSL the per connection memory was allocated from the APR
> memory pool associated with the Connector so the memory was not released
> until the Connector was stopped. The fix is to create a pool per
> connection and use that for the per connection allocations. With a fix
> to do that in place, memory use is now broadly static under extended TLS
> load.
>
> Mark
>

Thanks Mark!

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



Re: Tomcat memory growth while using TLS

2019-01-09 Thread i...@flyingfischer.ch
Am 09.01.19 um 11:14 schrieb Mark Thomas:
> On 08/01/2019 23:51, Mason Meier wrote:
>> Hello,
>>
>> I'm running Tomcat-8.5 with TLS and I've noticed substantial memory growth
>> with requests over time, to the point that if I run Tomcat in Docker and
>> make constant requests to it, Docker will kill the container due to
>> excessive memory utilization. The problem occurs with standalone Tomcat as
>> well. Over the course of millions of requests, the memory usage of the
>> Tomcat process grows continuously, seemingly without bound.
> I've behaviour like this in the past. From memory there was some caching
> in the TLS implementation at the root of most of it that could be
> controlled with some system properties.
>
> It may be you are seeing the same thing. Or you may have found a memory
> leak. The next step would be to use a profiler to see where the memory
> is being used.
>
>> I've done a fair amount of testing on AWS EC2 instances and some local
>> machines, and here are my observations:
>>   * 'org.apache.tomcat.util.net.openssl.OpenSSLImplementation' seems to
>> increase memory utilization more quickly and consistently than
>> 'org.apache.tomcat.util.net.jsse.JSSEImplementation'. The
>> JSSEImplementation doesn't cause the memory to grow in certain setups.
> Can you share some configs that demonstrate an issue and some that
> don't. That might help narrow down what is going on.
>
> Mark
>

We do also see frequent OOM memories with the latest Tomcat versions.
Free memory shrinks to a critical value. With previous versions this
behaviour was not here. However, we use a limited machine and I need to
investigate further.

Markus

>
> -
> 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: Wrong content-type for CSS files since 8.5.37 / 9.0.14

2018-12-27 Thread i...@flyingfischer.ch
Am 27.12.18 um 21:34 schrieb Rémy Maucherat:
> On Thu, Dec 27, 2018 at 9:30 PM Mark Thomas  wrote:
>
>> On December 26, 2018 9:49:00 PM UTC, "i...@flyingfischer.ch" <
>> i...@flyingfischer.ch> wrote:
>>> Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a
>>> webapp as
>>>
>>> content-type: text/html;charset=UTF-8
>>>
>>> instead of
>>>
>>> content-type: text/css;charset=UTF-8
>>>
>>> This causes the browser (FF) not to interpret the CSS.
>>>
>>> I suspect the listed change in changelog of 8.5.36: "The default
>>> Servlet
>>> should not override a previously set content-type. (remm)"
>> Sounds likely.
>>
>> Whatever part of the app is setting the incorrect content type (probably a
>> filter) needs to be fixed.
>>
> Yes, I also prefer keeping the new behavior, which was suggested by
> Christopher. Worst case scenario there should be a new init-param.
>
> Rémy
>
I could get it fixed by disabling a filter in the (legacy) app, which
did set a hardcoded content-type to UTF-8.

Markus


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



Wrong content-type for CSS files since 8.5.37 / 9.0.14

2018-12-26 Thread i...@flyingfischer.ch
Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a
webapp as

content-type: text/html;charset=UTF-8

instead of

content-type: text/css;charset=UTF-8

This causes the browser (FF) not to interpret the CSS.

I suspect the listed change in changelog of 8.5.36: "The default Servlet
should not override a previously set content-type. (remm)"

Markus

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



Re: mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping

2018-06-20 Thread i...@flyingfischer.ch
> Hi all,
> 
> I have problems to pass (REST-) URLs containing escaped slashes ('%2F') in 
> path elements using the  Apache httpd  and  mod_jk  to the application server 
> (in fact not Tomcat, but Wildfy. But this is of no matter, here).
> 
> This kind of URL may be accepted by the httpd using the option 
> 'AllowEncodedSlashes=NoDecode'. But then, while using the mode 
> 'ForwardURIProxy' for mod_jk , they are re-encoded in a bad way: As '%252F', 
> because the percent sign itself is escaped by accident. The result is a 
> syntactically bad URL which is rejected by the application server.
> 
> I already filed this last week as  
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 . Please, may take some 
> maintainer a look at this?
> 
> with greetings
> 
> Guido
> 

You may want to create setenv.sh in CATALINA_HOME/bin with the following
option:

export
JAVA_OPTS="-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true"


Markus

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



relaxedPathChars / relaxedQueryChars XML

2018-05-10 Thread i...@flyingfischer.ch
Thanks for the two new configurable options relaxedPathChars and
relaxedQueryChars.

https://bz.apache.org/bugzilla/show_bug.cgi?id=62273

However, since these two elements will be nested in server.xml, adding

"<>"

will result in an invalid XML and a failing reboot of tomcat.

The instructions quote: "Any other characters present in the value will
be ignored".

https://tomcat.apache.org/tomcat-8.5-doc/config/http.html

So, I am not sure if adding  and  actually do work?

Markus

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



Re: Am I reinventing the wheel to get letsencrypt certs for Tomcat

2017-10-27 Thread i...@flyingfischer.ch
Am 27.10.2017 um 15:29 schrieb André Warnier (tomcat):
> On 27.10.2017 15:05, Don Flinn wrote:
>> Hi Andre,
>>
>> I have looked and it may be my ignorance but I didn't find any that
>> seemed
>> to fit.  I'll look more closely at the available letsencrypt clients.
>
> It is certainly more my own ignorance, rather than yours. I was only
> pointing out the obvious, since a fair number of people who post
> questions here seem to not bother doing their own homework first, and
> neglect obvious sources of information such as the WWW or the Tomcat FAQ.
>
> Your proposal solution below sounds very nice, and would certainly be
> of immense help to SSL/HTTPS dummies such as myself.
> I'm out of my depth already, but on this forum, Christopher may be the
> person most able to provide thoughtful and competent comments
> regarding such matters.
> I guess he'll be in shortly, being on the same oceanic side as you are
> (or seem to be; one never really knows these days).

Let's Encrypt will roll out an ACME module for Apache httpd called mod_md:

https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html

It would be most interesting to have a similar functionality directly
built into Tomcat, taking care of LE certs and their wildcard certs
coming next year.

Best regards
Markus

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



Re: TLD scanning performance question

2017-10-25 Thread i...@flyingfischer.ch

>
> Yes, it's the SecureRandom initialization that is killing you. Being a
> virtual server, it likely has no direct source of true randomness so
> it needs to pull from whatever the hypervisor is willing to provide.
>
> You'll need to ask your virtualization vendor for how to get access to
> more entropy, or switch to a less-secure random source (e.g.
> /dev/urandom on *NIX-like systems).
>
Install haveged and your boot up problems will be gone.

Markus


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



Re: URL-encoding and "#"

2017-10-13 Thread i...@flyingfischer.ch
Am 13.10.2017 um 12:48 schrieb Alex O'Ree:
> Well that explains a lot. Similar issue for me. With url encoding,  tomcat
> is dropping back slash and the plus symbol.

While I think it is perfectly eligible to strive for a most perfect
alignement with standards and specs, I think Tomcat should allow a
reasonnable set of characters to be optionally allowed (as they already
are in Tomcat up to 8.5).

I am aware that these options may be a security issue and that the
documentation should state that clearly. However it is not always
possible to correct the environment to be "standard" compatible and the
educational approach by not allowing these options is understandable but
may be not appropriate in many situations.

Best regards
Markus

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



Re: URL-encoding and "#"

2017-10-13 Thread i...@flyingfischer.ch
Am 13.10.2017 um 09:01 schrieb Mark Thomas:
> From memory, # isn't one of the allowed exceptions.
>
> The full list of invalid characters in the request line that Tomcat
> started to check for is:
> ' ', '\"', '#', '<', '>', '\\', '^', '`', '{', '|', '}'
>
> The allowed exceptions are (currently) '{', '|', '}'
>
> Mark
By the way:

While fully agreeing, that the '#' character should not be sent by a
client to the server, it still would be desirable to have those three by
optional configuration allowed characters, also be made a configurable
exception in Tomcat 9.

As fas as I know, this option has been allowed up to and including
Tomcat 8.5 only.

While it is a good thing to save the world, real world scenarios may differ.

Thanks for considering.

Markus

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



Re: Apache Struts

2017-09-14 Thread i...@flyingfischer.ch
Am 14.09.2017 um 18:38 schrieb Small, Wayne H:
> All,
>   A question for the forum:  Does TomCat 8.5.13 use Apache Struts or the Rest 
> plugin?
>
>
> Wayne Small
> Software Engineer Sr.
> Lockheed Martin
> Clearwater Manufacturing Facility
> 3655 Tampa Road
> Oldsmar, FL. 34677
> 813-854-7305 - office
> 727-455-0192 - mobile
>
> Vacation
> 05/27/2018-06/10/2018
>
> Opportunity is missed by most people because it is dressed in overalls and 
> looks like work. - Thomas Edison
>
>

No, Tomcat does not.

Your web appliactions deployed in Tomcat may or may not.

Try to search the archives:

https://marc.info/?l=tomcat-user=2=1=struts=b

Markus

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



Re: Apache Struts 2 Vulnerability in Tomcat 7.x

2017-09-08 Thread i...@flyingfischer.ch
Am 08.09.2017 um 10:59 schrieb Billy Aung Myint:
> Hi Everyone,
>
> May I know if Tomcat 7.x version is affected by the Apache Struts 2 
> vulnerability?
> I mean does Tomcat uses any of the Struts' libraries or such in any part of 
> the Tomcat?
>
> Thanks!
>
Tomcat is affected by Tomcat vulnerabilities, Struts is affected by
Struts vulnerabilities.

If you deploy old and not uptodate Struts libraries in Tomcat, then you
will be exposed to the corresponding exploits. In this case, as always
and independent of the nature of the component: upgrade to the latest
available version and or use other measure to block attacking requests.

Markus

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



Re: Access to source IP address during authentication and authorization

2017-08-08 Thread i...@flyingfischer.ch

Am 08.08.2017 um 14:05 schrieb Christopher Schultz:
> All,
>
> In spite of my (somewhat) recent work on the CredentialHandlers, I
> haven't been using Tomcat's container-provider authentication and
> authorization for over a decade. This is because I need access to the
> user's source IP address for auditing where users "are" when they
> login to my applications.
>
> Is there any opportunity to obtain the user's IP address during login?
> IIRC, the JASPIC scheme does allow this kind of information, but I'm
> not sure if Tomcat actually supplies it. JASPIC is a rather
> complicated solution when I am in fact authenticating against a simple
> relational database.
>
> What might be other ways to obtain the user's IP address during
> authentication?
>
> Thanks,
> -chris
>
> PS I don't use Spring, to "just use Spring security like everyone
> else" isn't a great solution for me.

If you run Tomcat only you may use request.getRemoteAddr() in the logic
and build IP based access management around this.

If you run Apache in front of Tomcat you may need to fiddle with
X-Forwarded-For header.

Markus




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



Re: java

2016-07-18 Thread i...@flyingfischer.ch

Am 18.07.2016 um 17:14 schrieb Sanka, Ambica:

Steffen,
Is it also possible to test your stuff with jdk1.8.0_51 so that we will know 
something must be wrong with security in jdk1.8.0_51?
Appreciate your help
Ambica.



You may want to follow the changes in

http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html

There have been several changes regarding the acceptance of 
certificates. You may change this behaviour in


/usr/lib/jvm/java-8-oracle/jre/lib/security/java.security

Any changes in this file will be overriden by the next update.

Markus

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



SSL inconsistency

2016-07-14 Thread i...@flyingfischer.ch
While testing locally the new 8.5 branch, I did experience some 
inconsistency with self-sigend SSL certs. I did manage to resolve them 
by installing Tomcat-Native library / APR, but maybe it is still worth 
reporting in regard of the different behaviour for the same cert, 
between Tomcat versions and configuartions.


I didn't want to file a bug, since this very likely is a configuration 
and/or self-signed cert problem.


Thanks for considering.

Markus

Tomcat 8, works fine.
Tomcat 8.5  error => Alias name tomcat does not identify a key entry



---

Tomcat 8.5, same cert, starts fine but throws on first SSL invocation:

java.lang.IllegalArgumentException: Invalid character found in method 
name. HTTP method names must be tokens




---

Tomcat 8.5, new cert
Tomcat-Native / APR disabled

Failed to initialize end point associated with ProtocolHandler 
["https-jsse-nio-8443"]

java.security.KeyStoreException: Cannot store non-PrivateKeys

Same cert works with Tomcat-Native / APR enabled

protocol="org.apache.coyote.http11.Http11NioProtocol"
   maxThreads="150" secure="true" scheme="https" 
SSLEnabled="true" defaultSSLHostConfigName="localhost">






Also works with protocol="org.apache.coyote.http11.Http11AprProtocol" 
with Tomcat-Native / APR enabled



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