Hi Christopher,
On 27.02.2018 23:18, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Olaf,
On 2/27/18 4:33 PM, Olaf Kock wrote:
On 27.02.2018 21:54, Mark A. Claassen wrote:
I would /not/ state that it's /not secure/. But I'm following your
later argument: It's an "unencrypted connector", yes. In order to
encrypt it, it needs to be run through an encrypted tunnel - and
doing so is cumbersome, error prone and unrelated to the
unencrypted nature of this connector.
We use stunnel in production to tunnel AJP from AWS-based web servers
and our back-end co-located app servers. We haven't had any problems
with that set up vis-a-vis connection failures or anything like that.
We haven't even had any issues with running out of file-handles for
stunnel.
So, yes, it's another component to configure and babysit, but I
wouldn't call it "cumbersome"... merely "more than you might expect"
when HTTPS through mod_proxy_http is an alternative.
Nice. This is the first time that I hear that somebody actually does
this. It's not surprising that it comes from this direction (e.g. you,
somebody well known in this community).
And yes, I rambled - couldn't resist. While I wouldn't object with
your proposed change, I believe that the world wouldn't be notably
better with it.
I disagree: I can imagine many administrators (or developers, who
often do make these decisions) overlooking the fact that AJP is a
plaintext protocol. It's definitely worth mentioning that fact, and
that it should only be used over trusted channels where anyone
observing the traffic is an acceptable risk.
As I said: I won't object to the change. And given my statement about
taking advice from the first hit on stackoverflow, I guess I'll have to
take back my conclusion: The world would be slightly better. I've leaned
towards my default to rather /not/ document what a feature can /not/ do,
because this kind of documentation makes docs hard to read.
Thinking about this situation again, here's a case with a benefit. Not
only would I not object - I'll now fully support it. (well, not that
this has any weight, but it feels good to have a new insight. Thank you
for that)
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
