DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20473>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20473

ajp13 connection between apache and tomcat is not encrypted

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|LATER                       |



------- Additional Comments From [EMAIL PROTECTED]  2003-06-04 12:07 -------
So, Let me get this right.
In order to use *less* resources we need to twice the amount of work ? 
( ie on box a run apache & sshtunnel and on box b run tomcat & sshtunnel)

This doesn't make sense to me.
Having tested this on a p2 300 (both ends) it doesn't add much overhead & to the
poor box. AJP13 is very good with keep-alive connections. The majority of the
overhead is on the initial connection. The encryption whilst the connection is
alive is relativly low.

That being said I can understand that the average user of Tomcat & apache
doesn't care too much about the security level between apache & tomcat. The fact
that they have a secure site with an insecure connecting layer won't bother them.

However for the bigger/enterprise user of this technology, this might be of
concern. Security teams will be interrested in this.

Of course if you have two machines on the open net and you are taking credit
card details etc please think about the implications.

I suggest that in the same way that Java has the 'javax.' classes we should
consider a level of extensions for mod_jk2. After all *ALL* the work has been
done it's all here you just need to use it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to