Taking this out of bugzilla.
You say 'I found a little crasy to see HTTP SSL requests, decryped by Apache, then
reencrypted by Apache for Tomcat (in ajp13) and then redecrypted by Tomcat.'
How does this differ to your ssh tunnel idea ?
Mine :
browser talks https to apache
apache connects directly to a secure channel which transfers ajp13 over the SSL
encrypted link to
tomcat.
Resources
On the sending server : encryption on apache making network connection to dest server.
On the destination server: A SecureSocket connection decrypting data transfer ( in
java of course)
ssh tunnel version:
browser talks https to apache
apache connects to ssh tunnel running on localhost as plain uncrypted ajp13
which then connects to and encrypts the data transfer to
another ssh tunnel running on the destination server which then decrypts the data and
sends the plain ajp13 onto tomcat.
Resources :
On the sending server: ssh tunnel listening encrypting data transfered to it.
On the destination server : ssh tunnel listening for inbound connections decrypting
and connecting to
Tomcat listening for inbound insecure connections.
In essense both are doing the same. Just with the channel you don't have to rely on
extra programs to work.
I haven't done any speed comparisons between java doing encrypted links and native
code.
If you are saying that java just can't do encryption at a sufficient speed to be
useful I'll have to take your word for it.
Out of interrest is anyone out there using the https JK2 connector ? Does it work ? or
is the speed of java doing encryption
make the https connector unusable ?
If there is a massive performance hit with Java doing SSL decryption it might be worth
using sshtunnel on the destination
server. But I really can't believe it will be that bad.
Thanks
David
[EMAIL PROTECTED]
rg To: [EMAIL PROTECTED]
cc:
04/06/2003 13:16 Subject: DO NOT REPLY [Bug 20473] -
ajp13 connection between apache and tomcat is not encrypted
Please respond to
"Tomcat
Developers List"
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|REOPENED |RESOLVED
Resolution| |INVALID
------- Additional Comments From [EMAIL PROTECTED] 2003-06-04 12:16 -------
Using a ssh tunnel consume less resource SINCE you do crypto with
native code on both side, whereas in you're solution, we're doing crypto on
Apache (native) and Tomcat (java).
In many configuration, Apache and Tomcat are on the same box, so the packet are
local and when tomcats are remotes, which is the case for large deployment, the
security SHOULD BE HANDLED for each configuration/requirement.
I found a little crasy to see HTTP SSL requests, decryped by Apache, then
reencrypted by Apache for Tomcat (in ajp13) and then redecrypted by Tomcat.
Also you shoudn't use bugzilla for such reports.
It's not an error but a missing feature so the request should be
sent on tomcat-dev where developpers could respond to you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
