In my opinion, disabled by default would be the correct choice except where using x509 certificate and requires server cert verification where it would be okay to enable redirection because an untrusted server should fail the verification.
On Wed, 5 Jul 2023, 2:02 pm Lenski, Daniel via developers, < developers@lists.mariadb.org> wrote: > Hi Georg, > > On Wed, 2023-07-05 at 20:15 +0200, Georg Richter wrote: > > Do you agree it makes sense to have a new error that can tell clients > to go to another server (similar to how HTTP 301 redirects work)? > > > I would very much like to hear your opinion on this one. If you are in > agreement, Daniel can spend more time polishing the feature and also > taking care of implementation details such as preventing redirect > loops and other corner cases. > > > If we want to implement redirection via error message, then the client > needs an option… > > > Done. > > 1. Added to the Connector/C PR in > https://github.com/mariadb-corporation/mariadb-connector-c/pull/226/commits/79722ee186f705714f9c97d98c75b84c3c8903d0 > 2. Added to the mariadb CLI as part of the MariaDB/Server PR, in > https://github.com/MariaDB/server/pull/2681/commits/b43f5909605c8b31cef2215695c3e2d3365ad836 > > … an option to enable redirecting, it should be disabled by default. > > > Why does it make sense for it to be *disabled by default*? > > Again, I'm trying to follow the semantics of HTTP 3xx redirects here. Most > HTTP(S) clients (e.g. web browsers) do follow redirections by default, and > only disable them in specific cases where the server configuration is > broken. For example, if the client encounters a redirect loop, or gets > redirected to a server with an invalid certificate; the latter case has > nothing to do with redirection *per se*. > > The current PR introduces a new vulnerability, since the client redirects > automatically under the hood. > > > Why should automatic redirection be considered a vulnerability? > > If a client, C1, trusts a MariaDB database server, S1, to handle its > queries correctly, then presumably it should *also *trust that server to > tell it to go redirect to another server, S2, and issues its queries to > that alternate server instead. > > This is precisely the logic behind automatic redirection in HTTPS. If I > trust "https://www.search-engine.com/?q=search+terms";, then I shouldn't > mind if the server tells me "go issue this same query to our secondary > server at https://www*2*.search-engine.com/?q=search+terms";. > > If redirection offered an opportunity for untrusted third parties to > redirect to attacker-controlled servers, that *would be a vulnerability*. > And that is precisely why it is crucial to plug the pre-existing > https://jira.mariadb.org/browse/CONC-648 vulnerability while implementing > redirection. > > Thanks, > Daniel > _______________________________________________ > developers mailing list -- developers@lists.mariadb.org > To unsubscribe send an email to developers-le...@lists.mariadb.org >
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
