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)