Re: AW: gostCat patch
On 23.03.20 15:07, Mark Thomas wrote: > On 23/03/2020 14:02, Fritze, Florian wrote: >> Maybe I am making it too easy but if you or another tomcat developer could >> prevent the newest Tomcat from throwing this exception: >> >> org.apache.catalina.core.StandardService.startInternal Failed to start >> connector [Connector[AJP/1.3-8011]] >> org.apache.catalina.LifecycleException: Der Start des >> Protokoll-Handlers ist fehlgeschlagen >> at >> org.apache.catalina.connector.Connector.startInternal(Connector.java:1057) >> at >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> at >> org.apache.catalina.core.StandardService.startInternal(StandardService.java:440) >> at >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> at >> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766) >> at >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >> at org.apache.catalina.startup.Catalina.start(Catalina.java:688) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) >> at >> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) >> Caused by: java.lang.IllegalArgumentException: The AJP Connector is >> configured with secretRequired="true" but the secret attribute is either >> null or "". This combination is not valid. >> at >> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274) >> at >> org.apache.catalina.connector.Connector.startInternal(Connector.java:1055) >> ... 12 more >> >> This could solve the problem for me: Please just let the tomcat run through >> and do not let it check for the validation criterion. > Sorry, no. > > Research indicated that a large number of Tomcat users were running an > AJP connector in an insecure configuration. The Tomcat team made a > deliberate choice to break those configurations and require users to > make configuration changes either to secure those configurations or to > explicitly allow the insecure ones. I applaude this decision. I believe that the error message is clear enough to point to the root cause - and with the public awareness of the Ghostcat vulnerability and necessity to patch, the release notes are quite clear about the changed defaults. The only change that I'd assume could help is to add a comment to server.xml, next to the commented-out AJP-Connector, that states: "This configuration isn't complete - read the documentation, particularly 'secretRequired', 'secret', ... to learn about the proper settings". But even if that doesn't go in, the necessary change should be found quickly given the above error message. Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: gostCat patch
On 23/03/2020 14:02, Fritze, Florian wrote: > Maybe I am making it too easy but if you or another tomcat developer could > prevent the newest Tomcat from throwing this exception: > > org.apache.catalina.core.StandardService.startInternal Failed to start > connector [Connector[AJP/1.3-8011]] > org.apache.catalina.LifecycleException: Der Start des > Protokoll-Handlers ist fehlgeschlagen > at > org.apache.catalina.connector.Connector.startInternal(Connector.java:1057) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardService.startInternal(StandardService.java:440) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at org.apache.catalina.startup.Catalina.start(Catalina.java:688) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) > at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) > Caused by: java.lang.IllegalArgumentException: The AJP Connector is > configured with secretRequired="true" but the secret attribute is either null > or "". This combination is not valid. > at > org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274) > at > org.apache.catalina.connector.Connector.startInternal(Connector.java:1055) > ... 12 more > > This could solve the problem for me: Please just let the tomcat run through > and do not let it check for the validation criterion. Sorry, no. Research indicated that a large number of Tomcat users were running an AJP connector in an insecure configuration. The Tomcat team made a deliberate choice to break those configurations and require users to make configuration changes either to secure those configurations or to explicitly allow the insecure ones. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: gostCat patch
Maybe I am making it too easy but if you or another tomcat developer could prevent the newest Tomcat from throwing this exception: org.apache.catalina.core.StandardService.startInternal Failed to start connector [Connector[AJP/1.3-8011]] org.apache.catalina.LifecycleException: Der Start des Protokoll-Handlers ist fehlgeschlagen at org.apache.catalina.connector.Connector.startInternal(Connector.java:1057) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:688) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid. at org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274) at org.apache.catalina.connector.Connector.startInternal(Connector.java:1055) ... 12 more This could solve the problem for me: Please just let the tomcat run through and do not let it check for the validation criterion. -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center Research Services & Open Science Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49 711 970-2713 florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de -Ursprüngliche Nachricht- Von: Mark Thomas Gesendet: Montag, 23. März 2020 14:56 An: users@tomcat.apache.org Betreff: Re: gostCat patch On 23/03/2020 11:34, André Warnier (tomcat/perl) wrote: > The *default* of this attribute is "false", when the "address" > attribute is explicitly set to "127.0.0.1" or "::1", or when it > defaults to the loopback address. > The *default* of this attribute is "true", when the "address" > attribute is set to any other IP address. > unquote This proposal assumes that only trusted users have access to the loopback address. While this is true for the majority of Tomcat installations there are use cases where this is not the case. Granted those use cases (e.g. shared hosting) usually have better solutions (e.g. per user, isolated containers) where only trusted users have access but not everyone uses them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: gostCat patch
On 23/03/2020 11:34, André Warnier (tomcat/perl) wrote: > The *default* of this attribute is "false", when the "address" attribute > is explicitly set to "127.0.0.1" or "::1", or when it defaults to the > loopback address. > The *default* of this attribute is "true", when the "address" attribute > is set to any other IP address. > unquote This proposal assumes that only trusted users have access to the loopback address. While this is true for the majority of Tomcat installations there are use cases where this is not the case. Granted those use cases (e.g. shared hosting) usually have better solutions (e.g. per user, isolated containers) where only trusted users have access but not everyone uses them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
gostCat patch
Hello tomcat developers. Re : current : https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations quote secretRequired If this attribute is true, the AJP Connector will only start if the secret attribute is configured with a non-null, non-zero length value. This attribute only controls whether the secret attribute is required to be specified for the AJP Connector to start. It does not control whether workers are required to provide the secret. The default value is true. This attribute should only be set to false when the Connector is used on a trusted network. unquote The above new feature/default has been creating a lot of issues, particularly for sysadmins, who upgrade to what looks like a minor version level, and find their front-end/back-end configurations not working anymore. (Because previously, they did not specify this attribute at all, which defaulted to "false"). In many cases, this will happen even though the front-end httpd (or IIS) and the back-end (tomcat) are in fact running on the same host (*), and thus using the loopback interface to communicate (which also fits well with the new default for "address", which is the loopback address). To avoid such surprises for sysadmins, how about the following suggested change, to the documentation and to the underlying code : quote secretRequired If this attribute is true, the AJP Connector will only start if the secret attribute is configured with a non-null, non-zero length value. This attribute only controls whether the secret attribute is required to be specified for the AJP Connector as they did previouslyto start. It does not control whether workers are required to provide the secret. This attribute should only be set to false when the Connector is used on a trusted network. In consequence and as a hint : The *default* of this attribute is "false", when the "address" attribute is explicitly set to "127.0.0.1" or "::1", or when it defaults to the loopback address. The *default* of this attribute is "true", when the "address" attribute is set to any other IP address. unquote The point is to make sure that existing configurations, which often concern a front-end and a back-end running on the same host, and which often do not contain an explicit "secretRequired" AJP Connector attribute, would default to working as they did before, but *only if* the connection is deemed secure anyway, because it is local. I believe that this alone would already greatly reduce the "stress" caused by this security-related configuration change. (*) I currently manage about 30 Apache httpd / tomcat combinations, and in all of them but one, they are on the same host. And from a historical perspective, I believe that is true for the majority of httpd/tomcat installations except large load-balancing configurations. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org