Created attachment 28630 [details] adding "secret" proxypass option apache httpd config: ProxyPass /test ajp://localhost:8009/test secret=123 tomcat config: <Connector protocol="AJP/1.3" requiredSecret="123" ... />
Voting for this bug because this is the only way to prevent someone from constructing a ajp request and sending it with a invalid username to a tomcat server. This module should support this.
example of more secure configuration. main apache virtualhost file (world readable): ... ProxyPass /test ajp://localhost:8009/test #Include must be after ProxyPass Include ajp_secrets.include ... contents of ajp_secrets.include (only root readable): ... ProxySet ajp://localhost:8009/test secret=123 ...
Voting to this because it's a way of securing connection between Apache Reverse proxy and target application server. It would be even better to have a "signature request mechanism" for some header. Like if the REMOTE_USER header is added by the reverse proxy, the header is signed in a REMOTE_USER_SIGNATURE field, using a private key stored on the reverse proxy.
signature will require modification on the Tomcat side. this patch only impliment Tomcat requiredSecret option for mod_proxy, like mod_jk does. see https://tomcat.apache.org/connectors-doc/reference/workers.html (search for "secret"). security for frontend to backend communication may be done by localhost connection or by network topology (network switch), etc. security for frontend to backend communication may be done by localhost connection or by network topology (network switch, etc.), because this is internal trusted link.
this patch is worked with apache-2.4.18
Created attachment 33739 [details] apache 2.4 patch
(In reply to Dmitry A. Bakshaev from comment #4) > signature will require modification on the Tomcat side. > this patch only impliment Tomcat requiredSecret option for mod_proxy, like > mod_jk does. > see https://tomcat.apache.org/connectors-doc/reference/workers.html (search > for "secret"). > security for frontend to backend communication may be done by localhost > connection or by network topology (network switch), etc. > > security for frontend to backend communication may be done by localhost > connection or by network topology (network switch, etc.), because this is > internal trusted link. You're right, I've created a new request for this signature idea : 59285 (https://bz.apache.org/bugzilla/show_bug.cgi?id=59285). This will permit to the application to treat this field without changing the Tomcat connector.
(In reply to David Naramski from comment #7) > You're right, I've created a new request for this signature idea : 59285 > (https://bz.apache.org/bugzilla/show_bug.cgi?id=59285). > > This will permit to the application to treat this field without changing the > Tomcat connector. why not use ssl for backend connection? integrity, encryption, transparently for both sides mod_proxy can do it for http. not sure about mod_proxy_ajp and tomcat ajp-connector.
(In reply to Dmitry A. Bakshaev from comment #8) > > why not use ssl for backend connection? > > integrity, encryption, transparently for both sides Agreed. > > mod_proxy can do it for http. > not sure about mod_proxy_ajp and tomcat ajp-connector. mod_proxy_ajp can also be configured to use TLS connections and PKI.
Yann, are you aure about proxy_ajp and TLS? I thought the TLS part is only inside proxy_http but I could be wrong. Of course one can use technology outside of httpd like stunnel. I also would be very surprised, but positively surprised, if we would find a way on AJP servers (Tomcat, Jetty) to configure AJP over TLS there. Regards, Rainer
Hmm, you are right, I thought "ajps:" was handled but it's an overlook on my side. It shouldn't be too much pain to add it though, if Tomcat is already good to go, most of the code to handle TLS is in proxy_util. I could try to cook a patch...
The subject of this bug report is adding support to include the "secret" AJP field. Please do not confuse things by bringing in other topics such as AJP support for TLS, instead open a new bug report for that independent issue. Now back to the actual topic of this bug. A simple non-controversial patch has been available since this bug was opened 4 years ago. Yet 4 years later it still has not been applied. Why?
(In reply to jdennis@redhat.com from comment #12) > Now back to the actual topic of this bug. A simple non-controversial patch > has been available since this bug was opened 4 years ago. Yet 4 years later > it still has not been applied. Why? Maybe because a stronger authentication method is possible by using an https connector? Not ajps though (I stand corrected!), but AFAICT current Tomcat versions can be configured to use https and hence TLS authentication. Please keep in mind that committers are volunteer here, with limited time devoted to most important tasks, in their opinion... The point is, IMHO, that a secret sent in clear text in not very secure. Either the network between httpd and tomcat is controlled and an (week) authentication is not needed, or the network is unsafe and a stronger authentication is required.
I suspect everyone is in agreement that the transport needs to be protected for this to be useful. But lets not get the cart before the horse, protected transport only becomes an issue *after* this omission in the AJP protocol generation is fixed. That's all this bug report is asking for, to correct the omission. The patch is available, it's not hard. Nobody would be forced to use the feature so it doesn't make anything less secure. But as it stands now if you do want to use it, perhaps you have a protected transport available to you, you can't use it because the AJP protocol generator oddly omits the attribute. We want to use the attribute. We'll worry about the separate issue of protected transport elsewhere. Make sense?
this patch just adds lost functionality to mod_proxy_ajp, a lot of time working in mod_jk+tomcat. no new features. a typical usage scenario: client(browser) - https(internet) - apache httpd(ssl-termination-acceleration) - mod_proxy_ajp - ajp - localhost(trusted area) - apache tomcat(application) "secret" need to "bind" multiple url on apache httpd to multiple tomcat instances or connectors one-to-one, to protect from fake ajp requests from other application and users from same host(localhost). "secret" works like "identification", not crypto-blablabla... ssl,encryption&etc is separate question.
(In reply to jdennis@redhat.com from comment #14) > We want to use the attribute. We'll worry about the separate issue of > protected transport elsewhere. Make sense? (In reply to Dmitry A. Bakshaev from comment #15) > this patch just adds lost functionality to mod_proxy_ajp, a lot of time > working in mod_jk+tomcat. Fair enough, there seem to (still) be attraction to it, so committed in r1738878, let's see what others say... > > a typical usage scenario: > client(browser) - https(internet) - apache > httpd(ssl-termination-acceleration) - mod_proxy_ajp - ajp - > localhost(trusted area) - apache tomcat(application) > > "secret" need to "bind" multiple url on apache httpd to multiple tomcat > instances or connectors one-to-one, to protect from fake ajp requests from > other application and users from same host(localhost). I can grok the "isolation" argument (prevent requests from reaching unexpected services), but not the security one. This is definitively not a security feature (like SSLv2 isn't anymore), and shouldn't be presented as such. As I said earlier, either localhost is trusted or it is not, and in the latter case "secret" won't change anything (significantly). > > "secret" works like "identification", not crypto-blablabla... > > ssl,encryption&etc is separate question. This is called "authentification" in crypto, not blah, and it's probably the only way to achieve security goals, if any...
Thank you!
thanks to all
It would be useful to backport this eature to 2.4.x. The newest Tomcat releases hardened the AJP connector by demanding a "secret" by default, so they are no longer compatibel with mod_proxy_ajp out-of-the-box. One has to explicitly set secretRequired="false" on the TC AJP connector to be able to use it with mod_proxy_ajp (and thereby increase attack surface). r1738878 plus small struct layout adjustments for compatibility should do it.
Backported today to 2.4.x as r1874456, will be part of 2.4.42.
(In reply to Rainer Jung from comment #20) > Backported today to 2.4.x as r1874456, will be part of 2.4.42. Thank you! The secret is also documented (not yet backported to 2.4.x) in https://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml?view=markup Caveat: mod_proxy_ajp.xml refers to old attribute names <code>request.secret</code> or <code>requiredSecret</code> of Tomcat, which are now just "secret". I updated a similar reference in mod_jk documentation in the following commit: https://github.com/apache/tomcat-connectors/commit/83dc3e486509cf63b0c478b46d75b4b886088652
Because of Ghostcat CVE-2020-1938 may I ask you, when (in detail) the 2.4.42 release will be out? After the tomcat side could be hardened, we can not do it, because of missing support on the other side in Apache reverse proxy. :-(
Agreeing with Patrick, we need this released so we can resolve issue with Tomcat updates.
2.4.42 failed the release vote, but in te meantime 2.4.43 has been released, which contains this feature.