Re: [securityfilter-devel] transport-guarantee secure port configuration

[Max C. <ma...@ma...>]

#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 <to...@po...> 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
> to...@po...
>
>
>
>
> -------------------------------------------------------------------------
> 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
> sec...@li...
> https://lists.sourceforge.net/lists/listinfo/securityfilter-devel
>