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 07:49:19 GMT
No we are not.

On 7/1/10, Pid <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> 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
> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>
>
>

-- 
Sent from my mobile device

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message