> As I'm working through the ajp13 code (C and Java), I'm discovering that
> there is some basic work which needs to be done on the protocol itself
> (as well as a lot of work on the implementations).
Cool there is some need for.
> Specifically:
>
> - If the request contains > 8K of header/attribute information, the
> protocol fails.
> - There is no authentication step. I believe that this could result in
> some serious security violations if the web server is performing HTTP
> authentication (since remote_user is one of the attributes passed over).
> [side note: if anyone thinks otherwise, let me know] Since connections
> are maintained across many requests, there is no good reason not to do
> the authentication (IMHO).
Rigth, a fix is needed. We could use a strategy like hosts.deny and hosts.allow
used on Linux systems. We could add also a secret token between the apache
server and tomcat. I've also some ideas around.
> To fix these major issues will require modifying the protocol. I have
> some ideas on how to do so, but I want to get some feedback on the best
> way to go about making these changes. I could just modify the protocol
> itself, and change the mod_jk code and Ajp13 code in the tomcat-3.3
> branch. My fear is that I'll be changing a protocol which is in
> production use, without changing its version number. This seems like
> asking for trouble. Should I therefore leave ajp13 where it is and work
> on ajp14? Or is that multiplying protocols needlessly?
Please consider also tomcat 3.2 since it could be included in 3.2.1 ;-)
BTW: Why not negociating at connect time ? We could have ajp13 on tomcat check
if a key is present and then :
- It could accept old ajp13 unsecurized
- It could require an ajp13 securized via secret token.
Even simpler will be to use some ACL to accept only from source IP adress. It
will avoid to change the protocol. When using tomcat with apache it's easy to
protect the link via routers or firewall.
Also the protection could be include in integrated firewall found on Linux/BSD
box => No need to modify tomcat or ajp13.
> I realize that the new mod_webapp is being worked on, but it seems to me
> that getting mod_jk / ajp13 working right is probably still worth it --
> there are plenty of people who are going to depend on that before Tomcat
> 4.0 is released.
Right : for now ajp13 and mod_jk are the only production ready protocol.
> If I do change the protocol, it will require people who download the new
> version to update their mod_jk.so at the same time as they rebuild the
> Java classes.
I'll do that job at least for Linux box and could also do that on Windows world
(just need to adapt makefile to borland free c compiler)
> What do people think?
+1
PS: You did a nice work on documenting ajp13.
Feel free to recontact me directly ;-)
