Re: Should I enforce ssl/local socket use?

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