On 01/07/2010 14:49, John-Paul Ranaudo wrote:
> That wont work either because like I said before, the application is no=
t
> really using SSL. The SSL is handled by the load balancers.=20
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=3D"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:
>=20
> On 01/07/2010 08:49, John-Paul Ranaudo wrote:
> > No we are not.
>=20
> 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'.
>=20
> The container will automatically upgrade a matching request to HTTP=
S by
> redirecting it to the port configured in 'redirectPort' on the HTTP=
> connector.
>=20
>=20
> p
>=20
> > 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 th=
e
> wrong
> >>> scheme (HTTP). So here is my current configuration:
> >>>
> >>> <Connector port=3D"80" protocol=3D"HTTP/1.1"
> connectionTimeout=3D"20000" />
> >>> <Connector port=3D"443" protocol=3D"HTTP/1.1" connectionTimeout=
=3D"20000"
> >>> scheme=3D"https" secure=3D"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 an=
d 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 (certificate=
s
> etc)
> >>>>>> since
> >>> my
> >>>>>> load balancer is decoding the connection. So even if the
loa=
d
> balancer
> >>>>>> is
> >>>>>> "decoding" the connection I still have to have SSLEnabled=3D=
"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 "connecti=
on"?
> >>>
> >>> Yes, setting SSLEnabled=3D"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 b=
e
> able to
> >>> do it like this:
> >>>
> >>> <Connector
> >>> port=3D"443" <- this is the port that the LB talks to
> >>> protocol=3D"HTTP/1.1"
> >>> connectionTimeout=3D"20000"
> >>> scheme=3D"https" <- so request.getScheme returns correct valu=
e
> >>> secure=3D"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 f=
airly
> >>>>>> obvious
> >>>>>> but "secure" it confusing. Not sure under what context I
nee=
d
> to set
> >>> this.
> >>>
> >>> You can set these to different values, for instance, to instruc=
t 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 w=
ebapp
> >>> 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 th=
e
> port on
> >>> the load-balancer the client will hit, not necessarily the port=
> on the
> >>> local machine. The following configuration is perfectly legitim=
ate:
> >>>
> >>> <!-- non-secure connector -->
> >>> <Connector
> >>> port=3D"8080"
> >>> protocol=3D"HTTP/1.1"
> >>> connectionTimeout=3D"20000"
> >>> redirectPort=3D"443"
> >>> />
> >>>
> >>> <!-- secure connector -->
> >>> <Connector
> >>> port=3D"8443"
> >>> protocol=3D"HTTP/1.1"
> >>> connectionTimeout=3D"20000"
> >>> scheme=3D"https" <- so request.getScheme returns correct valu=
e
> >>> secure=3D"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=3D"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>
> >>>>
> >>>>
> >>
> >>
> >>
> >
>=20
>=20
>=20
|