[slighly OT] Re: Apache Vulnerability - Understanding Connector Protocols

[Peter Kreuser]

Michael, Mark and Chris,

> Am 02.08.2019 um 01:40 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Michael,
> 
 On 8/1/19 15:21, Michael Osipov wrote:
 Am 2019-08-01 um 21:19 schrieb Mark Thomas:
 On 01/08/2019 20:07, Justiniano, Tony wrote:
 And that is what I was thinking, inadvertently, our scanning
 tool just found the apache version during a scan and
 corresponded it (the apache version) with a CVE.
 
 Do you concur?
>>> 
>>> Sounds likely. Most low quality scanning tools only look at the
>>> version number.
>> 
>> I was told the same security by obscurity nonsense by our ISEC
>> team.

Being the ISEC team(!), I‘d ask you to validate the finding and do your 
homework, patch (you do, right?) or reconfigure your system and if it is a 
false positive mark it as such. Done. So you are aware of the possible problems 
and you have assessed the risk: no http/2==0! (Well you don‘t enable it next 
week, of course?!)

I assume noone here would like a vuln scanner to exploit all issues and tear a 
system down. But of course there are stupid an better ones (Scanner and ISEC 
teams ;-)). Nevertheless the process of excluding false positives should be 
reasonable.

> The OP should just set their reported version number to Tomcat 4.3 and
> let it completely freak out.

Just for the test of it: great idea!

But one of the first hardening actions on Tomcat is to disable standard error 
pages and version info. Server header removed (set to IIS if you like!)



You reduce these findings and the info for the attackers.

Peter
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1DeFsACgkQHPApP6U8
> pFixVBAAtRtkVQipOISzRnd7eFUpKTgpZeENUvbJlCSrgiKu66IJx+1WDdO81zmj
> mAk+F2syOoZgThiB5icu6gISwcpJm4yWWQOb+QileSQtjvkhdgueiv1Hwla74fm3
> jz/FtFc+6xiYGSG07/O9RgJASeM7Dabo+UB7KCXrDpL2WxDw1hU8kWUYIpnR16Ub
> 1DlXtOcIlnFe5FLld4WR8VHO6kAjNJd25EvYNqpEOfkG2WpJwkhGsMyDHcom40AF
> H5b7nrtpAVi1kaiyWcGVGpyFqUjZfdXYHM9bDDn1dsAkMBiYNDg8tlMT8JtkzZK9
> ULKBwnEJdeKJ6PvVfSDpsRYkSCqVJJXS/5X5Wx41VhbrHxKvnywimHNNxB3bQbAn
> LW1rvsP1aD1GaDzBwP2DoUKVUeMqhnVGwM75/Dyi7UjVu79xhoQpnR5aNmtB+k5/
> Kasib1LdFvNpZTs/1UgoG/JjVOd6j8nDe0U44cC23eSYBnq8bsGuaCUmSgsNOvOF
> ykA/0cMoGNFw481GZhgggOfAA+l+4m+x8CDQrawlq5d5Hx/6dBDGSjUqo0XWSg0J
> zJmJxPVj0024aD0Lt+ZO3U9Z0qIQ8doc0AkKO6t5wFJGAWTccDMsQAQV4UejRBDt
> dXpJdvqmZ28yxoOK2PNs8Swo1dg1iFF1xgqtu254nWqlU3/3xV8=
> =z4EQ
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

RE:Component working in Console not as Service

[Potgieter, Carlo]

On 01.08.2019 13:02, Potgieter, Carlo wrote:
> On 31.07.2019 20:26, Potgieter, Carlo wrote:
>> On 31.07.2019 14:49, Mark Thomas wrote:
>>> On 31/07/2019 13:03, Potgieter, Carlo wrote:


 On 31/07/2019 12:48, Potgieter, Carlo wrote:
> I was hoping to obtain some assistance. We have used a library to convert 
> MS Office documents (docx and pptx) to PDF.
>
> This works perfectly in the development environment and also when running 
> Tomcat in a console window.
>
> The moment we run Tomcat as a service this specific component gives and 
> error. Unfortunately the error is non-specific so we cannot troubleshoot 
> the origin.
>
> My question is, what would be the difference in running Tomcat as a 
> Service as oppose to running it in Console that might cause this problem?

 Tomcat runs as a different user with different access permissions, 
 particularly to network shares.

 You probably want to set up a Tomcat specific user with the appropriate 
 permissions.

 Mark

 Thank you Mark for the quick response.

 My first thought was permissions also, however I have attempted to run it 
 with local, domain and system user, however the same result.

 Both local and domain user was part of the local admin group. Is there 
 anything else I can check?
>>>
>>> Are you sure the DDL is being loaded? That normally needs explicit
>>> configuration to point the JVM at the right path.
>>>
>>> Look at the docs for for
>>> org.apache.catalina.startup.VersionLoggerListener and configure it
>>> to dump everything. Then compare the console start with the service start.
>>>
>>
>> What is also different when Tomcat runs as a Service or in a console, is 
>> where the JVM that runs tomcat, picks up its environment and command-line 
>> switches.
>> If you are not familiar with this matter, this may help :
>> verbose explanation :
>> https://secure-web.cisco.com/16LxnNI0vUhSt5WCJq8xkkulFgI8kkE6jU6nNTTW
>> H
>> 8Edc36MeIASjeU6nUbSA_zE1ivz6c5TGLRI5-1Pf6_zuQkUOEaw8utUuFpuUnCrCLIeiS
>> 7
>> dhXxvll2giIW3fHOBe1_gpGzPiGufx1vE50Dzs9UUSm5Rc1iB9G9UILBUZ6dhLaGa3vAE
>> U
>> t8bmVvfaGcwlM8tmxid6q8PydRkxPkVHu_02IIO1w4c2yyYp4O9vhwKqUq1OeApnpAj1c
>> 0
>> e2G-t0fT-lxYS5ofL92-i2ZpXEQk9bpTnCXLs0bT0wnFZYQsrFJZ8GQQckDdY-8eBWc94
>> 6
>> XK9enjcTwIMehHfk013zuw/https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2F
>> d
>> isplay%2FTOMCAT%2FWindows#Windows-Q11
>> Official page :
>> https://secure-web.cisco.com/1BYhcwXb2ofGRuNXu8K-JZBV4sFyWUkMe0XaNSYX
>> c
>> ey93JyiAhWVVK1zM0iJzrwal62xEQvv7bWZTbZIMuGTP_S_2qZdoXT4tLt78CPHzpOJND
>> 9
>> 6h28X7R95_fnapxZO1zDvqNUPkrh23BUmyvnfKvqfef2panME2Z0l8GOvPAP4lZdyaSwg
>> c
>> D0L2TM7oClsAQ4TPAeM8hVEtWCsJsoeQjwh7m4IHyvpPDfPDJ28gRGkBoLQWETM9alb7R
>> H
>> jMtvclQ7-lMp3IYS9kOzQBDVHACmGkdIqgx-XAWNBjM6Wce6IoYmAeiwIgYmPZ0oClxso
>> v
>> Fcb1-dH06wAs3t938YQVvw/https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-d
>> o
>> c%2Fwindows-service-howto.html
>>
>> (Perhaps the application expects some value to be set somewhere..)
>>
>> Also, above you mention "Unfortunately the error is non-specific..", but 
>> maybe you want to copy the error message here, so that someone else can have 
>> a look at it ?
>> Maybe it triggers some recognition by another user having had the same issue 
>> with that library.
>>
>>
>> Quickly answering both posts from Mark and Andrei:
>>
>> Mark: Yes, the DLL is being loaded. There is error handling in place should 
>> it be unsuccessful in accessing any of the components.
>> I also compared the output of the VersionLoggerListners:
>> When running as a service and executing the Tomcat8.exe from cmd the 
>> information is the same, however the functionality only works when the .exe 
>> is run from cmd.
>> When using the Startup.bat script to start the server there are three less 
>> entries and one extra:
>>
>> Entries not included:
>> 31-Jul-2019 19:34:37.398 INFO [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Command line
>> argument: exit
>> 31-Jul-2019 19:34:37.399 INFO [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Command line
>> argument: -Xms128m
>> 31-Jul-2019 19:34:37.399 INFO [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Command line
>> argument: -Xmx256m
>>
>> Entry included but not in the other two:
>> 31-Jul-2019 19:37:11.434 INFO [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Command line
>> argument: -Djdk.tls.ephemeralDHKeySize=2048
>>
>> Again using this method to run the server allows the functionality to work.
>>
>> Andre: From what I could see, everything is loaded the same as all of them 
>> uses the sae JVM. Unless I missed something...which is entirely possible.
>> The zeonpadpdf we are using consists of 3 components, 2 .jar's and 1
>> .dll. zeonpadpdf.jar, jacob-1.18.jar, jacob-1.18-x64.dll The error we are 
>> receiving states: "Conversion error" and is generated from the 
>> zeonpadpdf.jar which handles 

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

[Christopher Schultz]

-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

Re: FW: Apache Vulnerability - Understanding Connector Protocols

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 8/1/19 15:21, Michael Osipov wrote:
> Am 2019-08-01 um 21:19 schrieb Mark Thomas:
>> On 01/08/2019 20:07, Justiniano, Tony wrote:
>>> And that is what I was thinking, inadvertently, our scanning
>>> tool just found the apache version during a scan and
>>> corresponded it (the apache version) with a CVE.
>>> 
>>> Do you concur?
>> 
>> Sounds likely. Most low quality scanning tools only look at the
>> version number.
> 
> I was told the same security by obscurity nonsense by our ISEC
> team.

The OP should just set their reported version number to Tomcat 4.3 and
let it completely freak out.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl1DeFsACgkQHPApP6U8
pFixVBAAtRtkVQipOISzRnd7eFUpKTgpZeENUvbJlCSrgiKu66IJx+1WDdO81zmj
mAk+F2syOoZgThiB5icu6gISwcpJm4yWWQOb+QileSQtjvkhdgueiv1Hwla74fm3
jz/FtFc+6xiYGSG07/O9RgJASeM7Dabo+UB7KCXrDpL2WxDw1hU8kWUYIpnR16Ub
1DlXtOcIlnFe5FLld4WR8VHO6kAjNJd25EvYNqpEOfkG2WpJwkhGsMyDHcom40AF
H5b7nrtpAVi1kaiyWcGVGpyFqUjZfdXYHM9bDDn1dsAkMBiYNDg8tlMT8JtkzZK9
ULKBwnEJdeKJ6PvVfSDpsRYkSCqVJJXS/5X5Wx41VhbrHxKvnywimHNNxB3bQbAn
LW1rvsP1aD1GaDzBwP2DoUKVUeMqhnVGwM75/Dyi7UjVu79xhoQpnR5aNmtB+k5/
Kasib1LdFvNpZTs/1UgoG/JjVOd6j8nDe0U44cC23eSYBnq8bsGuaCUmSgsNOvOF
ykA/0cMoGNFw481GZhgggOfAA+l+4m+x8CDQrawlq5d5Hx/6dBDGSjUqo0XWSg0J
zJmJxPVj0024aD0Lt+ZO3U9Z0qIQ8doc0AkKO6t5wFJGAWTccDMsQAQV4UejRBDt
dXpJdvqmZ28yxoOK2PNs8Swo1dg1iFF1xgqtu254nWqlU3/3xV8=
=z4EQ
-END PGP SIGNATURE-

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

Re: TLSv1.3 in TC8.5 + Azul Java 8

[Mark Thomas]

On 01/08/2019 21: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]. Does this 
> help TC with JSSE SSL engine to also offer TLSv1.3 on its SSL listeners?

It the JRE supports it then you can specify it in Tomcat's server.xml
and Tomcat will use it.

Mark


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


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

RE: Invalid HTTP Header - attack?

[Justiniano, Tony]

My apologies, the version of Apache that came with the application is 9.0.13.

Tony Justiniano
Engineer I, EUS Engineering

Wyndham Destinations
6277 Sea Harbor Drive
Orlando, FL 32821
Office: +1-407-626-5416
Mobile: +1-407-463-4297
tony.justini...@wyn.com

-Original Message-
From: John Dale 
Sent: Thursday, August 1, 2019 4:37 PM
To: Tomcat Users List 
Subject: Re: Invalid HTTP Header - attack?

This e-mail is from an external source.  Use caution when opening attachments 
or clicking on links.

9.0.16.0 - this is the version installed with apt-get tomcat9 on ubuntu 18.04

Thank you for your feedback.

John


On 8/1/19, Konstantin Kolinko  wrote:
> чт, 1 авг. 2019 г. в 22:11, John Dale :
>>
>> Great feedback.  Thanks.
>>
>> I am the network department. :)
>>
>> This is a public facing service and shortly after I see this in the
>> log, I get an OOM exception and server shutdown.  Twice now this
>> morning.
>>
>
> The exception text is a bit misleading. It says "header", but it
> actually caused by sanity checks that are done when parsing the first
> line of the request (it precedes all the headers) aka the "request
> line". Thus you can see "parseRequestLine()" in the stack trace.
>
> As you may know, starting with HTTP/1.1 a client can send several HTTP
> request over the same connection (aka "keep alive", also "request
> pipelining"). If the length of the preceding request was not processed
> correctly either because the client sent an incorrect value of
> Content-Length header or if there is a bug, Tomcat will start parsing
> a new request at a wrong place and you will see such an error.
>
> Other cause of similar errors is when a client tries to connect using
> https: protocol to a http: connector. A small difference is that in
> that case the sanity check will be triggered earlier: when parsing the
> HTTP method name (the first component of the request line). In your
> case the error message says about the HTTP protocol version (the third
> component of the request line).
>
>
> 1. Personally, I always run with
> org.apache.catalina.connector.RECYCLE_FACADES=true
> as documented in [1].
>
> This property helps if there is a bug in a web application.
>
> 2. Make sure that you use an up-to-date version of Tomcat. You didn't
> tell us what version of Tomcat 9.0.x you are using.
>
> 3. If there is bug that causes Tomcat to incorrectly process a length
> of a request (a known way to trigger such a bug), I think that it will
> be treated as a security vulnerability that leads to an information
> leak.
>
> See CVE-2018-8037 )fixed in 9.0.10), CVE-2017-5651 and CVE-2017-5647
> (both fixed in 9.0.0.M19) for an idea.
>
> https://tomcat.apache.org/security-9.html
>
> Maybe you can configure creation of a heap dump during the OOM, so
> that it could be diagnosed what is causing a memory leak?
>
> Note that there is a procedure to report security issues [2]. A public
> Bugzilla should not be used for such reports.
>
> 4. The error message that you saw is printed only once in every 24
> hours. The latter occurrences during the same day are suppressed
> (logged at DEBUG level) to prevent flooding one's log files. This
> behaviour is controlled by system properties [3],
>
> org.apache.juli.logging.UserDataHelper.CONFIG
> org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME
>
> [1]
> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Pr
> operties
>
> [2] https://tomcat.apache.org/security.html
>
> [3]
> https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Loggi
> ng
>
> 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

This email message (including all attachments) is for the sole use of the 
intended recipient(s) and may contain confidential and/or privileged 
information, or may otherwise be protected by work product or other legal 
rules. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message. Unless otherwise 
indicated in the body of this email, nothing in this communication is intended 
to operate as an electronic signature and this transmission cannot be used to 
form, document, or authenticate a contract. Wyndham Destinations, Inc., and/or 
its affiliates may monitor all incoming and outgoing email communications, 
including the content of emails and attachments, for security, legal 
compliance, training, quality assurance and other purposes. The sender believes 
that this email and any attachments were free of any virus, worm, Trojan horse, 
malicious code and/or other contaminants when sent. Email transmissions cannot 

TLSv1.3 in TC8.5 + Azul Java 8

[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: failing fast when the server is overloaded

[Mark Thomas]

On 01/08/2019 21:10, john.e.gr...@wellsfargo.com.INVALID wrote:
> Folks,
> 
> I've been using Tomcat for a long time but am new-ish to NIO (Tomcat 8.5.)  
> It seems that one of the big benefits of NIO is decoupling the worker threads 
> from the client connections.  I can now have a large number of open 
> connections without a corresponding large number of threads.
> 
> I know the acceptCount parameter will stop incoming connection requests if 
> the server is overloaded.  However, suppose I have 1000 open connections and 
> 100 of those connections have a request in flight, using all 100 of the 
> threads I've allocated.  Now what happens if the other 900 connections 
> suddenly send me requests?

They wait until either the client times out waiting to read the response
or one of the 100 allocated threads completes the request/response it
was working and takes the next of the 900 waiting requests off the queue.

> Does acceptCount play any role?

No, no with those numbers. If you increase that 900 then acceptCount
will - eventually - play a role.

>  Is there some other mechanism that I can use to fail fast (by sending back a 
> 503, for example?)

Short of decreasing maxConnections, no.

Mark

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

Re: Invalid HTTP Header - attack?

[John Dale]

9.0.16.0 - this is the version installed with apt-get tomcat9 on ubuntu 18.04

Thank you for your feedback.

John


On 8/1/19, Konstantin Kolinko  wrote:
> чт, 1 авг. 2019 г. в 22:11, John Dale :
>>
>> Great feedback.  Thanks.
>>
>> I am the network department. :)
>>
>> This is a public facing service and shortly after I see this in the
>> log, I get an OOM exception and server shutdown.  Twice now this
>> morning.
>>
>
> The exception text is a bit misleading. It says "header", but it
> actually caused by sanity checks that are done when parsing the first
> line of the request (it precedes all the headers) aka the "request
> line". Thus you can see "parseRequestLine()" in the stack trace.
>
> As you may know, starting with HTTP/1.1 a client can send several HTTP
> request over the same connection (aka "keep alive", also "request
> pipelining"). If the length of the preceding request was not processed
> correctly either because the client sent an incorrect value of
> Content-Length header or if there is a bug, Tomcat will start parsing
> a new request at a wrong place and you will see such an error.
>
> Other cause of similar errors is when a client tries to connect using
> https: protocol to a http: connector. A small difference is that in
> that case the sanity check will be triggered earlier: when parsing the
> HTTP method name (the first component of the request line). In your
> case the error message says about the HTTP protocol version (the third
> component of the request line).
>
>
> 1. Personally, I always run with
> org.apache.catalina.connector.RECYCLE_FACADES=true
> as documented in [1].
>
> This property helps if there is a bug in a web application.
>
> 2. Make sure that you use an up-to-date version of Tomcat. You didn't
> tell us what version of Tomcat 9.0.x you are using.
>
> 3. If there is bug that causes Tomcat to incorrectly process a length
> of a request (a known way to trigger such a bug), I think that it will
> be treated as a security vulnerability that leads to an information
> leak.
>
> See CVE-2018-8037 )fixed in 9.0.10), CVE-2017-5651 and CVE-2017-5647
> (both fixed in 9.0.0.M19) for an idea.
>
> https://tomcat.apache.org/security-9.html
>
> Maybe you can configure creation of a heap dump during the OOM, so
> that it could be diagnosed what is causing a memory leak?
>
> Note that there is a procedure to report security issues [2]. A public
> Bugzilla should not be used for such reports.
>
> 4. The error message that you saw is printed only once in every 24
> hours. The latter occurrences during the same day are suppressed
> (logged at DEBUG level) to prevent flooding one's log files. This
> behaviour is controlled by system properties [3],
>
> org.apache.juli.logging.UserDataHelper.CONFIG
> org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME
>
> [1]
> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Properties
>
> [2] https://tomcat.apache.org/security.html
>
> [3]
> https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Logging
>
> 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

Re: Invalid HTTP Header - attack?

[Konstantin Kolinko]

чт, 1 авг. 2019 г. в 22:11, John Dale :
>
> Great feedback.  Thanks.
>
> I am the network department. :)
>
> This is a public facing service and shortly after I see this in the
> log, I get an OOM exception and server shutdown.  Twice now this
> morning.
>

The exception text is a bit misleading. It says "header", but it
actually caused by sanity checks that are done when parsing the first
line of the request (it precedes all the headers) aka the "request
line". Thus you can see "parseRequestLine()" in the stack trace.

As you may know, starting with HTTP/1.1 a client can send several HTTP
request over the same connection (aka "keep alive", also "request
pipelining"). If the length of the preceding request was not processed
correctly either because the client sent an incorrect value of
Content-Length header or if there is a bug, Tomcat will start parsing
a new request at a wrong place and you will see such an error.

Other cause of similar errors is when a client tries to connect using
https: protocol to a http: connector. A small difference is that in
that case the sanity check will be triggered earlier: when parsing the
HTTP method name (the first component of the request line). In your
case the error message says about the HTTP protocol version (the third
component of the request line).


1. Personally, I always run with
org.apache.catalina.connector.RECYCLE_FACADES=true
as documented in [1].

This property helps if there is a bug in a web application.

2. Make sure that you use an up-to-date version of Tomcat. You didn't
tell us what version of Tomcat 9.0.x you are using.

3. If there is bug that causes Tomcat to incorrectly process a length
of a request (a known way to trigger such a bug), I think that it will
be treated as a security vulnerability that leads to an information
leak.

See CVE-2018-8037 )fixed in 9.0.10), CVE-2017-5651 and CVE-2017-5647
(both fixed in 9.0.0.M19) for an idea.

https://tomcat.apache.org/security-9.html

Maybe you can configure creation of a heap dump during the OOM, so
that it could be diagnosed what is causing a memory leak?

Note that there is a procedure to report security issues [2]. A public
Bugzilla should not be used for such reports.

4. The error message that you saw is printed only once in every 24
hours. The latter occurrences during the same day are suppressed
(logged at DEBUG level) to prevent flooding one's log files. This
behaviour is controlled by system properties [3],

org.apache.juli.logging.UserDataHelper.CONFIG
org.apache.juli.logging.UserDataHelper.SUPPRESSION_TIME

[1] 
https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html#System_Properties

[2] https://tomcat.apache.org/security.html

[3] https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Logging

Best regards,
Konstantin Kolinko

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

failing fast when the server is overloaded

[John.E.Gregg]

Folks,

I've been using Tomcat for a long time but am new-ish to NIO (Tomcat 8.5.)  It 
seems that one of the big benefits of NIO is decoupling the worker threads from 
the client connections.  I can now have a large number of open connections 
without a corresponding large number of threads.

I know the acceptCount parameter will stop incoming connection requests if the 
server is overloaded.  However, suppose I have 1000 open connections and 100 of 
those connections have a request in flight, using all 100 of the threads I've 
allocated.  Now what happens if the other 900 connections suddenly send me 
requests?  Does acceptCount play any role?  Is there some other mechanism that 
I can use to fail fast (by sending back a 503, for example?)

Thanks

John

Re: FW: Apache Vulnerability - Understanding Connector Protocols

[Michael Osipov]

Am 2019-08-01 um 21:19 schrieb Mark Thomas:

On 01/08/2019 20:07, Justiniano, Tony wrote:

And that is what I was thinking, inadvertently, our scanning tool just found 
the apache version during a scan and corresponded it (the apache version) with 
a CVE.

Do you concur?


Sounds likely. Most low quality scanning tools only look at the version
number.


I was told the same security by obscurity nonsense by our ISEC team.

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

Re: FW: Apache Vulnerability - Understanding Connector Protocols

[Mark Thomas]

On 01/08/2019 20:07, Justiniano, Tony wrote:
> And that is what I was thinking, inadvertently, our scanning tool just found 
> the apache version during a scan and corresponded it (the apache version) 
> with a CVE.
> 
> Do you concur?

Sounds likely. Most low quality scanning tools only look at the version
number.

Mark


> 
> Tony Justiniano
> Engineer I, EUS Engineering
> 
> Wyndham Destinations
> 6277 Sea Harbor Drive
> Orlando, FL 32821
> Office: +1-407-626-5416
> Mobile: +1-407-463-4297
> tony.justini...@wyn.com
> 
> -Original Message-
> From: Mark Thomas 
> Sent: Thursday, August 1, 2019 3:05 PM
> To: users@tomcat.apache.org
> Subject: Re: FW: Apache Vulnerability - Understanding Connector Protocols
> 
> This e-mail is from an external source.  Use caution when opening attachments 
> or clicking on links.
> 
> On 01/08/2019 19:49, Justiniano, Tony wrote:
>> Forwarding from an initial email this morning.
>>
>> ___
>>
>> Good Morning,
>>
>> I have been referred to this team in an attempt to have some questions 
>> answered.  Before I ask those question let me provide a little background on 
>> how I got to this point.
>>
>> Vulnerability scans showed that two of my servers in the DMZ came back with 
>> CVE-2019-10072 vulnerability.  The CVE information is below:
>>
>> The fix for CVE-2019-0199 was incomplete and did not address HTTP/2
>> connection window exhaustion on write in Apache Tomcat versions
>> 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE
>> messages for the connection window (stream 0) clients were able to
>> cause server-side threads to block eventually leading to thread
>> exhaustion and a DoS.
>> (CVE-2019-10072> 9-10072>)
>>
>> The question I have is based on the server.xml configuring the connector and 
>> protocols used.  Below are both of my servers server.xml connector entries:
>> Server6: > protocol="org.apache.coyote.http11.Http11NioProtocol"
>>
>> Server5: > protocol="org.apache.coyote.http11.Http11NioProtocol"
>>
>> What I have highlighted are the protocols that are used for those specific 
>> connectors on the servers.
>>
>> So, my question is in your professional opinions, if I'm not calling the 
>> http2 protocol in any connector, my servers shouldn't be susceptible to the 
>> particular CVE's vulnerability assessment.
>>
>> Please let me know if this question can be answered.
> 
> If you don't have
> 
> 
> 
> nested in a Connector anywhere in your server.xml that you can't possibly be 
> vulnerable to HTTP/2 related vulnerabilities.
> 
> Looks like it is time to start shopping for a new vulnerability scanner.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> This email message (including all attachments) is for the sole use of the 
> intended recipient(s) and may contain confidential and/or privileged 
> information, or may otherwise be protected by work product or other legal 
> rules. If you are not the intended recipient, please contact the sender by 
> reply email and destroy all copies of the original message. Unless otherwise 
> indicated in the body of this email, nothing in this communication is 
> intended to operate as an electronic signature and this transmission cannot 
> be used to form, document, or authenticate a contract. Wyndham Destinations, 
> Inc., and/or its affiliates may monitor all incoming and outgoing email 
> communications, including the content of emails and attachments, for 
> security, legal compliance, training, quality assurance and other purposes. 
> The sender believes that this email and any attachments were free of any 
> virus, worm, Trojan horse, malicious code and/or other contaminants when 
> sent. Email transmissions cannot be guaranteed to be secure or error-free, so 
> this message and its attachments could have been infected, corrupted or made 
> incomplete during transmission. By reading the message and opening any 
> attachments, the recipient accepts full responsibility for any viruses or 
> other defects that may arise, and for taking remedial action relating to such 
> viruses and other defects. Neither Wyndham Destinations, Inc., nor any of its 
> affiliated entities is liable for any loss or damage arising in any way from, 
> or for errors or omissions in the contents of, this message or its 
> attachments.
> 
> -
> 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: Invalid HTTP Header - attack?

[John Dale]

Great feedback.  Thanks.

I am the network department. :)

This is a public facing service and shortly after I see this in the
log, I get an OOM exception and server shutdown.  Twice now this
morning.

Hmm .. :\

John


On 8/1/19, Michael Osipov  wrote:
> Am 2019-08-01 um 20:36 schrieb Mark Thomas:
>> On 01/08/2019 19:08, John Dale wrote:
>>> I'm getting this in my logs - is this an attack do you think?
>>
>> Unlikely to be an attack. Most likely a broken client.
>
> There is another scenario:
>
> Regular security scans on all corporate subnets from sec dept. I have
> these almost every day in access.log and via SSH.
>
> Ask your network department who's IP this is and you should get better
> information.
>
> See also: https://bz.apache.org/bugzilla/show_bug.cgi?id=55372
>
> Michael
>
> -
> 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: FW: Apache Vulnerability - Understanding Connector Protocols

[Justiniano, Tony]

And that is what I was thinking, inadvertently, our scanning tool just found 
the apache version during a scan and corresponded it (the apache version) with 
a CVE.

Do you concur?

Tony Justiniano
Engineer I, EUS Engineering

Wyndham Destinations
6277 Sea Harbor Drive
Orlando, FL 32821
Office: +1-407-626-5416
Mobile: +1-407-463-4297
tony.justini...@wyn.com

-Original Message-
From: Mark Thomas 
Sent: Thursday, August 1, 2019 3:05 PM
To: users@tomcat.apache.org
Subject: Re: FW: Apache Vulnerability - Understanding Connector Protocols

This e-mail is from an external source.  Use caution when opening attachments 
or clicking on links.

On 01/08/2019 19:49, Justiniano, Tony wrote:
> Forwarding from an initial email this morning.
>
> ___
>
> Good Morning,
>
> I have been referred to this team in an attempt to have some questions 
> answered.  Before I ask those question let me provide a little background on 
> how I got to this point.
>
> Vulnerability scans showed that two of my servers in the DMZ came back with 
> CVE-2019-10072 vulnerability.  The CVE information is below:
>
> The fix for CVE-2019-0199 was incomplete and did not address HTTP/2
> connection window exhaustion on write in Apache Tomcat versions
> 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE
> messages for the connection window (stream 0) clients were able to
> cause server-side threads to block eventually leading to thread
> exhaustion and a DoS.
> (CVE-2019-10072 9-10072>)
>
> The question I have is based on the server.xml configuring the connector and 
> protocols used.  Below are both of my servers server.xml connector entries:
> Server6:  protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> Server5:  protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> What I have highlighted are the protocols that are used for those specific 
> connectors on the servers.
>
> So, my question is in your professional opinions, if I'm not calling the 
> http2 protocol in any connector, my servers shouldn't be susceptible to the 
> particular CVE's vulnerability assessment.
>
> Please let me know if this question can be answered.

If you don't have



nested in a Connector anywhere in your server.xml that you can't possibly be 
vulnerable to HTTP/2 related vulnerabilities.

Looks like it is time to start shopping for a new vulnerability scanner.

Mark

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

This email message (including all attachments) is for the sole use of the 
intended recipient(s) and may contain confidential and/or privileged 
information, or may otherwise be protected by work product or other legal 
rules. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message. Unless otherwise 
indicated in the body of this email, nothing in this communication is intended 
to operate as an electronic signature and this transmission cannot be used to 
form, document, or authenticate a contract. Wyndham Destinations, Inc., and/or 
its affiliates may monitor all incoming and outgoing email communications, 
including the content of emails and attachments, for security, legal 
compliance, training, quality assurance and other purposes. The sender believes 
that this email and any attachments were free of any virus, worm, Trojan horse, 
malicious code and/or other contaminants when sent. Email transmissions cannot 
be guaranteed to be secure or error-free, so this message and its attachments 
could have been infected, corrupted or made incomplete during transmission. By 
reading the message and opening any attachments, the recipient accepts full 
responsibility for any viruses or other defects that may arise, and for taking 
remedial action relating to such viruses and other defects. Neither Wyndham 
Destinations, Inc., nor any of its affiliated entities is liable for any loss 
or damage arising in any way from, or for errors or omissions in the contents 
of, this message or its attachments.

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

Re: FW: Apache Vulnerability - Understanding Connector Protocols

[Mark Thomas]

On 01/08/2019 19:49, Justiniano, Tony wrote:
> Forwarding from an initial email this morning.
> 
> ___
> 
> Good Morning,
> 
> I have been referred to this team in an attempt to have some questions 
> answered.  Before I ask those question let me provide a little background on 
> how I got to this point.
> 
> Vulnerability scans showed that two of my servers in the DMZ came back with 
> CVE-2019-10072 vulnerability.  The CVE information is below:
> 
> The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 
> connection window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 
> 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the 
> connection window (stream 0) clients were able to cause server-side threads 
> to block eventually leading to thread exhaustion and a DoS. 
> (CVE-2019-10072)
> 
> The question I have is based on the server.xml configuring the connector and 
> protocols used.  Below are both of my servers server.xml connector entries:
> Server6:  protocol="org.apache.coyote.http11.Http11NioProtocol"
> 
> Server5:  protocol="org.apache.coyote.http11.Http11NioProtocol"
> 
> What I have highlighted are the protocols that are used for those specific 
> connectors on the servers.
> 
> So, my question is in your professional opinions, if I'm not calling the 
> http2 protocol in any connector, my servers shouldn't be susceptible to the 
> particular CVE's vulnerability assessment.
> 
> Please let me know if this question can be answered.

If you don't have



nested in a Connector anywhere in your server.xml that you can't
possibly be vulnerable to HTTP/2 related vulnerabilities.

Looks like it is time to start shopping for a new vulnerability scanner.

Mark

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

FW: Apache Vulnerability - Understanding Connector Protocols

[Justiniano, Tony]

Forwarding from an initial email this morning.

___

Good Morning,

I have been referred to this team in an attempt to have some questions 
answered.  Before I ask those question let me provide a little background on 
how I got to this point.

Vulnerability scans showed that two of my servers in the DMZ came back with 
CVE-2019-10072 vulnerability.  The CVE information is below:

The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection 
window exhaustion on write in Apache Tomcat versions 9.0.0.M1 to 9.0.19 and 
8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE messages for the connection 
window (stream 0) clients were able to cause server-side threads to block 
eventually leading to thread exhaustion and a DoS. 
(CVE-2019-10072)

The question I have is based on the server.xml configuring the connector and 
protocols used.  Below are both of my servers server.xml connector entries:
Server6: 

Re: Invalid HTTP Header - attack?

[Michael Osipov]

Am 2019-08-01 um 20:36 schrieb Mark Thomas:

On 01/08/2019 19:08, John Dale wrote:

I'm getting this in my logs - is this an attack do you think?


Unlikely to be an attack. Most likely a broken client.


There is another scenario:

Regular security scans on all corporate subnets from sec dept. I have 
these almost every day in access.log and via SSH.


Ask your network department who's IP this is and you should get better 
information.


See also: https://bz.apache.org/bugzilla/show_bug.cgi?id=55372

Michael

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

Re: Invalid HTTP Header - attack?

[Mark Thomas]

On 01/08/2019 19:08, John Dale wrote:
> I'm getting this in my logs - is this an attack do you think?

Unlikely to be an attack. Most likely a broken client.

>  How
> might I determine this?

debug logging for org.apache.coyote.http11.Http11InputBuffer is going to
log the request line and HTTP headers for every request.

tcpdump / wireshark is another option.

> Could this be pushing bytes to the handler and causing a memory issue?

No.

Mark


> 
> Error parsing HTTP request header
> Aug  1 17:37:58 dom1 tomcat9[9793]:  Note: further occurrences of HTTP
> request parsing errors will be logged at DEBUG level.
> Aug  1 17:37:58 dom1 tomcat9[9793]:
> java.lang.IllegalArgumentException: Invalid character found in the
> HTTP protocol
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:531)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> Aug  1 17:37:58 dom1 tomcat9[9793]: at 
> java.lang.Thread.run(Thread.java:748)
> 
> -
> 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: how to enable OCSP for Tomcat w OpenSSL

[Alex O'Ree]

This thread was super useful. thanks for sharing

On Wed, Apr 17, 2019 at 3:29 PM John Palmer  wrote:

> I'm still struggling with getting APR/OpenSSL to do the OCSP check.
>
> I'd appreciate some tips:
> versions: Java 8 (1.8.0_202), 64-bit, tomcat 8.5.38, APR 1.2.21
> using APR/OpenSSL (the tc-native-1.dll binary for Windows, compiled w OCSP
> support - the X64 dll from
> tomcat-native-1.2.21-openssl-1.1.1a-ocsp-win32-bin.zip)
>
> I can't get certificate revocation checking, specifically OCSP to happen
> from the APR/OpenSSL code;
> it seems to be happening instead from the Java (JSSE) code instead.
>
> I suspect a logic error is setting the OpenSSL revocation configuration
> (callback?) code to be set, then reset with the JSSE revocation
> configuration (due to the Catlina log excerpts shown below).
> I've tried following the APR initialization logic in the tomcat 8.5.35
> source, (but I get lost)...
> OpenSSLContext.java has
> SSLContext.setCertVerifyCallback()
> I suspect this is getting called correctly, then getting stepped on by the
> JSSE configuration being called (when it should be skipped).
>
> But I may just have something misconfigured.
>
>
> steps to reproduce:
>
> First, get Java revocation checking working without tc-native:
> UNcomment ocsp.enable=true in the Java\jre\lib\security\java.security file
> add
> revocationEnabled="true"
> certificateVerification="require"
> to the SSLHostConfig / Connector section of the server.xml config file.
>
>
> add -Djava.security.debug="certpath" to the Tomcat Java options (shows the
> JSSE cert validation - including OCSP if any - in the std-err log)
> or
> -Djava.security.debug="certpath ocsp"  (adds hexdumps of the OCSP REQUEST
> and RESPONSE. Generally not needed)
> (add -Djavax.net.ssl.trustStore=NONE to prevent the default truststore from
> being loaded - just because it clutters the std-out log)
>
> added to loggin.properties to see some of what Tomcat is logging:
> org.apache.tomcat.util.net.openssl.level=ALL
> org.apache.tomcat.util.net.level=ALL
> org.apache.tomcat.jni.level=ALL
>
> Restart tomcat,
> access via a browser with an appropriate cert (or OpenSSL or other client
> with options to send a client cert).
>
> You now can see JSSE doing OCSP checks in the (tocat)stderr logs (wireshark
> confirms this).
>
> stop tomcat, copy the tc-native-1.dll compiled with OCSP support, restart
> tomcat...
> access via browser (or client) with a cert etc...
>
> You'll see the tomcat stderr logs show that JSSE is STILL doing the OCSP
> checks.
>
> Catalina and stdout logs show that APR/OpenSSL is loading the server and
> trusted certs, doing the SSL handshakes etc, but not the certificate
> verification. this seems to be falling through to the JSSE certificate
> verification..
> (and that JSSE is ALSO loading the trusted certs (and the server cert, I
> think).
>
>
>
> the Catlina log shows that the APR/OpenSSL stuff is loading and configuring
> properly first:
>
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
> based Apache Tomcat Native library [1.2.21] using APR version [1.6.5].
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true].
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
> configuration: useAprConnector [false], useOpenSSL [true]
> org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized [OpenSSL 1.1.1a  20 Nov 2018]
> org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
> The ["https-openssl-nio2-A.B.C.D-443"] connector has been configured to
> support negotiation to [h2] via ALPN
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["https-openssl-nio2-A.B.C.D-443"]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [protocols] that are
> active are : [[TLSv1.3, TLSv1.2]]
> org.apache.tomcat.util.net
> .openssl.ciphers.OpenSSLCipherConfigurationParser.convertForJSSE
> jsse.openssl.effectiveCiphers
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled The [ciphers] that are
> active are : [[TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
> TLS_ECDHE_ECDSA_WITH_AES_256_CCM, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_PSK_DHE_WITH_AES_256_CCM_8, TLS_DHE_PSK_WITH_AES_256_CCM,
> TLS_DHE_RSA_WITH_AES_256_CCM_8, TLS_DHE_RSA_WITH_AES_256_CCM,
> TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
> TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA, TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,
> TLS_SRP_SHA_WITH_AES_256_CBC_SHA, TLS_AES_256_GCM_SHA384,
> TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_AES_256_CBC_SHA384,
> TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384,
> 

Invalid HTTP Header - attack?

[John Dale]

I'm getting this in my logs - is this an attack do you think?  How
might I determine this?

Could this be pushing bytes to the handler and causing a memory issue?

Error parsing HTTP request header
Aug  1 17:37:58 dom1 tomcat9[9793]:  Note: further occurrences of HTTP
request parsing errors will be logged at DEBUG level.
Aug  1 17:37:58 dom1 tomcat9[9793]:
java.lang.IllegalArgumentException: Invalid character found in the
HTTP protocol
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:531)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
Aug  1 17:37:58 dom1 tomcat9[9793]: at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
Aug  1 17:37:58 dom1 tomcat9[9793]: at java.lang.Thread.run(Thread.java:748)

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

[ANN] Apache Tomcat 7.0.96 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.96.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.94.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Apache Tomcat website:
http://tomcat.apache.org

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Enjoy

The Apache Tomcat team

Re: Component working in Console not as Service

[tomcat]

On 01.08.2019 13:02, Potgieter, Carlo wrote:

On 31.07.2019 20:26, Potgieter, Carlo wrote:

On 31.07.2019 14:49, Mark Thomas wrote:

On 31/07/2019 13:03, Potgieter, Carlo wrote:



On 31/07/2019 12:48, Potgieter, Carlo wrote:

I was hoping to obtain some assistance. We have used a library to convert MS 
Office documents (docx and pptx) to PDF.

This works perfectly in the development environment and also when running 
Tomcat in a console window.

The moment we run Tomcat as a service this specific component gives and error. 
Unfortunately the error is non-specific so we cannot troubleshoot the origin.

My question is, what would be the difference in running Tomcat as a Service as 
oppose to running it in Console that might cause this problem?


Tomcat runs as a different user with different access permissions, particularly 
to network shares.

You probably want to set up a Tomcat specific user with the appropriate 
permissions.

Mark

Thank you Mark for the quick response.

My first thought was permissions also, however I have attempted to run it with 
local, domain and system user, however the same result.

Both local and domain user was part of the local admin group. Is there anything 
else I can check?


Are you sure the DDL is being loaded? That normally needs explicit
configuration to point the JVM at the right path.

Look at the docs for for
org.apache.catalina.startup.VersionLoggerListener and configure it to
dump everything. Then compare the console start with the service start.



What is also different when Tomcat runs as a Service or in a console, is where 
the JVM that runs tomcat, picks up its environment and command-line switches.
If you are not familiar with this matter, this may help :
verbose explanation :
https://secure-web.cisco.com/16LxnNI0vUhSt5WCJq8xkkulFgI8kkE6jU6nNTTWH
8Edc36MeIASjeU6nUbSA_zE1ivz6c5TGLRI5-1Pf6_zuQkUOEaw8utUuFpuUnCrCLIeiS7
dhXxvll2giIW3fHOBe1_gpGzPiGufx1vE50Dzs9UUSm5Rc1iB9G9UILBUZ6dhLaGa3vAEU
t8bmVvfaGcwlM8tmxid6q8PydRkxPkVHu_02IIO1w4c2yyYp4O9vhwKqUq1OeApnpAj1c0
e2G-t0fT-lxYS5ofL92-i2ZpXEQk9bpTnCXLs0bT0wnFZYQsrFJZ8GQQckDdY-8eBWc946
XK9enjcTwIMehHfk013zuw/https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fd
isplay%2FTOMCAT%2FWindows#Windows-Q11
Official page :
https://secure-web.cisco.com/1BYhcwXb2ofGRuNXu8K-JZBV4sFyWUkMe0XaNSYXc
ey93JyiAhWVVK1zM0iJzrwal62xEQvv7bWZTbZIMuGTP_S_2qZdoXT4tLt78CPHzpOJND9
6h28X7R95_fnapxZO1zDvqNUPkrh23BUmyvnfKvqfef2panME2Z0l8GOvPAP4lZdyaSwgc
D0L2TM7oClsAQ4TPAeM8hVEtWCsJsoeQjwh7m4IHyvpPDfPDJ28gRGkBoLQWETM9alb7RH
jMtvclQ7-lMp3IYS9kOzQBDVHACmGkdIqgx-XAWNBjM6Wce6IoYmAeiwIgYmPZ0oClxsov
Fcb1-dH06wAs3t938YQVvw/https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-do
c%2Fwindows-service-howto.html

(Perhaps the application expects some value to be set somewhere..)

Also, above you mention "Unfortunately the error is non-specific..", but maybe 
you want to copy the error message here, so that someone else can have a look at it ?
Maybe it triggers some recognition by another user having had the same issue 
with that library.


Quickly answering both posts from Mark and Andrei:

Mark: Yes, the DLL is being loaded. There is error handling in place should it 
be unsuccessful in accessing any of the components.
I also compared the output of the VersionLoggerListners:
When running as a service and executing the Tomcat8.exe from cmd the 
information is the same, however the functionality only works when the .exe is 
run from cmd.
When using the Startup.bat script to start the server there are three less 
entries and one extra:

Entries not included:
31-Jul-2019 19:34:37.398 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: exit
31-Jul-2019 19:34:37.399 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Xms128m
31-Jul-2019 19:34:37.399 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Xmx256m

Entry included but not in the other two:
31-Jul-2019 19:37:11.434 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djdk.tls.ephemeralDHKeySize=2048

Again using this method to run the server allows the functionality to work.

Andre: From what I could see, everything is loaded the same as all of them uses 
the sae JVM. Unless I missed something...which is entirely possible.
The zeonpadpdf we are using consists of 3 components, 2 .jar's and 1
.dll. zeonpadpdf.jar, jacob-1.18.jar, jacob-1.18-x64.dll The error we are receiving 
states: "Conversion error" and is generated from the zeonpadpdf.jar which 
handles the conversion from .docx to pdf.
This is also the error in the stack trace which doesn't provide much more 
information.
Based on what I could find in the zeonpadpdf.jar this is generic error message.

Hope that gives some more context.




1) I remember (from some time ago) that in the Services control panel, there was an 
option when defining a Service, like "Allow this service to interact with the 
desktop".
If you 

RE:Component working in Console not as Service

[Potgieter, Carlo]

On 31.07.2019 20:26, Potgieter, Carlo wrote:
> On 31.07.2019 14:49, Mark Thomas wrote:
>> On 31/07/2019 13:03, Potgieter, Carlo wrote:
>>>
>>>
>>> On 31/07/2019 12:48, Potgieter, Carlo wrote:
 I was hoping to obtain some assistance. We have used a library to convert 
 MS Office documents (docx and pptx) to PDF.

 This works perfectly in the development environment and also when running 
 Tomcat in a console window.

 The moment we run Tomcat as a service this specific component gives and 
 error. Unfortunately the error is non-specific so we cannot troubleshoot 
 the origin.

 My question is, what would be the difference in running Tomcat as a 
 Service as oppose to running it in Console that might cause this problem?
>>>
>>> Tomcat runs as a different user with different access permissions, 
>>> particularly to network shares.
>>>
>>> You probably want to set up a Tomcat specific user with the appropriate 
>>> permissions.
>>>
>>> Mark
>>>
>>> Thank you Mark for the quick response.
>>>
>>> My first thought was permissions also, however I have attempted to run it 
>>> with local, domain and system user, however the same result.
>>>
>>> Both local and domain user was part of the local admin group. Is there 
>>> anything else I can check?
>>
>> Are you sure the DDL is being loaded? That normally needs explicit
>> configuration to point the JVM at the right path.
>>
>> Look at the docs for for
>> org.apache.catalina.startup.VersionLoggerListener and configure it to
>> dump everything. Then compare the console start with the service start.
>>
>
> What is also different when Tomcat runs as a Service or in a console, is 
> where the JVM that runs tomcat, picks up its environment and command-line 
> switches.
> If you are not familiar with this matter, this may help :
> verbose explanation :
> https://secure-web.cisco.com/16LxnNI0vUhSt5WCJq8xkkulFgI8kkE6jU6nNTTWH
> 8Edc36MeIASjeU6nUbSA_zE1ivz6c5TGLRI5-1Pf6_zuQkUOEaw8utUuFpuUnCrCLIeiS7
> dhXxvll2giIW3fHOBe1_gpGzPiGufx1vE50Dzs9UUSm5Rc1iB9G9UILBUZ6dhLaGa3vAEU
> t8bmVvfaGcwlM8tmxid6q8PydRkxPkVHu_02IIO1w4c2yyYp4O9vhwKqUq1OeApnpAj1c0
> e2G-t0fT-lxYS5ofL92-i2ZpXEQk9bpTnCXLs0bT0wnFZYQsrFJZ8GQQckDdY-8eBWc946
> XK9enjcTwIMehHfk013zuw/https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fd
> isplay%2FTOMCAT%2FWindows#Windows-Q11
> Official page :
> https://secure-web.cisco.com/1BYhcwXb2ofGRuNXu8K-JZBV4sFyWUkMe0XaNSYXc
> ey93JyiAhWVVK1zM0iJzrwal62xEQvv7bWZTbZIMuGTP_S_2qZdoXT4tLt78CPHzpOJND9
> 6h28X7R95_fnapxZO1zDvqNUPkrh23BUmyvnfKvqfef2panME2Z0l8GOvPAP4lZdyaSwgc
> D0L2TM7oClsAQ4TPAeM8hVEtWCsJsoeQjwh7m4IHyvpPDfPDJ28gRGkBoLQWETM9alb7RH
> jMtvclQ7-lMp3IYS9kOzQBDVHACmGkdIqgx-XAWNBjM6Wce6IoYmAeiwIgYmPZ0oClxsov
> Fcb1-dH06wAs3t938YQVvw/https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.5-do
> c%2Fwindows-service-howto.html
>
> (Perhaps the application expects some value to be set somewhere..)
>
> Also, above you mention "Unfortunately the error is non-specific..", but 
> maybe you want to copy the error message here, so that someone else can have 
> a look at it ?
> Maybe it triggers some recognition by another user having had the same issue 
> with that library.
>
>
> Quickly answering both posts from Mark and Andrei:
>
> Mark: Yes, the DLL is being loaded. There is error handling in place should 
> it be unsuccessful in accessing any of the components.
> I also compared the output of the VersionLoggerListners:
> When running as a service and executing the Tomcat8.exe from cmd the 
> information is the same, however the functionality only works when the .exe 
> is run from cmd.
> When using the Startup.bat script to start the server there are three less 
> entries and one extra:
>
> Entries not included:
> 31-Jul-2019 19:34:37.398 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: exit
> 31-Jul-2019 19:34:37.399 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Xms128m
> 31-Jul-2019 19:34:37.399 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Xmx256m
>
> Entry included but not in the other two:
> 31-Jul-2019 19:37:11.434 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djdk.tls.ephemeralDHKeySize=2048
>
> Again using this method to run the server allows the functionality to work.
>
> Andre: From what I could see, everything is loaded the same as all of them 
> uses the sae JVM. Unless I missed something...which is entirely possible.
> The zeonpadpdf we are using consists of 3 components, 2 .jar's and 1
> .dll. zeonpadpdf.jar, jacob-1.18.jar, jacob-1.18-x64.dll The error we are 
> receiving states: "Conversion error" and is generated from the zeonpadpdf.jar 
> which handles the conversion from .docx to pdf.
> This is also the error in the stack trace which doesn't provide much more 
> information.
> Based on what I could find in the zeonpadpdf.jar this is generic error 
>