Re: [EXTERNAL] Re: Tomcat(9.0.13) Error in DEV Server
Hi Gary, see way below inline... > Am 16.04.2019 um 03:02 schrieb Hua, Gary - Saint Louis, MO - Contractor > : > > Luis: > > Thanks for your input. I put the following into > conf/logging.properties and add debug="99" in the Realm definition so I > can see more Realm logging information: > > org.apache.catalina.realm.level = ALL > org.apache.catalina.realm.useParentHandlers = true > org.apache.catalina.authenticator.level = ALL > org.apache.catalina.authenticator.useParentHandlers = true > > >After the first login attempt in the application TOPS login screen, the > URL was redirected to https://eagnmnmed1f45:9443/TOPS-WEB/j_security_check > with invalid UID/PW message.Then I entered topsadmin/@88Topstopstops as > id/pd and clicked the Login button again, I got the following message in > the catalina.out: > > > 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.authenticator.AuthenticatorBase.invoke Security checking > request POST /TOPS-WEB/j_security_check > 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking > constraint 'SecurityConstraint[Entire Application]' against POST > /j_security_check --> true > 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking > constraint 'SecurityConstraint[Secure area's for TOPS_ADMIN user]' against > POST /j_security_check --> false > 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking > constraint 'SecurityConstraint[SecuredResource]' against POST > /j_security_check --> false > 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking > constraint 'SecurityConstraint[Entire Application]' against POST > /j_security_check --> true > 15-Apr-2019 17:08:17.690 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking > constraint 'SecurityConstraint[Secure area's for TOPS_ADMIN user]' against > POST /j_security_check --> false > 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.findSecurityConstraints Checking > constraint 'SecurityConstraint[SecuredResource]' against POST > /j_security_check --> false > 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling > hasUserDataPermission() > 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.RealmBase.hasUserDataPermission User data > constraint already satisfied > 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.authenticator.AuthenticatorBase.invoke Calling > authenticate() > 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.authenticator.FormAuthenticator.doAuthenticate > Authenticating username 'topsadmin' > 15-Apr-2019 17:08:17.691 FINE [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.CombinedRealm.authenticate Attempting to > authenticate user [topsadmin] with realm [org.apache.catalina.realm.JNDIRealm] > 15-Apr-2019 17:08:17.694 INFO [https-jsse-nio-9443-exec-7] > org.apache.catalina.realm.JNDIRealm.authenticate Exception performing > authentication. Retrying... > javax.naming.CommunicationException: Connection reset [Root exception is > java.net.SocketException: Connection reset]; That may be the reason!? It cannot connect and everything following is just bad error handling? > remaining name 'DC=devsub,DC=dev,DC=dce,DC=usps,DC=gov' >at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2002) >at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1844) >at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) >at > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) >at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) >at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) >at > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) >at > org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1675) >at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1510) >at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1458) >at > org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1403) >at > org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1285) >at > org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:188) >at > org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:153) >
Re: Has anybody ever heard of "ECDHE-ECDSA-CHACHA20-POLY1305"? was Re: TLS protocols and cipher suites
Hi James, > Am 18.03.2019 um 23:49 schrieb James H. H. Lampert : > > I've just (same customer as before) been asked about > ECDHE-ECDSA-CHACHA20-POLY1305 > and ECDHE-RSA-CHACHA20-POLY1305 > > and I can't find either one on the Sun or IBM JSSE cipher lists for Java 8. > Most certainly only >=Java9... (OpenJDK and Oracle, don’t know about IBM though) > -- > JHHL > > - > 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: Has anybody ever heard of "ECDHE-ECDSA-CHACHA20-POLY1305"? was Re: TLS protocols and cipher suites
Oh, and yes I’ve heard about them and used the RSA version! Peter > Am 18.03.2019 um 23:49 schrieb James H. H. Lampert : > > I've just (same customer as before) been asked about > ECDHE-ECDSA-CHACHA20-POLY1305 > and ECDHE-RSA-CHACHA20-POLY1305 > > and I can't find either one on the Sun or IBM JSSE cipher lists for Java 8. > > -- > JHHL > > - > 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: Http insecure headers
Nitin, sorry for my late reply. > Am 27.02.2019 um 17:01 schrieb Nitin Kadam : > > Hello , > > We dint have any reverse proxy in middle layers and we have added filters in > web.config only, Please find attached snaps of same. > i am new to tomcat so didnt able to understand all terms. > Well your added filter will not help, if there is already code in place. To find a possible configuration you may check on your webapp’s web.xml (located in the WEB-INF directory). But that all depends on the webapp... Is this application developed by you/your company or somebody else? You may need help from the developer. Best regards Peter >> On Wed, Feb 27, 2019 at 9:20 PM logo wrote: >> >> >> Hello Nitin, >> >> Am 27.02.2019 16:34, schrieb Nitin Kadam: >> >> > Hello Team, >> > >> > I have added below given filter and restarted tomcat service still it >> > shows Cache Control as private. >> > Please help me on same. >> >> Pictures are stripped off the mailing list. so better send us text logs. >> >> >> Nevertheless I told you before, the Cache-Control header may come from >> your webapp. So you have to check the web.xml of the app for a possible >> filter. Maybe it's also in the framework or the servlets itself. What is >> happening if you request a resource from another context? >> If it is set in the app, then possibly nothing in tomcat will be able to >> remove it from the response (maybe a reverse proxy like apache or >> nginx). >> >> Hope this helps. >> >> Peter >> >> > On Wed, Feb 27, 2019 at 2:54 PM logo wrote: >> > >> >> Hi Nitin, >> >> >> >> Am 27.02.2019 10:11, schrieb Nitin Kadam: >> >>> Sorry for typo in earlier email, i was saying about ExpiresFilter only >> >>> >> >>> so how do i add this filter and failter mapping , Do i need to add >> >>> both in existing httpHeaderSecurity >> >>> >> >>> >> >>> >> >>> ExpiresFilter >> >>> >> >>> org.apache.catalina.filters.ExpiresFilter >> >>> >> >>> ExpiresByType image >> >>> access plus 10 days >> >>> >> >>> >> >>> ExpiresByType text/css >> >>> access plus 10 hours >> >>> >> >>> >> >>> ExpiresByType application/javascript >> >>> access plus 10 minutes >> >>> >> >>> >> >>> >> >>> ExpiresDefault >> >>> access plus 0 seconds >> >>> >> >> >> >> this is an extra entry. I don't know if you should really put this in >> >> the global web.xml or rather in your applications web.xml. Maybe Mark >> >> can let us know more about possible consequences? >> >> >> >> Add the ... AND the !!! >> >> >> >> Peter >> >> >> >>> >> >>> >> >>> On Wed, Feb 27, 2019 at 1:59 PM logo wrote: >> >>> >> >>>> Hello Nitin, >> >>>> >> >>>> Am 27.02.2019 08:52, schrieb Nitin Kadam: >> >>>>> Hello, >> >>>>> >> >>>>> >> >>>>> >> >>>>> How can i change "Cache Control -private: to "Cache-Control: nostore" >> >>>>> >> >>>>> i searched and found that need to add express filters in web config but >> >>>>> not >> >>>>> sure on where to add in filters. >> >>>>> >> >>>>> can you please guide me on same? >> >>>>> >> >>>> >> >>>> as far as I can tell, that Header is already set by your application - >> >>>> Tomcat will not set it by default. Not to "private" for sure. >> >>>> So it may be necessary to change that in your config, maybe even code. >> >>>> >> >>>> Usually you would have to implement a CacheControl filter like the one >> >>>> mentioned here at stackoverflow >> >>>> https://stackoverflow.com/questions/2876250/tomcat-cache-control [1] >> >>>> >> >>>> I don't know if the new ExpiresFilter will let you set the >> >>>> Cache-Control-Header to that necessary value (other than max-age=0).
Re: Http insecure headers
Hi Nitin, Per se this can be done by enabling the org.apache.catalina.filters.HttpHeaderSecurityFilter in the global or your webapp‘s web.xml For CSP you should write your own Filter. Beware though that Content Security Policy is nothing that can be enabled without application knowhow, the right settings for your needs and intensive testing. You may really break inline Javascript in your pages (css too). Please check out the great websites of Scott Helme on the Headers https://Securityheaders.io or https://scotthelme.co.uk/csp-cheat-sheet/ Peter > Am 19.02.2019 um 19:13 schrieb Nitin Kadam : > > Hello Team > > Need help to enable below security headers in Apache tomcat 7.0.79 > Operating system is windows 2012 R2 > > 1. Content security headers > 2. HSTS header > > Regards > Nitin
Re: Question regarding mitigating the CVE-2017-12617 vulnerability
Michael, > Am 13.02.2019 um 22:03 schrieb Adams, Michael : > > Christopher, > Thanks for your input. It was very helpful. This afternoon, my > InfoSecurity technician who runs the Tripwire app believes Apache Tomcat vs > 8.5.13 is being flagged for the CVE-2017-12617 vulnerability solely off of > the version. Not saying that the update would not be worth it, but to get around the version check, you should set the ErrorReportValve like so: That will remove the version info from the 404 or error-pages. I assume that you removed the Default ROOT and examples webcontext. The are a couple more hardening suggestions. But keep the updates coming. 8.5.13 is a bit aged and the next scan will come. Just the 2cts of an application security guy. Peter > Tripwire isn't trying to see if HTTP PUT is enabled. He is opening a false > positive ticket with the Tripwire vendor to get more information on their > check. > > Thanks again, > Mike > > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, February 13, 2019 1:19 PM > To: users@tomcat.apache.org > Subject: [External] Re: Question regarding mitigating the CVE-2017-12617 > vulnerability > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Michael, > >> On 2/13/19 13:35, Adams, Michael wrote: >> I currently am running Apache Tomcat 8.5.13.0 on Windows Server >> 2012 R2 servers to support a NCR Aptra Vision application. A >> Tripwire vulnerability scan showed the servers have the Apache >> Tomcat CVE-2017-12617 Vulnerability. To mitigate I see I could >> upgrade to Apache Tomcat 8.5.23 or later. Instead of upgrading to >> 8.5.23 or later, I am wanting to 'turn off' HTTP PUT >> functionality.> I have this simple question: Is it possible to >> mitigate the vulnerability by just adding/setting the init-param >> readonly param value to true for the DefaultServer in the Apache >> TomCat instance ../conf/web.xml file? Or is Tomcat 8.5.23 or higher >> required for Apache TomCat to properly process the DefaultServer's >> setting when I set the readonly parameter to true? > Yes and no. > > First of all, conf/web.xml should default to readonly=true and it > would be a huge security vulnerability to set it to false. It is never > safe to set readonly=false in conf/web.xml because it would affect all > applications deployed that do not explicitly set the readonly flag for > DefaultServlet... and most don't. > > Which brings me to the "no" part of the above. > > If an individual application specifies readonly=false in its web.xml > file (found in WEBAPP/WEB-INF/web.xml), then the setting at the > top-level will not disable PUT and DELETE requests. > > AFAIK, there is no way to completely disable it on the server, > overriding the configuration of the deployed web applications. > >> The reason I ask is this: The Tripwire test still found the Tomcat >> CVE-2017-12617 Vulnerability even after I did the following on the >> Windoww Server 2012 R2 servers: Stopped Apache Tomcat intance, made >> the configuration change to the ../conf/web.xml file shown below, >> and re-started Apache Tomcat. > > I can think of two possible reasons: > > 1. One of your web applications is specifying readonly=false for the > DefaultServlet. This would (a) be very uncommon if true and (b) > usually means that the application *absolutely must* have it set up > that way. It's an unusual configuration mistake to make... you really > have to go out of your way to make this unsafe. > > 2. Your TripWire scan is checking the version number of the server and > complaining about everything that could possibly be in it, rather than > giving you a honest report of what vulnerabilities are actually > exploitable in your environment. > >> The following should make the context read-only and HTTP commands >> like PUT and DELETE to be rejected. >> default >> org.apache.catalina.servlets.DefaultServlet ass> >> >> > >> debug 0 >> listings >> false >> readonly true >> 1 >> >> Your help in the following matter would be much appreciated. > > That should be fine, but it should also be the default and therefore > unnecessary. > > Check each of the deployed web applications to see if they are > defining the default servlet. You should be able to do a "FIND" on > each of the app/WEB-INF/web.xml for DefaultServlet to see if anything > is in there. > > If that doesn't show any re-definitions of the DefaultServlet, they it > looks like a version bump is the only thing that will make TripWire happ > y. > > Fortunately, upgrading Tomcat between point-releases should not be a > very traumatic experience. If you'd like some help with that, just ask. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxkbaQACgkQHPApP6U8 > pFjsjg//VMeNY7moedueSgNJv7TkPJ63EikCffigqe6Dr8w7ox0Tt54zgQtX34QM > O8kE4IH
Re: [EXTERNAL] Re: tomcat Finding!
Danyaal, > Am 18.12.2018 um 21:15 schrieb > : > > Added following to the Server.xml, still showing in the latest scan. > > showReport=false" showServerInfo="false" /> > > Thank you, > Danyaal > > -Original Message- > From: John Palmer [mailto:johnpalm...@gmail.com] > Sent: Friday, December 14, 2018 6:26 PM > To: Tomcat Users List > Subject: [EXTERNAL] Re: tomcat Finding! > > WARNING:This is an external email that originated outside of our email > system. DO NOT CLICK links or open attachments unless you recognize the > sender and know that the content is safe! > > I found this to be easier to accomplish (and maintain): > > add to the Host section of server.xml: > showReport=false" showServerInfo="false" /> > > (this will disable the tomcat version number and the stacktrace - the > defaults for these are "true") > > >> On Fri, Dec 14, 2018 at 10:18 AM wrote: >> >> Good Morning, >> I'm encountering following scan finding errors and couldn't find way to >> mitigate this. >> >> Tomcat 8.5.32 >> 12085 >> Apache Tomcat Default Files >> The following default files were found >> :/nessus-check/default-404-error-page.html >> Delete the default index page and remove the example JSP and servlets. did you also remove the default files under webapps (examples, Root,...)? This finding is not only for errorpages with version number! Peter >> Follow the Tomcat or OWASP instructions to replace or modify the default >> error page. >> >> Thank you, >> Danyaal >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > B‹CB•È [œÝXœØÜšX™KK[XZ[ˆ \Ù\œË][œÝXœØÜšX™P ÛXØ] > ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ \Ù\œËZ[ ÛXØ] ˜\XÚK›Ü™ÃBƒ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection closed error and certificateVerification="required"
Mark, >> Am 18.04.2018 um 11:55 schrieb Mark Thomas : >> >> On 18/04/18 10:36, Richard Tearle wrote: >> On 17 April 2018 at 16:45, Richard Tearle >> wrote: >>> On 17 April 2018 at 14:54, Mark Thomas wrote: > On 17/04/18 11:36, Mark Thomas wrote: > On 17/04/18 10:14, Richard Tearle wrote: > Now all we need to to do is to figure out how to fix this. With the > understanding of what is (probably) going wrong, the problem can be > produced with a clean build and the certs we use for unit tests which > makes things a lot easier. I hope to make progress on this today. I believe this is fixed in trunk for both 9.0.x and 8.5.x. Are you able to build either of those from source and test? If not, I can provide a snapshot build for you to test with. Cheers, Mark >>> >>> I've built from source, re-enabled the health check, and so >>> far so good - it's been running an hour without an error. >>> >>> Once this run has finished, I'll run it overnight, and let you >>> know tomorrow morning. >>> >>> Many thanks for your help on this. >>> >>> -- >>> Richard >> >> Just a quick follow up - I've run our test for 8 hours, without the >> connection closed error. > > Excellent. That is really good news. > >> Again, many thanks. > > No problem. Happy to help. Thanks for your assistance with this issue. > Your test case and debug logs were invaluable. I couldn't have fixed > this without them. > > Mark > Do you mind to share more about the root cause? I’ve followed this mail communication from the start and am curious. Let me tell you that your endurance on all the tricky issues here is admirable! Thank you for that! Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Running as user tomcat
Hi Chris, > Am 23.02.2018 um 18:36 schrieb Cheltenham, Chris > : > > Hello All, > > I am trying to run tomcat as a non root user. > > It will start as the tomcat user but it will not bind to connector 443 unless > it starts as root. > > Does anyone know why? Unix will not let you open ports below 1024 as non-root user! You may use a proxy in front of it or maybe use iptables to be able to use standard ports AND user tomcat. > 23-Feb-2018 09:14:59.140 SEVERE [main] > org.apache.catalina.core.StandardService.initInternal Failed to initialize > connector [Connector[HTTP/1.1-443]] > org.apache.catalina.LifecycleException: Failed to initialize component > [Connector[HTTP/1.1-443]] > > I’m using java 9.0.4 and Tomcat 8.5.28 > > > === > > Thank You; > > Chris Cheltenham > Technology Services > The School District of Philadelphia > > Work # 215-400-5025 > Cell # 215-301-6571 Best regards Peter
