Michel Pelletier <pelletier.michel@xxxxxxxxx> writes: > I'm the author of the pgsodium cryptography library. I have a question > about a best practice I'm thinking of enforcing. Several functions in > pgsodium generate secrets, I want to check the Proc info to enforce that > those functions can only be called using a local domain socket or an ssl > connection. If the connection isn't secure by that definition, secret > generating functions will fail. > If someone really wants to point the gun at their foot, they can connect > with an unsecured proxy. My goal would be to make bypassing the check > annoying. > Any thoughts? Is this an insufferably rude attitude? I would say yes. How do your functions know that their outputs are going to be transmitted to the client at all? Even if the current session doesn't, what would stop a user from storing the results in a table and then reading them out over an insecure connection later? Besides which, you can't really tell this way how secure or insecure the connection is. (As a concrete example, the security of a non-SSL connection over localhost is probably not much worse than over Unix-domain socket.) > Are there scenarios > where one can foresee needing to generate secrets not over ssl or a domain > socket? Windows users, who lack the Unix-domain option, would probably find it quite annoying to be forced to use SSL for local connections. regards, tom lane
