Re: HTTP connector to be aware of proxied SSL requests
On 18/06/2010 00:36, Matthew Peterson wrote: > Out of interest, what are some of the security risks around non-trusted > proxies injecting the x-forwarded-* headers? Mainly an issue if you use the RemoteAddressValve or a similar mechanism to secure your webapp based on client IP address. If an untrusted proxy can change the apparent IP address, they can bypass your security. For https/http I'd be worried about untrusted proxies making Tomcat think a requert was received over https was actually insecure. That will change how Tomcat handles session IDs etc and could maybe (I haven't thought this through) lead to the session ID being exposed over http when it should only be sent over hhttps. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP connector to be aware of proxied SSL requests
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:clecl...@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 : ... ... 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 clecl...@xebia.fr http://blog.xebia.fr On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: HTTP connector to be aware of proxied SSL requests
"This is *open* source..." Thx Capt. Obvious - very helpful ;-) OK, so I now understand why it was chosen to perform the redirection in the Connector rather than in a Valve; to remove unnecessary processing keeping the redirect response as efficient as possible. I might lodge an enhancement for the connector to have the redirect configurable so that it can be disabled via an element attribute. The redirecting can then be done as a valve instead. We are using an F5 LB which does not support AJP. So that option will not work for us. The other option of using multiple HTTP Connectors is doable, but adds a lot of config management overhead (and points of possible failure/error) which is not very popular with those responsible for that management. But that is an internal issue which I need to deal with if this prob is deemed to be worth the worry. Out of interest, what are some of the security risks around non-trusted proxies injecting the x-forwarded-* headers? Thanks for your help, Matt. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, 17 June 2010 10:28 PM To: Tomcat Users List Subject: Re: HTTP connector to be aware of proxied SSL requests On 17/06/2010 01:41, Matt Peterson wrote: > 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. This is *open* source... > 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. The other option would be to proxy using AJP rather than HTTP (if the load-balancer supports it) since AJP passes SSL info as part of the protocol. If you want to use mixed HTTP/HTTPS in the LB and just HTTP on Tomcat than multiple connectors is usually what I'd recommend. > 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)? You can, not sure how much traction it would get. Both the logic and configuration is non-trivial to ensure only trusted proxies set the header. We try to keep the connector code fairly slick. This feels like more than we would want to add (bearing in mind this is just instinct - I haven't looked at any code at ths point). You might have better luck with an option to defer the redirection with the / to later in the processing chain. That would be simpler to implement but would add some extra processing that currently is bypassed by doing the rediection as early as possible. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 : ... ... 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 clecl...@xebia.fr http://blog.xebia.fr On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP connector to be aware of proxied SSL requests
On 17/06/2010 01:41, Matt Peterson wrote: > 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. This is *open* source... > 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. The other option would be to proxy using AJP rather than HTTP (if the load-balancer supports it) since AJP passes SSL info as part of the protocol. If you want to use mixed HTTP/HTTPS in the LB and just HTTP on Tomcat than multiple connectors is usually what I'd recommend. > 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)? You can, not sure how much traction it would get. Both the logic and configuration is non-trivial to ensure only trusted proxies set the header. We try to keep the connector code fairly slick. This feels like more than we would want to add (bearing in mind this is just instinct - I haven't looked at any code at ths point). You might have better luck with an option to defer the redirection with the / to later in the processing chain. That would be simpler to implement but would add some extra processing that currently is bypassed by doing the rediection as early as possible. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
