Redirect loops and mazes

On Mon, Oct 14, 2019 at 07:24:59PM -0400, Sean Conner wrote:
>   Possible actions:
> 
> 	client denies the redirect
> 	client denies redirects to non TLS-protocols
> 		otherwise, redirects
> 	client asks to redirect or not
> 	client asks to redirect to non-TLS protocol,
> 		othersise redirects,
> 	client warns user about redirect
> 	client warns user about redirect to non-TLS protocol
> 	client does redirect
> 

Those seem to be all the sensible options.

My initial instinct was to say something along the lines of: explicitly
prohibiting the scariest possible kind of redirect in the spec permits
client writers to take the easier route (both in terms of implementation
effort and smoothness of user experience) of automatically following
redirects with the understanding that the risk posed is minimal.

But that's not quite true, actually.  Just because the spec says
cross-protocol redirects are forbidden doesn't mean malicious servers
couldn't serve them up anyway.  So well-written clients need to be on
the lookout for this anyway, no matter what the spec says.  I guess at
the very least this point should be mentioned in the Best Practices doc
so it's not overlooked by client iplementors.

This is not to say it isn't still worthwhile forbidding them in the
spec.  I think I'm still inclined to do this if nobody comes forward
with a compelling use case.

-Solderpunk

---

Previous in thread (13 of 17): 🗣️ Sean Conner (sean (a) conman.org)

Next in thread (15 of 17): 🗣️ Sean Conner (sean (a) conman.org)

View entire thread.