tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John-Paul Ranaudo <jrana...@gmail.com>
Subject Re: SSL and non SSL configuration on tomcat 6.0.26, confused
Date Thu, 01 Jul 2010 19:11:55 GMT
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.

Thanks.

On Thu, Jul 1, 2010 at 2:54 PM, Pid <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>> 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>>>> 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>>>> 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>>>> 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>>>
> >     >     >     >> 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>>>
> >     >     >     >>>>
> >     >     >     >>>>
> >     >     >     >>
> >     >     >     >>
> >     >     >     >>
> >     >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >
> >     >
> >     >
> >
> >
> >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message