Modifying the Ajp13 Protocol

[Dan Milstein <da...@shore.net>]

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).

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).

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?

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.

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.

What do people think?

-Dan
-- 

Dan Milstein // danmil@shore.net

RE: Modifying the Ajp13 Protocol - Borland Free C Compiler

[Paulo Gaspar <pa...@krankikom.de>]

Hi Gomez,


I played last weekend with the free Borland C Compiler after an 
exchange of posts with Pier and I got a good a good feeling about it.

It sure looks much easier to port make files to this one than to 
Visual C++.

I also red about its use in a report by the Interbase/Firebird guys 
and it looks that the only problems they had were related to lack of
understanding of the calling conventions when linking the compiled 
code with other binaries. Besides that, the report was positive.
(And Interbase is a bit bigger than these connectors.)


Could you please say something more about what is your experience 
with it please Gomes?


Thanks a lot,

Paulo Gaspar


> -----Original Message-----
> From: Gomez Henri [mailto:hgomez@slib.fr]
> Sent: Tuesday, December 05, 2000 23:02
> 
> 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)
> 

Re: Modifying the Ajp13 Protocol

[Gomez Henri <hg...@slib.fr>]

> 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 ;-)

Re: Modifying the Ajp13 Protocol

[cm...@yahoo.com]

> 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?

If the change is backward compatible - leave it 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.

Yes, mod_webapp will be a big step forward and will have some very nice
features - and as soon as it's ready I think it will be a big priority to
make sure it works with tomcat3.3, next to mod_jk and mod_jserv.

But tomcat3.3 will continue to support existing protocols, and even add
other new protocols ( like improved JNI communication, etc) - it's very
hard to get performance without experimenting and testing and fine
tunning, and each protocol provides it's own benefits (
AJP12 is slower but more tested and probably more stable than AJP13,
and JNI have different benefits than AJP13 ). 

And even if mod_webapp will be best protocol, evolving ajp13 and improving
it's performance will certainly help everyone - the hard thing about
getting performance is that it requires many, many experiments and tests
and small changes. You can't get it right the first time.

> 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 think it's ok. We could add  a version number in mod_jk (like
mod_jk_1.so, etc ) - so we know what is what ?

Costin