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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]