Set Connector to "secure" but DON'T use TLS/keystore/etc.?

["John G. Norman" <jo...@gmail.com>]

For Tomcat 5.0.28:

I have an SSL accelerator in front of a set of hardware load-balanced Tomcats.

SSL is handled by the accelerator.

HTTP requests come in on port 80 and are redirected via the load
balancer (it's actually an Inkra) to a Tomcat HTTP Connector listening
on port 8080.

I would like to mark some resources in the app with the security
constraint "CONFIDENTIAL" and have the request redirected to port 443.

So . . . A redirected request would now come in on 443, where the SSL
accelerator handles TLS. Then the request goes into the LB, and goes
to a Tomcat Connector on port 8443.

Therefore, in server.xml, I would like to set the secure attribute for
the Connector on port 8443 to "true" so that the request is no longer
redirected.

But if I set the secure attribute to "true," it seems that I must
specify a keystore, and handle SSL on Tomcat. (If you set secure to
"true" but w/o a keystore, you get exceptions and the Connector
doesn't start.)

If I set the secure attribute to "false," then the redirect happens
again (effectively an infinite loop).

So . . . any suggestions?

My ideas are:

(0) See if the load balancer can do the redirect. I.e., have certain
traffic (not all, I'm afraid) return a 304 and redirect to the 443
port? There *are* certain paths (for example, for privacy policy XML
files) that must not use https/443. Then the Tomcat's 8443 could be
insecure. This is a bad solution because now the authority for the
redirect isn't in the app; harder to change.

(1) Stop using the hardware acceleration, and put the SSL cert on each
of the Tomcats. This is probably big drag for performance reasons.

(2) Write a custom J2EE filter to do the 304/redirect.

(3) Any more flexibility on this in Tomcat 5.5?

John

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

Re: Set Connector to "secure" but DON'T use TLS/keystore/etc.?

["John G. Norman" <jo...@gmail.com>]

My suggested solution (2) below works ok as a temporary stopgap. So,
if you ever find yourself in this scenario -- Tomcat behind a hardware
ssl accelerator but you need to redirect for confidential matrials), a
stopgap solution is the code below.

My question is still open as to whether or not a Connector can be set
to be "secure" but without its wanting to do TLS, etc. I wonder if
there is a way through this problem with proxy settings. Also, in the
solution below, I think there are some issues with cached resources.
Anyhoo . . .

Scenario:

1. You have Tomcat behind a hardware SSL accelerator, which handles
TLS for you. And you want that performance boost.

2. You need to mark certain resources CONFIDENTIAL in your web.xml
with <transport-guarantee>CONFIDENTIAL</transport-guarantee>

3. However, CONFIDENTIAL means that when you get traffic to your
Tomcat on the non-secured Connector, there is a redirect to, say, 443
(i.e., back to the SSL accelerator).

4. When the SSL accelerator then sends the traffic to your Tomcat's
8443, there's a double-bind:

a. If you set the 8443 Connector to secure="true" then Tomcat wants to
handle the SSL. But this is bad because it was already handled by the
hardware accelerator.
b. But if you set the 8443 Connect to secure="false" then Tomcat wants
to send the redirect (again). Infinite loop.

Stopgap solution:

1. Remove the user-data-constraint
<transport-guarantee>CONFIDENTIAL</transport-guarantee> from your
web.xml

2. Change your 8443 Connector to "secure=false"

3. Handle the redirect yourself with a filter such as this one (this
is just the dofilter method):

(Note that the filter will have to look at the incoming paths, and
reproduce whatever your settings were in that required the
CONFIDENTIAL guarantee.)

(Also note that this is obviously a hack, with some hardcoding of a
port, assumption that the other port is regular http, etc., etc.)

  public void doFilter(ServletRequest request, ServletResponse response,
      FilterChain chain) throws IOException, ServletException {

    // If incoming is not on the port that is for secure traffic, redirect
    if (request.getLocalPort() != 8443) {
      
      HttpServletRequest req = (HttpServletRequest) request;
      HttpServletResponse res = (HttpServletResponse) response;

      String url = NetUtils.getReconstructedURL(req);

      // Change the scheme
      String redirect = "https" + url.substring(4);
      res.setStatus(HttpServletResponse.SC_FOUND);
      res.setHeader("Location", redirect);
      if (logger.isLoggable(Level.INFO)) {
        logger.info("Redirecting: " + url + " to " + redirect);
      }
      return;
    } else {
      chain.doFilter(request, response);
    }
  }

John

On 6/7/05, John G. Norman <jo...@gmail.com> wrote:
> For Tomcat 5.0.28:
> 
> I have an SSL accelerator in front of a set of hardware load-balanced Tomcats.
> 
> SSL is handled by the accelerator.
> 
> HTTP requests come in on port 80 and are redirected via the load
> balancer (it's actually an Inkra) to a Tomcat HTTP Connector listening
> on port 8080.
> 
> I would like to mark some resources in the app with the security
> constraint "CONFIDENTIAL" and have the request redirected to port 443.
> 
> So . . . A redirected request would now come in on 443, where the SSL
> accelerator handles TLS. Then the request goes into the LB, and goes
> to a Tomcat Connector on port 8443.
> 
> Therefore, in server.xml, I would like to set the secure attribute for
> the Connector on port 8443 to "true" so that the request is no longer
> redirected.
> 
> But if I set the secure attribute to "true," it seems that I must
> specify a keystore, and handle SSL on Tomcat. (If you set secure to
> "true" but w/o a keystore, you get exceptions and the Connector
> doesn't start.)
> 
> If I set the secure attribute to "false," then the redirect happens
> again (effectively an infinite loop).
> 
> So . . . any suggestions?
> 
> My ideas are:
> 
> (0) See if the load balancer can do the redirect. I.e., have certain
> traffic (not all, I'm afraid) return a 304 and redirect to the 443
> port? There *are* certain paths (for example, for privacy policy XML
> files) that must not use https/443. Then the Tomcat's 8443 could be
> insecure. This is a bad solution because now the authority for the
> redirect isn't in the app; harder to change.
> 
> (1) Stop using the hardware acceleration, and put the SSL cert on each
> of the Tomcats. This is probably big drag for performance reasons.
> 
> (2) Write a custom J2EE filter to do the 304/redirect.
> 
> (3) Any more flexibility on this in Tomcat 5.5?
> 
> John
>

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