I am confused no doubt. What you say here is correct: *"In your description of the issue so far, you've said that the application *is* using SSL. The load-balancers might be terminating it & forwarding unencrypted connections"* * * *I think I understand what you mean by redirecting. Our current configuration. Framework A does not use SSL thus uses connector port 80. Framework B, the problem, uses SSL/port 443. * * * * <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" /> (Used by framework A) <Connector port="443" protocol="HTTP/1.1" connectionTimeout="20000" scheme="https" secure="true" /> (Used by framework B)
Now I could change the port 80 connector to have a redirectPort attribute like so: <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="443"/> The problem with this approach is that framework A which does not use SSL now will use it via he redirect port. We'll then get the same mixed content warnings in the browser. I hope this explains the problem more clearly. * > > Redirecting as I explained below just means that you can upgrade to > HTTPS for specific paths. The load-balancer still handles it. > > > > If we use anything that forces SSL it will fail for the other framework > which does > > not use SSL. > > Why? > > How are you switching back to HTTP for 'the other framework', once the > user has been on a page served under HTTPS? > > > p > > > > On Thu, Jul 1, 2010 at 3:59 AM, Pid <p...@pidster.com > > <mailto:p...@pidster.com>> wrote: > > > > On 01/07/2010 08:49, John-Paul Ranaudo wrote: > > > No we are not. > > > > If the SSL-only resources match a specific path, you can add a > > security-constraint which doesn't have user roles, but does have a > > transport-guarantee set to 'CONFIDENTIAL'. > > > > The container will automatically upgrade a matching request to HTTPS > by > > redirecting it to the port configured in 'redirectPort' on the HTTP > > connector. > > > > > > p > > > > > On 7/1/10, Pid <p...@pidster.com <mailto:p...@pidster.com>> wrote: > > >> On 01/07/2010 03:42, John-Paul Ranaudo wrote: > > >>> I have now realized the root of the problem. The cause of the > > problem is > > >>> that the load balancer will sometimes proxy an HTTPS request as > > an HTTP > > >>> request so when we send back a redirect we send it back with the > > wrong > > >>> scheme (HTTP). So here is my current configuration: > > >>> > > >>> <Connector port="80" protocol="HTTP/1.1" > > connectionTimeout="20000" /> > > >>> <Connector port="443" protocol="HTTP/1.1" > connectionTimeout="20000" > > >>> scheme="https" secure="true" /> > > >>> > > >>> Port 443 is not really handling the SSL because the load > > balancer is. I > > >>> set > > >>> "secure" to true to mark the connections as secure to tomcat and > not > > >>> needing > > >>> SSL decryption as recommended. > > >>> > > >>> The one framework in which uses HTTPS will send most request as > > HTTPS > > >>> however the load balancer (for unknown reasons) proxies the > > request as > > >>> HTTP > > >>> (port 80). So now when we send a redirect it's to HTTP (port 80) > > not HTTPS > > >>> (port 443). It should be port 443. > > >>> > > >>> Any idea how I can handle this in a connector configuration? > > >>> > > >>> My first thought is to create two virtual hosts which will then > > have 2 > > >>> different server.xml's. If I do this I can tell tomcat to proxy > > all HTTP > > >>> (port 80) requests to port 443 but only for that one virtual > > host (which > > >>> contains the problem framework). > > >>> > > >>> Any thoughts? > > >>> > > >>> Thanks and Regards, > > >>> > > >>> John-Paul Ranaudo > > >>> Application Architect > > >>> > > >>> On Fri, Jun 25, 2010 at 2:22 PM, Christopher Schultz < > > >>> ch...@christopherschultz.net > > <mailto:ch...@christopherschultz.net>> wrote: > > >>> > > >>> John-Paul, > > >>> > > >>> On 6/25/2010 1:40 PM, John-Paul Ranaudo wrote: > > >>>>>> Ok, so I am assuming I do not have to setup SSL (certificates > > etc) > > >>>>>> since > > >>> my > > >>>>>> load balancer is decoding the connection. So even if the load > > balancer > > >>>>>> is > > >>>>>> "decoding" the connection I still have to have > SSLEnabled="true"? > > >>> > > >>> No, Pid was saying that setting one of the two options > > (SSLEnabled and > > >>> secure) to "true" makes sense... setting both to "false" is not > > >>> particularly useful. > > >>> > > >>>>>> However if > > >>>>>> I do, does this not make Tomcat try and decode the > "connection"? > > >>> > > >>> Yes, setting SSLEnabled="true" will make the connector try to > > perform > > >>> the decryption. > > >>> > > >>>>>> *Which is the root of my problem. How to use the HTTPS > > protocol without > > >>>>>> having Tomcat decrypt the connection since the load balancer > > has done > > >>> this > > >>>>>> for me. * > > >>> > > >>> It sounds like you just want Tomcat to know that the connection > is > > >>> secure, but without actually doing the decryption. You should be > > able to > > >>> do it like this: > > >>> > > >>> <Connector > > >>> port="443" <- this is the port that the LB talks to > > >>> protocol="HTTP/1.1" > > >>> connectionTimeout="20000" > > >>> scheme="https" <- so request.getScheme returns correct value > > >>> secure="true" <- so request.isSecure returns correct value > > >>> /> > > >>> > > >>> There's no need to set SSLProtocol or SSLEnabled (you're not > > using SSL, > > >>> remember), they will default to "false". > > >>> > > >>>>>> The link to the documentation is correct. However the > > properties of the > > >>>>>> connector are confusing to me. For example "SSLEnabled" if > fairly > > >>>>>> obvious > > >>>>>> but "secure" it confusing. Not sure under what context I need > > to set > > >>> this. > > >>> > > >>> You can set these to different values, for instance, to instruct > the > > >>> server to report connections as secure even when they aren't > > actually > > >>> tunneled through SSL (as above). > > >>> > > >>>>>> The application always uses relative paths so whatever > > protocol the > > >>>>>> framework is using will be what is returned in the page. > > >>> > > >>> Good. How about redirects? > > >>> > > >>>>>> I have also tried setting the redirect port thinking I can > > redirect > > >>> requests > > >>>>>> to 443 to the port 80 internally and scheme to 'https'. This > > actually > > >>>>>> had > > >>>>>> the effect of making one framework (the one with https) work > > but broke > > >>> the > > >>>>>> other. > > >>> > > >>> The redirect port is only used when the server decides that a > webapp > > >>> requires a secure connection (see <transport-guarantee> in > > web.xml), and > > >>> the server issues a redirect to the client to upgrade the > > connection to > > >>> HTTPS. The default is 443, so if a client arrives on port 80, > > they will > > >>> be redirected to the same URL except with https:// on the front > > and the > > >>> port added if it's not the default of 443. > > >>> > > >>> Now, you have to remember that the port number that does out > > attached to > > >>> a redirect URL (say, https://myhost:443/foo/bar) is probably the > > port on > > >>> the load-balancer the client will hit, not necessarily the port > > on the > > >>> local machine. The following configuration is perfectly > legitimate: > > >>> > > >>> <!-- non-secure connector --> > > >>> <Connector > > >>> port="8080" > > >>> protocol="HTTP/1.1" > > >>> connectionTimeout="20000" > > >>> redirectPort="443" > > >>> /> > > >>> > > >>> <!-- secure connector --> > > >>> <Connector > > >>> port="8443" > > >>> protocol="HTTP/1.1" > > >>> connectionTimeout="20000" > > >>> scheme="https" <- so request.getScheme returns correct value > > >>> secure="true" <- so request.isSecure returns correct value > > >>> /> > > >>> > > >>> As you see, redirectPort is set to a port that isn't being > > handled by > > >>> Tomcat. That's okay, because the load-balancer is presumably > > handling > > >>> requests to myhost:443, terminating the SSL, and proxying the > > cleartext > > >>> HTTP request to the "8443" connector, which then reports > > secure="true" > > >>> to anyone who asks. > > >> > > >> Are you using a transport-guarantee element in your web.xml? > > >> > > >> > > >> p > > >> > > >> > > >>> Hope that helps, > > >>> -chris > > >>>> > > >> > --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > <mailto:users-unsubscr...@tomcat.apache.org> > > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > <mailto:users-h...@tomcat.apache.org> > > >>>> > > >>>> > > >> > > >> > > >> > > > > > > > > > > > >
