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

On Sat, Jun 6, 2020 at 1:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michel Pelletier <pelletier.michel@gmail.com> writes:

I'm the author of the pgsodium cryptography library. I have a question

Any thoughts? Is this an insufferably rude attitude?

I would say yes.

I'd say that settles it then, thank you!

-Michel

Michel Pelletier <pelletier.michel@gmail.com> writes:

Hello,

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? Are there scenarios
where one can foresee needing to generate secrets not over ssl or a domain
socket?

I'm never very fond of enforcing a particular behaviour as it assumes we
understand all environments and use cases. Far better to make this the
default behaviour, but allow users to disable it if they want and
clearly document that option as insecure. I also suspect that without
the ability to somehow disable the checks, people will find elaborate
ways to work around them which are almost certainly going to be even
worse from a security perspective.

--
Tim Cross

On Sun, Jun 7, 2020 at 10:32:39AM +1000, Tim Cross wrote:

Michel Pelletier <pelletier.michel@gmail.com> writes:

Hello,

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? Are there scenarios
where one can foresee needing to generate secrets not over ssl or a domain
socket?

I'm never very fond of enforcing a particular behaviour as it assumes we
understand all environments and use cases. Far better to make this the
default behaviour, but allow users to disable it if they want and
clearly document that option as insecure. I also suspect that without
the ability to somehow disable the checks, people will find elaborate
ways to work around them which are almost certainly going to be even
worse from a security perspective.

You also have to allow a way to disable it that is secure or it is
useless, which makes it even more complex.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee