tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: SSL and non SSL configuration on tomcat 6.0.26, confused
Date Thu, 01 Jul 2010 14:01:50 GMT
On 01/07/2010 14:49, John-Paul Ranaudo wrote:
> That wont work either because like I said before, the application is not
> really using SSL. The SSL is handled by the load balancers. 

Either I'm confused, or you are.

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, but the application must be using
it - or you wouldn't need the second connector with 'scheme="https"'.

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 <pid@pidster.com
> <mailto:pid@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 <pid@pidster.com <mailto:pid@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 <
>     >>> chris@christopherschultz.net
>     <mailto:chris@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-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>
>     >> For additional commands, e-mail: users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>
>     >>>>
>     >>>>
>     >>
>     >>
>     >>
>     >
> 
> 
> 



Mime
View raw message