> Another point of mod_jk is for Dan and about the question of security
> and or ligth crypto support. ajp12/ajp13 didn't support ACL to accept/deny
> connections from a list of known host, and the protocol is in clear text.
> Costin suggest using SSH tunnels which be a fast work-around but I really
> like to have this ACL+CRYPTO included in mod_jk/ajp13.
I agree that some form of authentication (and possibly encryption) are high-priority
things to add to mod_jk / ajp13. Before I dive into that work, though, I want to be
sure that there is a future for the code -- that's why I'm proposing using it in TC 4
as well as TC 3.
In some previous discussions about extending ajp13, there had been hope that it could
be done fairly easily, since there are typed packets, so new packet types could be
added without breaking the protocol. Unfortunately, I don't think that's going to
work -- the current code does read packet types, but if it sees an unknown packet
type, it closes the connection down. This makes it impossible to send packets in an
exploratory manner.
Fortunately, the ACL's should be implementable without touching the packet types (I
think you suggested this, Henri). We can just add a list of safe hosts to the
configuration directives for TC, and it will only allow connections if they come from
the specified hosts. I think this would still leave us open to IP address spoofing,
but it would certainly be an improvement over what we've got now.
For encryption, we would have to introduce new packet types. Personally, my feeling
is that encryption of the stream between the Web Server and TC is much less important
than authenticating connections. Especially given that SSH tunnels are not that hard
to set up, I am reluctant to add the complexity of crypto code to ajp13.
Finally, going ahead. I think it would be a good idea to introduce ajp14 (once the
bulk of the work above has been completed). I would propose it as a slight variant on
ajp13. Basically, the same protocol, with a few new packet types (we need something to
handle > 8K of header information), *and* with provision for handling unknown packet
types more intelligently. I think this would give us a protocol which we could live
with more easily over time. We could add new features, but it could still communicate
with old web server plugin versions.
-Dan
--
Dan Milstein // [EMAIL PROTECTED]
