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 15:01:45 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message