Re: transport-guarantee secure port configuration
"Max Cooper" <[email protected]> Tue, 6 Nov 2007 19:55:32 -0800
| Newsgroups | gmane.comp.java.securityfilter.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1209764848== Content-Type: multipart/alternative; boundary="----=_Part_3388_23195454.1194407732803" ------=_Part_3388_23195454.1194407732803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline #3 looks like a good option to me as well. It has an additional feature of being app-wide, which would allow other elements in the system to use the parameter to construct URLs using the port if they want to. Also, I agree that ports other than 443 are unlikely on production servers, they are fairly common on development servers, adding some importance to making it configurable. Another aspect of redirecting is that a lot of sites are setup using lousy web server plugins or just a simple proxy, where redirects are not properly rewritten. Here's an illustration of the problem: 1. user's browser requests GET http://www.company.com/ 2. (web server on www.company.com proxies request to internal-server.company.com) 3. (internal-server.company.com requires https, and redirects to https://internal-server.company.com:443/) 4. user's browser requests (in response to the redirect) GET https://internal-server.company.com:443/ and fails because the server is unreachable from the outside This won't happen with a properly setup server configuration, but it has been my experience that it is fairly common for organizations to have this problem. Maybe things have gotten better since I was working in this space, but I doubt it. So, it might be a useful feature to allow securityfilter to be configured with a full "https://www.company.com:443/"-style absolute prefix for the redirects. The absolute prefix could be an advantage over the redirect functionality offered by the containers, for teams with lousy server setups. It does create some issues for app developers during development, when they won't want requests to their dev server to redirect to their public server, but they can handle this with their own app configuration / build systems. And we should also allow just the port to change, to avoid creating headaches for those that do have their servers setup well. Solving this configuration problem is out of scope for securityfilter to deal with, but I wanted to raise awareness of the issue in case you decide to support the configuration of a " https://www.company.com:443/"-style prefix. To recap: 1. we should support just configuring the port a) so it can be set to something other than 443, which is common on dev servers b) so those that have their production servers setup properly don't have to deal with configuring an absolute prefix 2. (optional) it may be additionally useful to support the configuration of an absolute prefix so that the redirects can work with lousy server configs I collaborated on the design of another project called SSLExt ( http://sslext.sf.net) that worked with Struts, allowing developers to set a flag for each action to indicate that it should only execute when the request was over https. Ideally, developers would use the URL rewriting tags so that the URLs would be constructed to hit the https port without needing a redirect. However, it would also redirect requests received over plain http for those actions (that may have been optionally configurable, but I don't remember precisely what the final implementation does). One undesireable aspect of the redirects was that it could send the confidential form data over the wire again. So, sloppy usage could result in confidential data being sent over the wire twice (orig request, redirect response), and it might not be that obvious to developers when this happens. Another important aspect of this is that the data can get stuck in browser history, since a redirect cannot cause a POST and the only other alternative besides keeping the data on the server or just failing is to create a redirect with the data in the query string -- a troubling alternative from a security standpoint. I don't recall what containers (such as tomcat) do in response to plain http requests for urls with transport-guarantee settings that require https, but I think we should try to do the same. Or punt a bit on the first implementation and just fail fast rather than sending the info over the wire again. If the container does something fancy like keep the data on the server and this turns out to be difficult to implement (securely), I think failing is better than sending the data over the wire again. -Max On 11/6/07, Torgeir Veimo <[email protected]> wrote: > > > On 6 Nov 2007, at 22:59, Christopher Schultz wrote: > > > On the one hand, it's nice to have configuration in a single place > > (like > > securityfilter-config.xml). On the other hand, that file should be as > > much like the deployment descriptor's security-constraint sections as > > possible. > > > > I wondered if anyone had any thoughts on which strategy would be best. > > I'm leaning toward #3. > > > +1. I'd go for #3 as well. Setting the SL port to something else than > 443 I'd say would happen very rarely. > > -- > Torgeir Veimo > [email protected] > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > securityfilter-devel mailing list > securityfilter-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/securityfilter-devel > ------=_Part_3388_23195454.1194407732803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline #3 looks like a good option to me as well. It has an additional feature of being app-wide, which would allow other elements in the system to use the parameter to construct URLs using the port if they want to. Also, I agree that ports other than 443 are unlikely on production servers, they are fairly common on development servers, adding some importance to making it configurable. <br><br><br><br>Another aspect of redirecting is that a lot of sites are setup using lousy web server plugins or just a simple proxy, where redirects are not properly rewritten. Here's an illustration of the problem:<br> 1. user's browser requests GET <a href="http://www.company.com/">http://www.company.com/</a><br>2. (web server on <a href="http://www.company.com">www.company.com</a> proxies request to <a href="http://internal-server.company.com"> internal-server.company.com</a>)<br>3. (<a href="http://internal-server.company.com">internal-server.company.com</a> requires https, and redirects to <a href="https://internal-server.company.com:443/">https://internal-server.company.com:443/ </a>)<br>4. user's browser requests (in response to the redirect) GET <a href="https://internal-server.company.com:443/">https://internal-server.company.com:443/</a> and fails because the server is unreachable from the outside <br>This won't happen with a properly setup server configuration, but it has been my experience that it is fairly common for organizations to have this problem. Maybe things have gotten better since I was working in this space, but I doubt it. So, it might be a useful feature to allow securityfilter to be configured with a full " <a href="https://www.company.com:443/">https://www.company.com:443/</a>"-style absolute prefix for the redirects. The absolute prefix could be an advantage over the redirect functionality offered by the containers, for teams with lousy server setups. It does create some issues for app developers during development, when they won't want requests to their dev server to redirect to their public server, but they can handle this with their own app configuration / build systems. And we should also allow just the port to change, to avoid creating headaches for those that do have their servers setup well. Solving this configuration problem is out of scope for securityfilter to deal with, but I wanted to raise awareness of the issue in case you decide to support the configuration of a " <a href="https://www.company.com:443/">https://www.company.com:443/</a>"-style prefix.<br><br>To recap:<br>1. we should support just configuring the port<br>a) so it can be set to something other than 443, which is common on dev servers <br>b) so those that have their production servers setup properly don't have to deal with configuring an absolute prefix<br>2. (optional) it may be additionally useful to support the configuration of an absolute prefix so that the redirects can work with lousy server configs <br><br>I collaborated on the design of another project called SSLExt (<a href="http://sslext.sf.net">http://sslext.sf.net</a>) that worked with Struts, allowing developers to set a flag for each action to indicate that it should only execute when the request was over https. Ideally, developers would use the URL rewriting tags so that the URLs would be constructed to hit the https port without needing a redirect. However, it would also redirect requests received over plain http for those actions (that may have been optionally configurable, but I don't remember precisely what the final implementation does). One undesireable aspect of the redirects was that it could send the confidential form data over the wire again. So, sloppy usage could result in confidential data being sent over the wire twice (orig request, redirect response), and it might not be that obvious to developers when this happens. Another important aspect of this is that the data can get stuck in browser history, since a redirect cannot cause a POST and the only other alternative besides keeping the data on the server or just failing is to create a redirect with the data in the query string -- a troubling alternative from a security standpoint.<br> <br> I don't recall what containers (such as tomcat) do in response to plain http requests for urls with transport-guarantee settings that require https, but I think we should try to do the same. Or punt a bit on the first implementation and just fail fast rather than sending the info over the wire again. If the container does something fancy like keep the data on the server and this turns out to be difficult to implement (securely), I think failing is better than sending the data over the wire again.<br><br>-Max<br><br><div><span class="gmail_quote">On 11/6/07, <b class="gmail_sendername">Torgeir Veimo</b> <<a href="mailto:[email protected]">[email protected]</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br>On 6 Nov 2007, at 22:59, Christopher Schultz wrote:<br><br>> On the one hand, it's nice to have configuration in a single place<br>> (like<br>> securityfilter-config.xml). On the other hand, that file should be as <br>> much like the deployment descriptor's security-constraint sections as<br>> possible.<br>><br>> I wondered if anyone had any thoughts on which strategy would be best.<br>> I'm leaning toward #3. <br><br><br>+1. I'd go for #3 as well. Setting the SL port to something else than<br>443 I'd say would happen very rarely.<br><br>--<br>Torgeir Veimo<br><a href="mailto:[email protected]">[email protected]</a><br> <br><br><br><br>-------------------------------------------------------------------------<br>This SF.net email is sponsored by: Splunk Inc.<br>Still grepping through log files to find problems? Stop.<br>Now Search log events and configuration files using AJAX and a browser. <br>Download your FREE copy of Splunk now >> <a href="http://get.splunk.com/">http://get.splunk.com/</a><br>_______________________________________________<br>securityfilter-devel mailing list<br><a href="mailto:securityfilter-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"> securityfilter-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org</a><br><a href="https://lists.sourceforge.net/lists/listinfo/securityfilter-devel">https://lists.sourceforge.net/lists/listinfo/securityfilter-devel</a><br></blockquote></div><br> ------=_Part_3388_23195454.1194407732803-- --===============1209764848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1209764848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ securityfilter-devel mailing list securityfilter-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/securityfilter-devel --===============1209764848==--