Thread: Should I enforce ssl/local socket use?
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?
-Michel
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