Re: Tomcat Large Payload Truncated
Hi Mark, Thank you for responding. I have one more question. This is spring-boot 2 application REST API server and it does not accept Cookie or session (timeout is set to zero).Auth happens through Authorized header. We have set 10mb for maxPostSize. Does maxSavePostSize takes precedence over maxPostSize ? I will set maxSavePostSize to -1 to disable it. Also, I have another question. When Payload is as large as 10mb (json post), does payload body in JVM MEMORY or offloaded to FileInputStream ? Thanks, a lot for your help! Thanks, Bhavesh
Re: Tomcat 9.0.36 - JDK 13/14
Hi Mark, It does not log any errors. Just reverted back to the JDK1.8 version and tried to recreate the issue. I can recreate it. I had a doubt that the logging configuration might have messed up, so had to create a sample war file to check this. Anyone can try this and see if it works for them. Just build a simple spring boot app with jdk 13/14 and deploy it on the latest tomcat running on jdk 1.8. Maybe something is messed up in my environment. Here is console catalina.out log along with same use case classes from spring site. 29-Jun-2020 20:19:24.852 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.36 29-Jun-2020 20:19:24.854 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Jun 3 2020 17:07:09 UTC 29-Jun-2020 20:19:24.854 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.36.0 29-Jun-2020 20:19:24.854 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Windows 10 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 10.0 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: C:\Program Files\Java\jdk1.8.0_221\jre 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_221-b11 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36 29-Jun-2020 20:19:24.855 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36 29-Jun-2020 20:19:24.856 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36\conf\logging.properties 29-Jun-2020 20:19:24.856 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 29-Jun-2020 20:19:24.857 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 29-Jun-2020 20:19:24.857 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources 29-Jun-2020 20:19:24.857 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs= 29-Jun-2020 20:19:24.857 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36 29-Jun-2020 20:19:24.857 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36 29-Jun-2020 20:19:24.858 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=C:\Program Files\Apache Software Foundation\apache-tomcat-9.0.36\temp 29-Jun-2020 20:19:24.860 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache Tomcat Native library which allows using OpenSSL was not found on the java.library.path: [C:\Program Files\Java\jdk1.8.0_221\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Python38\Scripts\;C:\Python38\;C:\app\oracle\product\12.2.0\dbhome_1\bin;C:\Python27\;C:\Python27\Scripts;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Apache Software Foundation\apache-maven-3.3.9\bin;C:\Program Files\Java\jdk1.8.0_121;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;C:\Program Files (x86)\Calibre2\;C:\WINDOWS\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;C:\Program Files\AdoptOpenJDK\jdk8u192-b12\bin;C:\Program Files\Java\jdk1.8.0_221\bin;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Android\android-sdk\tools\bin;C:\Program Files\dotnet\;C:\Users\KIRAN\AppData\Local\Microsoft\WindowsApps;C:\Users\KIRAN\AppData\Local\Programs\Fiddler;C:\Users\KIRAN\AppData\Local\Microsoft\WindowsApps;C:\Program Files\JetBrains\IntelliJ IDEA 2019.1\bin;C:\Users\KIRAN\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\KIRAN\Ap;C:\Program Files\nodejs\;C:\Users\KIRAN\scoop\shims;C:\Users\KIRAN\AppData\Local\Microsoft\WindowsApps;;C:\Users\KIRAN\AppData\Local\Programs\Fiddler;C:\Users\KIRAN\AppData\Local\Microsoft\WindowsApps;C:\Program
Re: Tomcat 9.0.36 - JDK 13/14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 6/26/20 22:01, Kiran Badi wrote: > we fixed the issue Mark. > > Actually tomcat was running on JDK 1.8 and applications were built > using JDK 13/14.So when they were deployed to tomcat running with > 1.8, they were giving 404. > > Now plan is to explore and upgrade tomcat to at least jdk 13. > > It would have been nice really to have at least some error saying > major.minor version exception or something like that in some logs > somewhere which java often throws in these cases. > > Any ways we are good to go now. Thanks for your reply. My experience is that mismatched .class file versions do just that: they result in errors being logged to stdout / catalina.out. Perhaps you have a logging configuration which disables that? - -chris > On Fri, Jun 26, 2020 at 6:34 AM Mark Thomas > wrote: > >> On 26/06/2020 05:45, Kiran Badi wrote: >>> Hi All, >>> >>> I wanted to check if tomcat 9.0.36 supports open jdk 13/14. >> >> Supported Java versions are listed at: >> http://tomcat.apache.org/whichversion.html >> >> "Java 8 and later" includes Java 13 and Java 14. >> >>> I created a simple spring boot war file and compiled/built it >>> with >> openjdk >>> 13/14. After running maven install , I deployed the war file >>> from the target directory to tomcat webapps using tomcat >>> manager. It did not work and gave me 404 messages with both >>> 13/14. No error or any exception anywhere in logs.Catalina log >>> just says a war file is deployed. >> >> That is normally indicative of a configuration error. >> >>> Then i compiled the same spring boot app with jdk 8 and >>> deployed it with tomcat and it works fine. I am able to call my >>> endpoints with no issues. >>> >>> I am having a hard time deploying angular/spring boot and >>> building war >> file >>> and deploying it on tomcat 9.0x with openjdk 13. So I thought >>> this might >> be >>> a good place to start with. >> >> If you can provide the code you use to create the sample, e.g. as >> a GitHub project somebody may be able to take a look. >> >> Mark >> >>> >>> I used the below pom file. >>> >>> >> xmlns="http://maven.apache.org/POM/4.0.0; xmlns:xsi=" >>> http://www.w3.org/2001/XMLSchema-instance; >>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 >>> https://maven.apache.org/xsd/maven-4.0.0.xsd;> >>> 4.0.0 >>> org.springframework.boot >>> spring-boot-starter-parent >>> 2.3.1.RELEASE >>> com.kiran >>> springwar >>> 1.0.2-SNAPSHOT war >>> springwar Sample project to deploy >>> war to tomcat >>> >>> 14 >>> >>> >>> org.springframework.boot >>> spring-boot-starter-web >>> >>> org.springframework.boot >>> spring-boot-starter-tomcat >>> provided >>> org.springframework.boot >>> spring-boot-starter-test >>> test >>> org.junit.vintage >>> junit-vintage-engine >>> >>> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76VcYACgkQHPApP6U8 pFg0hw//XS313bw+b+jfbe8cCRwz7DXCoR9DloQ+IgBWnaz+p/VgeMj7ZVOrXtzw cTyRKzWz5vxHg4aRkY71ONqKPgtPsOC1vR/Cw6r3BFYJ0asD0tlIvGniYJ0BWWeZ tMpQMwxE21LNNLGP5nK0nPUdrj1KdIjb1GhmAqEfSsF5nEtuwYRsfBWOqL+gPMja 4uxcIbXeq7PuyPvI6m5Nwv/dZ5uVxQZ8zc0FYZf5rURC2w6p01DyPwsfsiHn8Ldf d+6MdMF2zQLNxacRW2iqDvpgjgoZ57Dto4RkKHJzN5WktnO386/Podw7rGBdaZ8D vSqw+gF/Lp5wWP3QyQMshOvmUqdrcsI1qHIa+PIQOu0kS4SK39Bc8ccwHcCQorie jQSc83WNe3Ock4EUjsXAbaC4jHFYWA6ggn32HyaO7lHcMECwfBPxvXsntKE+hRxB 0n5aKfGWLGRDiGevKZXbPUjcAeOwM9knBeoyVXCvyPG7QJ1jymQtapA8vLIl5g/V tkazXroWb9edKS6SXs6WvbsHwnc6cm8Fvija7HAOIJGbTz0S26q6qyWew/He3MtT BabV0TTxexOAuiRWU1S0G4Gvm4ZGaRhRh/EQGvCpjUn+MlGVWC9hT8TpbSykW6wf 8vpSWpvAobydsq8YX//tymXn9Ab5ia85Ds0gbyaBOOK75+fez7A= =fzrm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thomas, On 6/27/20 05:52, Thomas Meyer wrote: > Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas > : >> On 27/06/2020 10:19, Thomas Meyer wrote: >>> Hi, >>> >>> A few questions regarding tomcat session replication: >> >> load-balancing and session replication are two separate parts of >> an overall clustering solution. >> >>> 1) is the jvmRoute attribute on Engine object necessary for >>> session >> replication to work correctly? >> >> No, but if you don't use it it places a number of restrictions on >> the web application behaviour and on the configuration of >> session replication. >> >> The limitations are: - you need to use the DeltaManager (which >> doesn't scale as well as the BackupManager); > > Yes, I'm using default DeltaManager as I will only have two pods > running Tomcat. > >> - any requests made by the client that depend on the session MUST >> be issued in series, not in parallel; and > > Not sure about this one, the app uses spring default security for > login. So need to check this one. This has more to do with how your web application itself works and less about your security framework. For example, if you have a web-1.0-style web application which is mostly user-driven GET and POST requests, then you are probably fine with the occasional user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event. But if you have a web-2.0 style websocket/AJAX/many-things-happening-at-once-style application, then you are probably going to have problems without sticky sessions. >> - the session Manager must be configured to update all the other >> nodes in the cluster BEFORE the current request returns to the >> client. > > How to do that? I did have a look at Manager/DeltaManager > attributes but didn't see something that looks like above setting. > Can you plea point me in the right direction? http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor mation This is done using channelSendOptions on the and mapSendOptions on the ReplicationValve. The default value is to be synchronous, which would be required, here. Synchronous means that the data is replicated before the response is completed to the client. You could also do asynchronous which would allow the request to complete and queue the replication for "later" (but probably pretty shortly thereafter). >>> 2) does session replication only work correctly with sticky >>> load >> balancer routing? >> >> No. It works quite happily without it. > > Good to know. You might want to use sticky-sessions anyway. >>> My setup is 1) load balancer without sticky session routing >>> into kubernetes 2) two pods running tomcat with cloud member >>> provider, which see and >> find each other >>> >>> No jvmRoute attribute is set. > > Another question regarding jvmRoute: Even if my load balancer has > no sticky sessions, should I add jvmRoute attribute? I think I > could easily add the pod's name as jvmRoute. If it's no particular trouble, I would: 1. Add jvmRoute 2. Enable sticky sessions #2 just means that all requests for an session-holding client will be directed to a single Tomcat node. If fail-over is necessary, the other node will have the session-information that was last sent successfully and should be relatively up-to-date. The session-id will be changed upon fail-over and the user shouldn't really notice unless some replication message was lost. IMHO the only potential downside to non-sticky-sessions is that it's possible for one of your nodes to "collect" more users than the others and give you a lop-sided load-profile across your nodes. Unless that's a particular concern for you (and, for most applications, it's not a problem at all), I would enable sticky-sessions because it avoids a lot of race-conditions and other performance-related issues with cluster s. This isn't Tomcat-specific: it's just the nature of the beast. >>> Above setup doesn't work and give strange errors for the >>> distributed >> webapp which relies on http sessions. >>> >>> Should above setup work? If not why and what do I need to fix? >>> >>> Any hints of what logging to enable to debug the problem if any >>> at >> all? >> >> Please show us how you have configured the session manager and >> clustering. > > My setup is just go with the defaults: > > > className="org.apache.catalina.tribes.group.GroupChannel"> > className="org.apache.catalina.tribes.membership.cloud.CloudMembership Service" > > membershipProviderClassName="org.apache.catalina.tribes.membership.cloud .DNSMembershipProvider"/> > So pretty much default-everything (except maybe the CloudMembership). > In the logs I can see the member appears/disappears messages, which > is a good thing I guess. It is! Unless you can think of a particular reason NOT to enable sticky-sessions, I'd go ahead and do it. Remember that your reverse-proxy needs to understand how to handle session stickiness, though. What are you using for
Re: Tomcat session replication
Am 29. Juni 2020 22:54:12 MESZ schrieb Christopher Schultz : >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Thomas, Hi, > >On 6/27/20 05:52, Thomas Meyer wrote: >> Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas >> : >>> On 27/06/2020 10:19, Thomas Meyer wrote: Hi, A few questions regarding tomcat session replication: >>> >>> load-balancing and session replication are two separate parts of >>> an overall clustering solution. >>> 1) is the jvmRoute attribute on Engine object necessary for session >>> replication to work correctly? >>> >>> No, but if you don't use it it places a number of restrictions on >>> the web application behaviour and on the configuration of >>> session replication. >>> >>> The limitations are: - you need to use the DeltaManager (which >>> doesn't scale as well as the BackupManager); >> >> Yes, I'm using default DeltaManager as I will only have two pods >> running Tomcat. >> >>> - any requests made by the client that depend on the session MUST >>> be issued in series, not in parallel; and >> >> Not sure about this one, the app uses spring default security for >> login. So need to check this one. > >This has more to do with how your web application itself works and >less about your security framework. For example, if you have a >web-1.0-style web application which is mostly user-driven GET and POST >requests, then you are probably fine with the occasional >user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event. > >But if you have a web-2.0 style >websocket/AJAX/many-things-happening-at-once-style application, then >you are probably going to have problems without sticky sessions. Yes, okay understood. Webapp is a traditional request/reply jsp app. So nothing fancy going on. > >>> - the session Manager must be configured to update all the other >>> nodes in the cluster BEFORE the current request returns to the >>> client. >> >> How to do that? I did have a look at Manager/DeltaManager >> attributes but didn't see something that looks like above setting. >> Can you plea point me in the right direction? > >http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor >mation > >This is done using channelSendOptions on the and >mapSendOptions on the ReplicationValve. The default value is to be >synchronous, which would be required, here. Synchronous means that the >data is replicated before the response is completed to the client. You >could also do asynchronous which would allow the request to complete >and queue the replication for "later" (but probably pretty shortly >thereafter). Yes I also found out that simple tcp cluster had this option, but async is the default for some reason: https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java#L152 I tried ack and sync-ack but I still see "session not found errors". I'll check replication valve setting. In the meantime I also did enable tribes message logging, and tried to find out what goes wrong, but have not yet fully understand the problem. The error seems to happen in springs csrf filter which stores a uuid token in the http sessions. Also a change session id happens in between. Everything looks actually okay, but it doesn't work. > 2) does session replication only work correctly with sticky load >>> balancer routing? >>> >>> No. It works quite happily without it. >> >> Good to know. > >You might want to use sticky-sessions anyway. > My setup is 1) load balancer without sticky session routing into kubernetes 2) two pods running tomcat with cloud member provider, which see and >>> find each other No jvmRoute attribute is set. >> >> Another question regarding jvmRoute: Even if my load balancer has >> no sticky sessions, should I add jvmRoute attribute? I think I >> could easily add the pod's name as jvmRoute. > >If it's no particular trouble, I would: > >1. Add jvmRoute >2. Enable sticky sessions > >#2 just means that all requests for an session-holding client will be >directed to a single Tomcat node. If fail-over is necessary, the other >node will have the session-information that was last sent successfully >and should be relatively up-to-date. The session-id will be changed >upon fail-over and the user shouldn't really notice unless some >replication message was lost. > >IMHO the only potential downside to non-sticky-sessions is that it's >possible for one of your nodes to "collect" more users than the others >and give you a lop-sided load-profile across your nodes. Unless that's >a particular concern for you (and, for most applications, it's not a >problem at all), I would enable sticky-sessions because it avoids a >lot of race-conditions and other performance-related issues with >cluster >s. > >This isn't Tomcat-specific: it's just the nature of the beast. Okay. Above setup doesn't work and give strange errors for the distributed >>> webapp which relies on http sessions.
Re: Small patch for mod_proxy_ajp
Am 29. Juni 2020 22:13:10 MESZ schrieb Christopher Schultz : >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >All, > >IMO mod_proxy_balancer is missing an important feature, and that's the >ability to tell the back-end Tomcat node the current status of the >worke >r. Why would a tomcat Backend node want to have this information, what do you want to do? Can you give an example please. So when a node is disabled in mod proxy it won't receive any requests any more so how will this info reach the Backend Tomcat. What is your goal? > >I've filed an enhancement in Bugzilla >(https://bz.apache.org/bugzilla/show_bug.cgi?id=64338) for this and >attached a small patch. > >I'd love for anyone who is interested in this to: > >1. Try the patch >2. Try to get the status sent to Tomcat >3. Vote for the patch (if it works!) >4. Vote for back-port to 2.4.x branch > >Thanks! > >- -chris >-BEGIN PGP SIGNATURE- >Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > >iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76S1YACgkQHPApP6U8 >pFgXNxAAhEX5ND4dIwfAjfoXCI016Elt8o3zGMiNi2KYS9KSZ0L5c/GkU1sBMjNF >IcSHKzCTOiMC+IA/Z+2lS0pHi7ysAKgpnfklXcyneuEaY0/PpPpQ3MHtK7+v7VYA >floLy/qzFK8PnYwEWFiwFKq1HEDES2mXiltwHva0TEhMf+N8Pny81avsLjri8hMA >URHGW1+Pov101tf8pB0fxOz7Ts2iuytEEGFUAIz3ATq9VtStsXbhhZ1R4JFlj81o >l75pxyhh72P8ZztJF6M/yWDP8tV8UO0XTjs6kSzcFiKDt3dC43aO9zkhRFCj/kMY >gLylbQj8HJlv3r4+BZH0o+giVY/bmJ3ULQwFzxl/Bjj00UvK0PCan5DTIhhneBv+ >kTxcRUAZobP367QK3HWoQWsl0VMzrjBCxBaEXtVbW1fFqzw2gilg2GBok7RZe38p >Ehu0WHgKpV0hRKtwWwZaAsdADqLbwaRCnwtZafdY8RwaeSp3eVaDlPQTjKPQ+Vzf >XoTbh1SUKZQem77HBMpARMWNxp6bG22WhaZ+0aAuurs6mAzwAxuenjzjzlDC+nAS >G50IDbkW1ukU/tBJtuhoRk1F7mMopTYLB4bHKnoc2kmSUiQlWhvkOP6FEE6gz5Fh >osyvKMQfhtD9UcOktXTurNBpl6ZQNCxxZBdEMNr2kjv5QRtuKgA= >=h+2E >-END PGP SIGNATURE- > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to encrypt db password in tomcat context.xml
Hi Jürgen and Olaf,
I can really understand Jürgen's intentions. The core problem is not
security but administrators and so called security panels in
"professional" (non-open source related) companies. I really know this
from my own experiences. Maybe that's a German problem, since Germans
are said to be over-correct? Sometimes, that turns into paranoia...
(I'm from Germany, so I know this circumstances quite well, sounds
like Jürgen is German as well...)
True is, that there are administrators, which have very little
knowledge of software in general and security. Those tend to stick to
their personal categorical rules, which often are far off from what is
considered sensible by real IT and software professionals.
Furthermore, there are "security" panels, working out policies for a
company. These often only consist of people with very little *real* IT
an security knowledge.
The (sad) point is, that the policies passed by such a council are
actually valid and no one ever again asks whether these make sense or
are *correct* from a security professional's point of view. Changing
user passwords on a regular basis (e.g. after 90 days) still today is
one prominent example of that.
So, in order to make Tomcat fit into such "professional" company
environments easily (w/o requiring people to implement their own data
source class), it may be a good idea to add such a "encrypted
password" feature to Tomcat. Consider this as pure "syntactic sugar"
and keep in mind, that it's NOT a security feature (need to emphasis
that in the docs).
My idea is, that *all* passwords read by Tomcat MAY be
encrypted/obfuscated with a small number of algorithms. The algorithm
applied to the password could be prefixed like Jürgen suggested:
password="+duk6<7v@LD#"(plain, no encryption)
password="base64:K2R1azY8N3ZATEQj" (base64 obfuscation)
password="3des:hkph5ewjEwv70CvTB16v/w==" (3DES with hard-coded key,
expressed as base64 string)
The decoding algorithm could be implemented in a common util method
String decodePassword(String password) in Tomcat, so it could easily
be called from all those places at which Tomcat actually reads a
password.
Also, a small separate tool should be provided, which encodes such
passwords (like htpasswd does for httpd). However, it should be
sufficient to just print the encoded password to standard out. Then,
the user is responsible for copy and pasting it into the config file.
I offer my help for writing such an enhancement, since I believe that
it's a way to make Tomcat more out-of-the-box usable in such
"professional" company's environments (for some people it may be the
only way).
Again, I know this is NOT a security feature as it adds no extra
security to Tomcat. However, I may make some administrators and CEOs
happy, that are solely guided by questionable policies they don't
understand.
Some ideas on that?
Carsten
On 28.06.2020 23:49, Jürgen Weber wrote:
I'd just put some nice password as byte[] into Tomcat's source code
and provide a way to have passwords in the configs encrypted with that
nice password.
Use properties replacement so that in the xml config you have
${db.password} and in conf/catalina.properties you put the password
there.
So one could have samething like db.pass=3des: in
catalina.properties
Greetings, Juergen
Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock :
On 28.06.20 19:50, Jürgen Weber wrote:
I would like to know how to encrypt and decrypt the database
password in
context.xml when the application is running which also allow
me to change
the db password for the purpose of security.
>> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> Well, I know a chief open source app server that has the password to
> decrypt all passwords buried in its open source, and I know auditors
> who are good if root cannot read passwords at first sight. The
> reasoning behind that is that running java -jar someappserverlib.jar
> -decrypt is a deliberate act that a god guy root does not do. So a
> hidden password is a step better, even if not in the cryptographic
> sense.
Hi Jürgen,
I don't get your point here. Are you arguing that the linked wiki
article is incorrect, insufficient or invalid?
Because I believe that the article documents how to implement everything
that you describe on your own, and gives arguments for why this is not
implemented out of the box.
Best,
Olaf
-
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
--
--
Mit freundlichen Grüßen
Carsten Klein
mail: c.kl...@datagis.com [mailto:c.kl...@datagis.com]
Re: How to encrypt db password in tomcat context.xml
On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein wrote:
> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"(plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj" (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w==" (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>
The Tomcat committers' decision has always been to block inclusion of such
a feature, for the reasons explained in the wiki page here
https://cwiki.apache.org/confluence/display/TOMCAT/Password
As a result, your proposal will not be considered.
If you want a ready to use tool, go here:
https://github.com/web-servers/tomcat-vault
Rémy
>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with that
> > nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des: in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock >:
> >>
> >>
> >> On 28.06.20 19:50, Jürgen Weber wrote:
> >> I would like to know how to encrypt and decrypt the database
> >> password in
> >> context.xml when the application is running which also allow
> >> me to change
> >> the db password for the purpose of security.
> >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> >> > Well, I know a chief open source app server that has the password to
> >> > decrypt all passwords buried in its open source, and I know auditors
> >> > who are good if root cannot read passwords at first sight. The
> >> > reasoning behind that is that running java -jar someappserverlib.jar
> >> > -decrypt is a deliberate act that a god guy root does not do. So a
> >> > hidden password is a step better, even if not in the cryptographic
> >> > sense.
> >>
> >> Hi Jürgen,
> >>
> >> I don't get your point here. Are you arguing that the linked wiki
> >> article is incorrect, insufficient or invalid?
> >>
> >> Because I believe that the article documents how to
Announcing ApacheCon @Home 2020
Hi, Apache enthusiast! (You’re receiving this because you’re subscribed to one or more dev or user mailing lists for an Apache Software Foundation project.) The ApacheCon Planners and the Apache Software Foundation are pleased to announce that ApacheCon @Home will be held online, September 29th through October 1st, 2020. We’ll be featuring content from dozens of our projects, as well as content about community, how Apache works, business models around Apache software, the legal aspects of open source, and many other topics. Full details about the event, and registration, is available at https://apachecon.com/acah2020 Due to the confusion around how and where this event was going to be held, and in order to open up to presenters from around the world who may previously have been unable or unwilling to travel, we’ve reopened the Call For Presentations until July 13th. Submit your talks today at https://acna2020.jamhosted.net/ We hope to see you at the event! Rich Bowen, VP Conferences, The Apache Software Foundation - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Connector issue
I am sorry, but any ideas how to approach this? I have eliminated the possibility that the client is dropping the connection so it must be something within IIS/Win. Switching to keep_alive=true and HSE_REQ_SEND_RESPONSE_HEADER_EX did not make a difference. In the logs, occasionally I see a variation: start_response::jk_isapi_plugin.c (1082): HSE_REQ_SEND_RESPONSE_HEADER_EX failed with error=1229 (0x04cd) one time there was iis_write::jk_isapi_plugin.c (1283): Vector write of chunk encoded response failed with 1229 (0x04cd) which means the send response headers succeeded before writing the chunk. The responses are generated in relatively good time so timeouts are ruled out... All things point to connID being dropped/invalid but I can put a finger on anything. The only thing I that pops on Google is an old post about having to adjust responseBufferLimit=0 in IIS that might cause those errors. I think I have ruled out external firewall/intermediary dropping the connection on the client side. I know they have FIPS enabled on the Windows side but I cannot imagine that would make a difference. Calls to other virtual directories under that site do not exhibit this behavior. Interestingly the same is observed under othe OSes (Windows Server 2012) procured with their scrips... Any help/ideas is much appreciated George -Original Message- From: George Stanchev Sent: Tuesday, June 23, 2020 10:31 AM To: Tomcat Users List Subject: RE: Tomcat Connector issue Thanks all for the responses. It is on AWS VM machine that I don't have access to. I've googed the crap of x57 but besides some Bugzilla report from Adobe that seemed unrelated nothing good comes out of Google. x57 as Mark said is bad parameter and it is a generic error meaning either the p->lpEcb->ConnID is invalid or something is wrong with the headers or their sizes. Also chunking is off so keep-alive is JK_FALSE. I can try to enable the chunking to see if I can fork the execution into the HSE_REQ_SEND_RESPONSE_HEADER_EX call on jk_isapi_plugin.c#1066 and if it would make a difference. The headers from TC on the 302 response are pretty vanilla and I cannot imagine headers+sizes are wrong which leaves p->lpEcb->ConnID. I have omitted the actual binary dump of the AJP message because it is from a customer and didn't want to disclose their hostname but I can obfuscate it and post it if we think it is related to the issue. For now forking into the _EX call is the only idea I have to explore... Asked to procur another VM image in case something is wrong with IIS but it is a problem for them... Any ideas on how to even approach this are much appreciated... George -Original Message- From: Mark Thomas Sent: Tuesday, June 23, 2020 9:42 AM To: users@tomcat.apache.org Subject: Re: Tomcat Connector issue On 23/06/2020 16:35, Christopher Schultz wrote: > > > On 6/23/20 11:32, Mark Thomas wrote: >> On 23/06/2020 16:20, Christopher Schultz wrote: >>> George, >>> >>> On 6/22/20 17:13, George Stanchev wrote: We are getting HSE_REQ_SEND_RESPONSE_HEADER failed with error=87 (0x0057) on a 302 redirect proxied by TC connector 1.2.46. >>> Windows error 0x0057 is ... "Cannot connect to printer"??? > >> Not sure where you found that. 0x57 is "Invalid Parameter" > > Yeah, it sounded weird. Searching Google for "windows 0x0057" (at > least here in the US) gives a million pages about errors connecting to > printers, like this one which is the top-hit for me with expanded > explanation: > > https://appuals.com/fix-printer-error-0x0057/ > > " > Error 0x0057 is a printer related error on Windows which does not > allow the user to add the printer. This error is usually due to > corrupt drivers previously installed and the permission issues. ... > The 1st one would delete the driver and the second method would be to > copy the driver from a working computer. > " > > I don't have a "perror" program for Windows handy right now, so I just > tried Google :/ For the archives: https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@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: How to encrypt db password in tomcat context.xml
I've written my own vadmin.sh and a vadmin.exe file to take the place of the vault.sh/vault.bat file, just to make things easier here. Just starting testing with some of our app teams before determining if we will move forward with it or not. Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Pesonen, Harri Sent: Monday, June 29, 2020 10:10 AM To: Tomcat Users List Subject: RE: How to encrypt db password in tomcat context.xml I have implemented a Tomcat vault as well, it is basically a simplified version of https://github.com/web-servers/tomcat-vault My version does not have keystore, so it is much easier to use. It would be great if Tomcat would have this functionality built-in somehow. -Harri -Original Message- From: jonmcalexan...@wellsfargo.com.INVALID Sent: maanantai 29. kesäkuuta 2020 17.25 To: users@tomcat.apache.org Subject: RE: How to encrypt db password in tomcat context.xml -Original Message- From: Rémy Maucherat Sent: Monday, June 29, 2020 1:58 AM To: Tomcat Users List Subject: Re: How to encrypt db password in tomcat context.xml On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein wrote: > Hi Jürgen and Olaf, > > I can really understand Jürgen's intentions. The core problem is not > security but administrators and so called security panels in > "professional" (non-open source related) companies. I really know this > from my own experiences. Maybe that's a German problem, since Germans > are said to be over-correct? Sometimes, that turns into paranoia... > (I'm from Germany, so I know this circumstances quite well, sounds > like Jürgen is German as well...) > > True is, that there are administrators, which have very little > knowledge of software in general and security. Those tend to stick to > their personal categorical rules, which often are far off from what is > considered sensible by real IT and software professionals. > Furthermore, there are "security" panels, working out policies for a > company. These often only consist of people with very little *real* IT > an security knowledge. > > The (sad) point is, that the policies passed by such a council are > actually valid and no one ever again asks whether these make sense or > are *correct* from a security professional's point of view. Changing > user passwords on a regular basis (e.g. after 90 days) still today is > one prominent example of that. > > So, in order to make Tomcat fit into such "professional" company > environments easily (w/o requiring people to implement their own data > source class), it may be a good idea to add such a "encrypted > password" feature to Tomcat. Consider this as pure "syntactic sugar" > and keep in mind, that it's NOT a security feature (need to emphasis > that in the docs). > > My idea is, that *all* passwords read by Tomcat MAY be > encrypted/obfuscated with a small number of algorithms. The algorithm > applied to the password could be prefixed like Jürgen suggested: > > password="+duk6<7v@LD#"(plain, no encryption) > password="base64:K2R1azY8N3ZATEQj" (base64 obfuscation) > password="3des:hkph5ewjEwv70CvTB16v/w==" (3DES with hard-coded key, > expressed as base64 string) > > The decoding algorithm could be implemented in a common util method > String decodePassword(String password) in Tomcat, so it could easily > be called from all those places at which Tomcat actually reads a > password. > > Also, a small separate tool should be provided, which encodes such > passwords (like htpasswd does for httpd). However, it should be > sufficient to just print the encoded password to standard out. Then, > the user is responsible for copy and pasting it into the config file. > > I offer my help for writing such an enhancement, since I believe that > it's a way to make Tomcat more out-of-the-box usable in such > "professional" company's environments (for some people it may be the > only way). > > Again, I know this is NOT a security feature as it adds no extra > security to Tomcat. However, I may make some administrators and CEOs > happy, that are solely guided by questionable policies they don't > understand. > > Some ideas on that? > > The Tomcat committers' decision has always been to block inclusion of > such a feature, for the
Re: AJP error using mod_proxy__ajp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I believe I have determined the cause (or at least the fix) for this: Despite the mod_proxy_ajp documentation, it is using packets larger than 8192 bytes. Setting this on the Tomcat resolves the problem: packetSize="65536" I don't see anywhere you can set the maximum packet size on mod_proxy_ajp so I think this is the only recourse. Is anyone familiar enough with the mod_proxy_ajp code to know how to look for this? It was trivial to reproduce: just send a large POST message through mod_proxy_ajp to Tomcat. Thanks, - -chris On 6/25/20 10:28, Christopher Schultz wrote: > All, > > This issue is apparently trivially reproducible in my dev > environment. > > Do I have to get a protocol-trace to get any more helpful > information? > > Thanks, -chris > > On 6/24/20 10:46, Christopher Schultz wrote: >> All, > >> On 6/24/20 10:29, Christopher Schultz wrote: >>> All, > >>> I'm slowly switching from mod_jk to mod_proxy_ajp and I have a >>> development environment where I'm getting Bad Gateway >>> responses sent to clients along with this exception in my >>> Tomcat log file: > >>> java.lang.IllegalArgumentException: Header message of length >>> [8,194] received but the packetSize is only [8,192] at >>> org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:685 ) > >>> >>> > >> at >>> org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:626) >>> >>> > >>> at >>> org.apache.coyote.ajp.AjpProcessor.refillReadBuffer(AjpProcessor.jav a > >>> : > >>> > 73 > > >> 4) >>> at >>> org.apache.coyote.ajp.AjpProcessor$SocketInputBuffer.doRead(AjpProce s > >>> s > >>> > or > > >> .java:1456) >>> at org.apache.coyote.Request.doRead(Request.java:581) at >>> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer. j > >>> a > >>> > va > > >> :344) >>> at >>> org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBu f > >>> f > >>> > er > > >> .java:663) >>> at >>> org.apache.catalina.connector.InputBuffer.readByte(InputBuffer.java: 3 > >>> 5 > >>> > 8) > > >> at >>> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStre a > >>> m > >>> > .j > > >> ava:93) >>> at >>> org.apache.commons.io.input.ProxyInputStream.read(ProxyInputStream.j a > >>> v > >>> > a: > > >> 53) >>> at >>> org.apache.commons.io.input.TeeInputStream.read(TeeInputStream.java: 1 > >>> 0 > >>> > 6) > > >> at java.io.FilterInputStream.read(FilterInputStream.java:83) >>> at my.product.MacInputStream.read(MacInputStream.java:29) at >>> java.io.FilterInputStream.read(FilterInputStream.java:83) at >>> com.sun.org.apache.xerces.internal.impl.XMLEntityManager$RewindableI n > >>> p > >>> > ut > > >> Stream.read(XMLEntityManager.java:2890) >>> at >>> com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurren t > >>> E > >>> > nt > > >> ity(XMLEntityManager.java:674) >>> at >>> com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determine D > >>> o > >>> > cV > > >> ersion(XMLVersionDetector.java:148) >>> at >>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( X > >>> M > >>> > L1 > > >> 1Configuration.java:806) >>> at >>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( X > >>> M > >>> > L1 > > >> 1Configuration.java:771) >>> at >>> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser . > >>> j > >>> > av > > >> a:141) >>> at >>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(A b > >>> s > >>> > tr > > >> actSAXParser.java:1213) >>> at >>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser. p > >>> a > >>> > rs > > >> e(SAXParserImpl.java:643) >>> at >>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParse r > >>> I > >>> > mp > > >> l.java:327) >>> at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) > >>> This is a web service which is reading the request with a >>> SAXParser. It's been running in production (and dev!) for >>> years without any issues. It''s been running for a few months >>> in development, now, with mod_proxy_ajp without any errors. > >>> I know about the "max packet size" and the default is 8192 >>> bytes. I haven't changed the default. Here's my >>> configuration: > >>> >> secretRequired="false" redirectPort="443" protocol="AJP/1.3" >>> URIEncoding="UTF-8" executor="tomcatThreadPool" /> > >>> Here's the configuration in httpd.conf: > >>> BalancerMember >>> "ajp://localhost:8245" timeout=300 ping=5 ttl=60 > >>> ProxyPass "/my-api/" "balancer://my-api/my-api/" >>> ProxyPassReverse "/my-api/" "balancer://my-api/my-api/" > >>> The documentation for mod_proxy_ajp[1] seems to indicate that >>> the "Packet Size" for AJP is fixed at 8192 bytes: > >>> " Packet Size > >>> According to much of the code, the max packet size is 8 * 1024 >>> bytes (8K). The actual length of the packet is encoded in the >>> header. > >>> Packet Headers > >>> Packets sent from the server to the container begin with >>> 0x1234. Packets
RE: How to encrypt db password in tomcat context.xml
-Original Message-
From: Rémy Maucherat
Sent: Monday, June 29, 2020 1:58 AM
To: Tomcat Users List
Subject: Re: How to encrypt db password in tomcat context.xml
On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein wrote:
> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"(plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj" (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w==" (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>
> The Tomcat committers' decision has always been to block inclusion of such a
> feature, for the reasons explained in the wiki page
> here https://cwiki.apache.org/confluence/display/TOMCAT/Password
> As a result, your proposal will not be considered.
> If you want a ready to use tool, go here:
> https://github.com/web-servers/tomcat-vault
> Rémy
I have been working with the tomcat-vault and so far am finding it promising.
One caveat with this, is you can't set variables in the catalina.properties
that pull the values from the vault, it only works in xml files, so you have to
reference the vault item in server.xml, context.xml, etc.
>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with
> > that nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des: in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock
> > >:
> >>
> >>
> >> On 28.06.20 19:50, Jürgen Weber wrote:
> >> I would like to know how to encrypt and decrypt the database
> >> password in
> >> context.xml when the application is running which also allow
> >> me to change
> >> the db password for the purpose of security.
> >> >> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> >> > Well, I know a chief open source app server that has the password
> >> > to decrypt all passwords buried in its open source, and I know
> >> >
RE: How to encrypt db password in tomcat context.xml
I have implemented a Tomcat vault as well, it is basically a simplified version
of
https://github.com/web-servers/tomcat-vault
My version does not have keystore, so it is much easier to use.
It would be great if Tomcat would have this functionality built-in somehow.
-Harri
-Original Message-
From: jonmcalexan...@wellsfargo.com.INVALID
Sent: maanantai 29. kesäkuuta 2020 17.25
To: users@tomcat.apache.org
Subject: RE: How to encrypt db password in tomcat context.xml
-Original Message-
From: Rémy Maucherat
Sent: Monday, June 29, 2020 1:58 AM
To: Tomcat Users List
Subject: Re: How to encrypt db password in tomcat context.xml
On Mon, Jun 29, 2020 at 8:03 AM Carsten Klein wrote:
> Hi Jürgen and Olaf,
>
> I can really understand Jürgen's intentions. The core problem is not
> security but administrators and so called security panels in
> "professional" (non-open source related) companies. I really know this
> from my own experiences. Maybe that's a German problem, since Germans
> are said to be over-correct? Sometimes, that turns into paranoia...
> (I'm from Germany, so I know this circumstances quite well, sounds
> like Jürgen is German as well...)
>
> True is, that there are administrators, which have very little
> knowledge of software in general and security. Those tend to stick to
> their personal categorical rules, which often are far off from what is
> considered sensible by real IT and software professionals.
> Furthermore, there are "security" panels, working out policies for a
> company. These often only consist of people with very little *real* IT
> an security knowledge.
>
> The (sad) point is, that the policies passed by such a council are
> actually valid and no one ever again asks whether these make sense or
> are *correct* from a security professional's point of view. Changing
> user passwords on a regular basis (e.g. after 90 days) still today is
> one prominent example of that.
>
> So, in order to make Tomcat fit into such "professional" company
> environments easily (w/o requiring people to implement their own data
> source class), it may be a good idea to add such a "encrypted
> password" feature to Tomcat. Consider this as pure "syntactic sugar"
> and keep in mind, that it's NOT a security feature (need to emphasis
> that in the docs).
>
> My idea is, that *all* passwords read by Tomcat MAY be
> encrypted/obfuscated with a small number of algorithms. The algorithm
> applied to the password could be prefixed like Jürgen suggested:
>
> password="+duk6<7v@LD#"(plain, no encryption)
> password="base64:K2R1azY8N3ZATEQj" (base64 obfuscation)
> password="3des:hkph5ewjEwv70CvTB16v/w==" (3DES with hard-coded key,
> expressed as base64 string)
>
> The decoding algorithm could be implemented in a common util method
> String decodePassword(String password) in Tomcat, so it could easily
> be called from all those places at which Tomcat actually reads a
> password.
>
> Also, a small separate tool should be provided, which encodes such
> passwords (like htpasswd does for httpd). However, it should be
> sufficient to just print the encoded password to standard out. Then,
> the user is responsible for copy and pasting it into the config file.
>
> I offer my help for writing such an enhancement, since I believe that
> it's a way to make Tomcat more out-of-the-box usable in such
> "professional" company's environments (for some people it may be the
> only way).
>
> Again, I know this is NOT a security feature as it adds no extra
> security to Tomcat. However, I may make some administrators and CEOs
> happy, that are solely guided by questionable policies they don't
> understand.
>
> Some ideas on that?
>
> The Tomcat committers' decision has always been to block inclusion of such a
> feature, for the reasons explained in the wiki page
> here https://cwiki.apache.org/confluence/display/TOMCAT/Password
> As a result, your proposal will not be considered.
> If you want a ready to use tool, go here:
> https://github.com/web-servers/tomcat-vault
> Rémy
I have been working with the tomcat-vault and so far am finding it promising.
One caveat with this, is you can't set variables in the catalina.properties
that pull the values from the vault, it only works in xml files, so you have to
reference the vault item in server.xml, context.xml, etc.
>
> Carsten
>
>
> On 28.06.2020 23:49, Jürgen Weber wrote:
> > I'd just put some nice password as byte[] into Tomcat's source code
> > and provide a way to have passwords in the configs encrypted with
> > that nice password.
> >
> >> Use properties replacement so that in the xml config you have
> >> ${db.password} and in conf/catalina.properties you put the password
> >> there.
> >
> > So one could have samething like db.pass=3des: in
> > catalina.properties
> >
> > Greetings, Juergen
> >
> > Am So., 28. Juni 2020 um 21:19 Uhr schrieb Olaf Kock
> > >:
> >>
> >>
> >> On
Re: AJP error using mod_proxy__ajp (conclusion: user error)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 6/29/20 12:22, Christopher Schultz wrote: > I believe I have determined the cause (or at least the fix) for > this: > > Despite the mod_proxy_ajp documentation, it is using packets > larger than 8192 bytes. > > Setting this on the Tomcat resolves the problem: > > packetSize="65536" > > I don't see anywhere you can set the maximum packet size on > mod_proxy_ajp so I think this is the only recourse. That's because this is a property of mod_proxy and not mod_proxy_ajp. ProxyIOBufferSize [1] > Is anyone familiar enough with the mod_proxy_ajp code to know how > to look for this? > > It was trivial to reproduce: just send a large POST message > through mod_proxy_ajp to Tomcat. Evidently, I've been down this road before and I had *intentionally* set the high-water mark of ProxyIOBufferSize to 65535. So this was entirely self-inflicted. Thanks, - -chris [1] https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyiobuffersi ze > On 6/25/20 10:28, Christopher Schultz wrote: >> All, > >> This issue is apparently trivially reproducible in my dev >> environment. > >> Do I have to get a protocol-trace to get any more helpful >> information? > >> Thanks, -chris > >> On 6/24/20 10:46, Christopher Schultz wrote: >>> All, > >>> On 6/24/20 10:29, Christopher Schultz wrote: All, > I'm slowly switching from mod_jk to mod_proxy_ajp and I have a development environment where I'm getting Bad Gateway responses sent to clients along with this exception in my Tomcat log file: > java.lang.IllegalArgumentException: Header message of length [8,194] received but the packetSize is only [8,192] at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:68 5 > ) > > >>> at org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:626) > > at org.apache.coyote.ajp.AjpProcessor.refillReadBuffer(AjpProcessor.ja v > a > > : > >> 73 > > >>> 4) at org.apache.coyote.ajp.AjpProcessor$SocketInputBuffer.doRead(AjpProc e > s > > s > >> or > > >>> .java:1456) at org.apache.coyote.Request.doRead(Request.java:581) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer . > j > > a > >> va > > >>> :344) at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputB u > f > > f > >> er > > >>> .java:663) at org.apache.catalina.connector.InputBuffer.readByte(InputBuffer.java : > 3 > > 5 > >> 8) > > >>> at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStr e > a > > m > >> .j > > >>> ava:93) at org.apache.commons.io.input.ProxyInputStream.read(ProxyInputStream. j > a > > v > >> a: > > >>> 53) at org.apache.commons.io.input.TeeInputStream.read(TeeInputStream.java : > 1 > > 0 > >> 6) > > >>> at java.io.FilterInputStream.read(FilterInputStream.java:83) at my.product.MacInputStream.read(MacInputStream.java:29) at java.io.FilterInputStream.read(FilterInputStream.java:83) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager$Rewindable I > n > > p > >> ut > > >>> Stream.read(XMLEntityManager.java:2890) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurre n > t > > E > >> nt > > >>> ity(XMLEntityManager.java:674) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determin e > D > > o > >> cV > > >>> ersion(XMLVersionDetector.java:148) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse ( > X > > M > >> L1 > > >>> 1Configuration.java:806) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse ( > X > > M > >> L1 > > >>> 1Configuration.java:771) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParse r > . > > j > >> av > > >>> a:141) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse( A > b > > s > >> tr > > >>> actSAXParser.java:1213) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser . > p > > a > >> rs > > >>> e(SAXParserImpl.java:643) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXPars e > r > > I > >> mp > > >>> l.java:327) at javax.xml.parsers.SAXParser.parse(SAXParser.java:195) > This is a web service which is reading the request with a SAXParser. It's been running in production (and dev!) for years without any issues. It''s been running for a few months in development, now, with mod_proxy_ajp without any errors. > I know about the "max packet size" and the default is 8192 bytes. I haven't changed the default. Here's my configuration: > >>>
Small patch for mod_proxy_ajp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, IMO mod_proxy_balancer is missing an important feature, and that's the ability to tell the back-end Tomcat node the current status of the worke r. I've filed an enhancement in Bugzilla (https://bz.apache.org/bugzilla/show_bug.cgi?id=64338) for this and attached a small patch. I'd love for anyone who is interested in this to: 1. Try the patch 2. Try to get the status sent to Tomcat 3. Vote for the patch (if it works!) 4. Vote for back-port to 2.4.x branch Thanks! - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76S1YACgkQHPApP6U8 pFgXNxAAhEX5ND4dIwfAjfoXCI016Elt8o3zGMiNi2KYS9KSZ0L5c/GkU1sBMjNF IcSHKzCTOiMC+IA/Z+2lS0pHi7ysAKgpnfklXcyneuEaY0/PpPpQ3MHtK7+v7VYA floLy/qzFK8PnYwEWFiwFKq1HEDES2mXiltwHva0TEhMf+N8Pny81avsLjri8hMA URHGW1+Pov101tf8pB0fxOz7Ts2iuytEEGFUAIz3ATq9VtStsXbhhZ1R4JFlj81o l75pxyhh72P8ZztJF6M/yWDP8tV8UO0XTjs6kSzcFiKDt3dC43aO9zkhRFCj/kMY gLylbQj8HJlv3r4+BZH0o+giVY/bmJ3ULQwFzxl/Bjj00UvK0PCan5DTIhhneBv+ kTxcRUAZobP367QK3HWoQWsl0VMzrjBCxBaEXtVbW1fFqzw2gilg2GBok7RZe38p Ehu0WHgKpV0hRKtwWwZaAsdADqLbwaRCnwtZafdY8RwaeSp3eVaDlPQTjKPQ+Vzf XoTbh1SUKZQem77HBMpARMWNxp6bG22WhaZ+0aAuurs6mAzwAxuenjzjzlDC+nAS G50IDbkW1ukU/tBJtuhoRk1F7mMopTYLB4bHKnoc2kmSUiQlWhvkOP6FEE6gz5Fh osyvKMQfhtD9UcOktXTurNBpl6ZQNCxxZBdEMNr2kjv5QRtuKgA= =h+2E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 6/27/20 05:29, Mark Thomas wrote: > On 27/06/2020 10:19, Thomas Meyer wrote: >> Hi, >> >> A few questions regarding tomcat session replication: > > load-balancing and session replication are two separate parts of > an overall clustering solution. > >> 1) is the jvmRoute attribute on Engine object necessary for >> session replication to work correctly? > > No, but if you don't use it it places a number of restrictions on > the web application behaviour and on the configuration of session > replication. > > The limitations are: - you need to use the DeltaManager (which > doesn't scale as well as the BackupManager); - any requests made by > the client that depend on the session MUST be issued in series, not > in parallel; and This is only true of requests that would modify the session-state in a way that needed to be deterministic, right? A bunch of GET requests that don't change the session ought to be okay in parallel (as long as any prior state-changing requests have completed _ those changes replicated). > - the session Manager must be configured to update all the other > nodes in the cluster BEFORE the current request returns to the > client. Same (negative) caveat here, right? >> 2) does session replication only work correctly with sticky load >> balancer routing? > > No. It works quite happily without it. > >> >> My setup is 1) load balancer without sticky session routing into >> kubernetes 2) two pods running tomcat with cloud member provider, >> which see and find each other >> >> No jvmRoute attribute is set. >> >> Above setup doesn't work and give strange errors for the >> distributed webapp which relies on http sessions. >> >> Should above setup work? If not why and what do I need to fix? >> >> Any hints of what logging to enable to debug the problem if any >> at all? > > Please show us how you have configured the session manager and > clustering. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76UgcACgkQHPApP6U8 pFjoNQ//TbmZA3oh1ISz3ogBK9Txb/VH1qXnJ8+Y/uP0sjK45p88vd+hoqfAyQ98 8faqgN5/IuuYCnGPYlySGDfF2b2rfXL2umq5P62rjYnDBEsWulIix4dYxNLDqZF6 GeK7lKGXABAM+gJXxbyXELEwjnppP2qCYE+gSTzwJH3Jnz4UMj2oT9bjZjBp1jOy 7CaXY0VYnVqLZhbHwTmUC4A1eIQrzN+4Cag3FVoWE2oLUpi1/GK6iYmDJpy2owA/ 1kirT89sMqehaoTS02EnBfSusX9DN0qDmUK0ddxtv8jUiEz408+ujs5YPRuVG71z 5ISuymx9Sf8e9RA+TFNm252PIJWKtumi9uddG0As/FF4Qy+LMmY94RX+aXyBcQU9 r0A1nkX8/UmjqaUx61um2/t2PDfTBCDwl0ORat4ERHHc0vfQLYnvPYLZzKj/jNn6 guflkExS5qpwbiuvWFgvFiFTAi9Og5tF2ks+sqdb3PWoie2snStGKboivQKof4qb 7BStuSWVP1aeUieGn7fqCWhLlr9VSC0r2czEShkVde4TWC/cV5F38NfSGmbYssrQ 97zjbup6+/fL5MKmOaoDY2kOS1/XPzrB/BDK+d83w98cb03txezZCwtM2QPzn/48 1QvL3n3XMna31XHa8ljHldrX2c7bm2lpkhJPL5269pFznMRZOA4= =Lg+P -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
