SSL Accelerator Proxy and CONFIDENTIAL resources

[Adam Constabaris <ad...@unc.edu>]

I know questions about this have been asked before on this list and 
solutions offered, but they haven't worked for me.

I've read the proxying documentation, searched through the archives, and 
scratched my head, and I still don't have a solution I'm 100% confident 
about.

The setup is this: I want to run Tomcat 5.5 behind a load balancer and a 
hardware SSL accelerator.  The SSL accelerator handles all of the SSL 
conversation (handshake, encryption, decryption), and communicates with 
Tomcat via a standard, unencrypted, HTTP connection, with a Connector 
defined in the server.xml just for this purpose.  So, what Tomcat's 
seeing is just plain HTTP traffic.  This works fine for direct https 
requests to ordinary resources.  The problem arises when I've marked a 
resource as requiring CONFIDENTIAL transport-guarantee in the
webapp's web.xml.

The symptom I'm seeing when I hit a protected URL with Firefox 1.5 is

"Firefox has detected that the server is redirecting the request for 
this address in a way that will never complete." (Konqueror 3.4 tells me 
it's found a "cyclic link").

This happens whether the scheme I put in the location bar is "http" or 
"https"; what I think is going on is that Tomcat doesn't 'believe' the 
request is secure, whether it's coming in over the regular connector 
(for normal, unencrypted traffic) or the 'fake secure' connector, so it 
keeps sending redirects to the browser telling it to try the same URL.

Setting "secure='true'" on the Connector doesn't work, as that tells 
Tomcat to handle the SSL traffic.

Following the advice in

http://marc.theaimsgroup.com/?l=tomcat-user&m=105070277803721&w=2,

I tried setting "scheme='https'" proxyName="myserver.foo" and 
proxyPort="443" on the 'fake secure' Connector, but that didn't change 
the observed behavior.

Writing a ServletFilter that checks to see whether the request is coming
in over the 'fake secure' connector and wrapping it in doesn't work, as 
it doesn't seem to be getting invoked at all (i.e. whatever Tomcat's 
doing to guarantee confidentiality is happening before the ServletFilter 
gets run).

I have a Valve implementation that I wrote that sort of works, although 
I was seeing spotty behavior with it (not sure what I did, but I was 
able to cause the symptom noted above after a few clicks around).

Essentially, the Valve checks to see if the localPort on the incoming 
request is the 'fake secure' connector's port, and calls 
request.setSecure(true); this may or may not be a performance drag, but 
it is definitely non-portable.

Does anybody have any advice about this?  I'm having a hard time 
believing this type of setup is *that* unusual ... (see also the 
following from the tomcat-dev list earlier this year:

http://mail-archives.apache.org/mod_mbox/tomcat-dev/200504.mbox/%3C33076.38.116.134.159.1112508042.squirrel@secure.wispertel.net%3E

I think he's describing exactly what I'd need)

TIA,

AC

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org