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 Fri, 02 Jul 2010 07:43:11 GMT
On 01/07/2010 20:11, John-Paul Ranaudo wrote:
> I wish I could provide more information. At least I have narrowed down
> the problem. I am having a meeting with the architects of both
> frameworks today so perhaps I'll get some details.

Given some examples of URLs that fail, and bits of code/HTML/JSP that
are relevant would be a start.


p

> Thanks.
> 
> On Thu, Jul 1, 2010 at 2:54 PM, Pid <pid@pidster.com
> <mailto:pid@pidster.com>> wrote:
> 
>     On 01/07/2010 19:38, John-Paul Ranaudo wrote:
>     > I did more tracing and remote debugging and I was mistaken (too many
>     > late nights). Each framework is sending us the request via port
>     80. The
>     > problem comes from the fact the one of the frameworks uses HTTPS
>     before
>     > the load balancers so when we send back a redirect it is using the
>     wrong
>     > scheme. HTTP instead of HTTPS. I need a way of knowing which framework
>     > made the request so I can alter the scheme on redirect for just
>     the one
>     > framework.
>     >
>     > btw, the frameworks are proprietary and much like existing portal
>     > frameworks.
>     >
>     > So I am wondering if I can do this with virtual hosts or somehow
>     detect
>     > the incoming URL to tell which domain its coming from and handle
>     > appropriately.
> 
>     I wondering too, but mostly because you're not really giving us any real
>     information about what's happening.
> 
>     The word 'framework' might mean something specific to you, but it
>     doesn't help me understand what's happening on your server(s).
> 
>     We can't help you without accurate and detailed information.
> 
> 
>     I /guess/ that virtual hosts won't help you.
> 
>     I /guess/ that the domain it's coming from won't matter so much as the
>     domain requested.
> 
> 
>     p
> 
> 
> 
>     > On Thu, Jul 1, 2010 at 11:31 AM, Pid <pid@pidster.com
>     <mailto:pid@pidster.com>
>     > <mailto:pid@pidster.com <mailto:pid@pidster.com>>> wrote:
>     >
>     >     On 01/07/2010 16:01, John-Paul Ranaudo wrote:
>     >     > 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. /
>     >
>     >     It might help illuminate matters if you explain exactly what
>     Frameworks
>     >     A & B actually are.  Are they separate web applications?  How
>     do they
>     >     relate to each other, are they on separate URLs?
>     >
>     >     > <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.
>     >
>     >     It won't use it unless it's told to.  So what's telling it to?
>     >
>     >     As far as I can see, there's nothing stopping the whole site
>     running
>     >     under 443, which would prevent you seeing mixed content errors.
>     >
>     >     Have you identified exactly which resources are being served
>     via HTTP
>     >     within an HTTPS page?  What are they?
>     >
>     >
>     >     p
>     >
>     >     > 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 <pid@pidster.com
>     <mailto:pid@pidster.com>
>     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>>
>     >     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>
>     <mailto:pid@pidster.com <mailto:pid@pidster.com>>>
>     >     >     > <mailto:pid@pidster.com <mailto:pid@pidster.com>
>     <mailto:pid@pidster.com <mailto:pid@pidster.com>>
>     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>
>     <mailto: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>
>     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>>
>     <mailto:pid@pidster.com <mailto:pid@pidster.com>
>     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>>>
>     >     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>
>     <mailto:pid@pidster.com <mailto:pid@pidster.com>>
>     >     <mailto:pid@pidster.com <mailto:pid@pidster.com>
>     <mailto: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>
>     >     <mailto:chris@christopherschultz.net
>     <mailto:chris@christopherschultz.net>>
>     >     >     <mailto:chris@christopherschultz.net
>     <mailto:chris@christopherschultz.net>
>     >     <mailto:chris@christopherschultz.net
>     <mailto:chris@christopherschultz.net>>>
>     >     >     >     <mailto:chris@christopherschultz.net
>     <mailto:chris@christopherschultz.net>
>     >     <mailto:chris@christopherschultz.net
>     <mailto:chris@christopherschultz.net>>
>     >     >     <mailto:chris@christopherschultz.net
>     <mailto:chris@christopherschultz.net>
>     >     <mailto: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>
>     >     <mailto:users-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>>
>     >     >     <mailto:users-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>
>     >     <mailto:users-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>>>
>     >     >     >     <mailto:users-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>
>     >     <mailto:users-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>>
>     >     >     <mailto:users-unsubscribe@tomcat.apache.org
>     <mailto:users-unsubscribe@tomcat.apache.org>
>     >     <mailto: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>
>     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>>
>     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>
>     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>>>
>     >     >     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>
>     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>>
>     >     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>
>     >     <mailto:users-help@tomcat.apache.org
>     <mailto:users-help@tomcat.apache.org>>>>
>     >     >     >     >>>>
>     >     >     >     >>>>
>     >     >     >     >>
>     >     >     >     >>
>     >     >     >     >>
>     >     >     >     >
>     >     >     >
>     >     >     >
>     >     >     >
>     >     >
>     >     >
>     >     >
>     >
>     >
>     >
> 
> 
> 



Mime
View raw message