tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Peterson <matt.peter...@une.edu.au>
Subject RE: HTTP connector to be aware of proxied SSL requests
Date Fri, 18 Jun 2010 00:45:12 GMT
Hi Cyrille,

We have the RemoteIpValve implemented already, thanks. The behaviour we are seeing is occurring
in the Connector, before the request even reaches the valves. In this case, the request never
reaches the valves as the redirect is done within the connector.

Cheers,
Matt.

-----Original Message-----
From: Cyrille Le Clerc [mailto:cleclerc@xebia.fr] 
Sent: Friday, 18 June 2010 8:30 AM
To: Tomcat Users List; Matthew Peterson
Subject: Re: HTTP connector to be aware of proxied SSL requests

Hello Matt,

I think the RemoteIpValve does what you need : it looks at http
headers filled in the request by preceding network components (layer 7
load balancer, ssl accelerator, etc) such as 'x-forwarded-for' to get
the real ip address and 'x-forwarded-proto' to get the http/https
protocol. A concept of internal/trusted incoming proxies is used to
decide weither the http headers can be trusted or not.

Configuration is detailed in the javadocs :
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
The documentation of RemoteIpValve has been enhanced in Tomcat 7 to
integrate the content of the java doc.

I wrote a blog post in french to explain how it works with detailed
diagrams here :
http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/

Basically, if you want to trust http header x-forwarded-for and
x-forwarded-proto coming from LB/web-server 192.168.0.10 and
192.168.0.11, the valve configuration will look like :

<Server ...>
   ...
   <Service name="Catalina">
      <Connector ... />
      <Engine ...>
         <!-- Process X-Forwarded-For to get remote address and
X-Forwarded-Proto to identify SSL requests -->
         <Valve
               className="org.apache.catalina.valves.RemoteIpValve"
               internalProxies="192\.168\.0\.10, 192\.168\.0\.11"
               protocolHeader="X-Forwarded-Proto" />

         <!-- AccessLogValve must be declared after RemoteIpValve to
get the remote address and the scheme https/http -->
         <Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" pattern="common" prefix="access_log."
            resolveHosts="false" suffix=".txt" />

         ...
         </Host>
      </Engine>
   </Service>
</Server>

Please note that you can simplify the configuration omitting
'internalProxies' attribute and rely on the default that trusts all
the class A, B & C private IP addresses.

Hope this helps,

Cyrille

--
Cyrille Le Clerc
cleclerc@xebia.fr
http://blog.xebia.fr


On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson <matt.peterson@une.edu.au> wrote:
>
> Hi All,
>
>
>
> We have a hardware load balancer terminating SSL requests before making a
> plain-text connection with Tomcat. So that all contexts are aware that the
> request is actually a secure request, we have implemented the RemoteIpValve
> with a LB injected header. This works well for our apps. However, we have
> noticed that there is some processing of the request happening within the
> connector, before the valves are processed. In particular, the redirecting
> to URLs with a trailing slash. Because this processing is occurring before
> the valves are processed the Connector still thinks that the original
> request was a non-secure one, even though it was not. The result is that
> requests to https://domain.name/context are redirected to
> http://domain.name/context/ instead of to https://domain.name/context/. This
> is not major, because our LB then redirects from http://domain.name/context/
> to https://domain.name/context/ and all is good (except for the extra
> redirect).
>
>
>
> I can't find any documentation on the order of events for the Connector, so
> I'm not sure what other decisions get made based on the request attributes,
> but assume there are others.
>
>
>
> Is there another solution to handling proxied SSL requests so that Catalina
> as well as our apps are aware that the requests are secure??? One
> possibility is to have two Connectors (1 using the secure, scheme and
> serverPort attributes for secure and 1 for non-secure) and have the LB
> connect to the appropriate Connector depending on the request. But this
> effectively doubles the amount of config needed to be managed (2nd set of
> config for LB + 2nd connector), which is considerable when dealing with 6 TC
> clusters each with their own set of LB config.
>
>
>
> Should I lodge an enhancement request for the Connector to become aware of
> proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala
> WebLogic)?
>
>
>
> Cheers,
>
> Matt.
>

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


Mime
View raw message