Michel Pelletier <pelletier.michel@gmail.com> 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