21–30 of 30 posts
Earlier quoted context omitted.
Many places have security policies that require all traffic to be encrypted, even over local networks.
So, a VPN then?
Earlier quoted context omitted.
Who cares though? All connections to SQL servers are going to be localhost or over a VPN, if your setup for postgres has a SSL certificate you're doing something terribly wrong to begin with. I'm not even sure why the option exists to begin with, there's no use case.
Many places have security policies that require all traffic to be encrypted, even over local networks.
Earlier quoted context omitted.
Correct! According to Google, "insecure" means: 1. not firmly fixed; liable to give way or break. 2. (of a person) not confident or assured; uncertain and anxious. and "unsecure": 1. (especially of a computer system) not protected against attack or other criminal activity. 2. (of a loan) unsecured.
Google doesn't source its definition, but all reputable dictionaries I could find disagree: https://www.merriam-webster.com/dictionary/insecure definition 3, https://dictionary.cambridge.org/dictionary/english/insecure definition 2, https://www.collinsdictionary.com/dictionary/english/insecur... definition 2, https://www.oxfordlearnersdictionaries.com/definition/englis... definition 2 Dictionaries have also by and la…
[0]: https://languages.oup.com/google-dictionary-en/ [1]: https://support.google.com/websearch/answer/10106608?
Earlier quoted context omitted.
So, a VPN then?
A VPN generally connects networks, so that’s probably overkill for a database connection, but sure you could use one. Or something like stunnel, etc. or you could just use the built in feature already in Postgres. Why such resistance to simply having this option?
Earlier quoted context omitted.
A VPN generally connects networks, so that’s probably overkill for a database connection, but sure you could use one. Or something like stunnel, etc. or you could just use the built in feature already in Postgres. Why such resistance to simply having this option?
It’s something akin to a layer violation to have a database server running openssl and encrypting its own communication. It isn’t it’s business at all.
I would expect most databases that are listening to public internet connections are doing so by accident
I would expect most databases that are listening to public internet connections are doing so by accident
That sounds like a very good reason to add another security layer like client certificate authentication.
Earlier quoted context omitted.
(co-author) - `prefer` is... not great. That'll silently fall back to an unencrypted connection without warning the user. If you are the one using a programming library directly, you may know that `prefer` does this. If you are using a client that doesn't expose this to you, you may not know that you are using an unencrypted connection after you had set ssl on.
Who cares though? All connections to SQL servers are going to be localhost or over a VPN, if your setup for postgres has a SSL certificate you're doing something terribly wrong to begin with. I'm not even sure why the option exists to begin with, there's no use case.
No, that's a bad take. We should encrypt everything. The reasoning for not doing so in the past was computing power. Nowadays, that's really not a problem. Even my personal servers in my home network are all operating with encrypted links - because why the heck not? At work, everything that can be encrypted is encrypted, otherwise it's a bug. Even if currently 'there's no way' for attackers to get to that particular network. Emphasis on "currently". We shouldn't be a compromise away from leaking everything. Defense in depth.
Plus, the more you are familiar with setting up encryption, the less tempted you are going to be to cut corners when you are setting up something that's at a higher risk.
While I am a security person, and I > At most 15% of the approximately 820,000 PostgreSQL servers listening on the Internet require encryption. No, this is merely the ones that you can scan that are potentially identifiable as Postgres. You're missing a literal ton, and you are probably connecting to most of the PG honeypots in the world, and then making conclusions about the state of all Postgres. Congrats, you fell…
Isn't that what 'default' means? When you have exceptions, you can change from the default.
While I am a security person, and I > At most 15% of the approximately 820,000 PostgreSQL servers listening on the Internet require encryption. No, this is merely the ones that you can scan that are potentially identifiable as Postgres. You're missing a literal ton, and you are probably connecting to most of the PG honeypots in the world, and then making conclusions about the state of all Postgres. Congrats, you fell…
> This is a configurable item, and the idea that everything should always be encrypted all the time may not be true for various use-cases. Isn't that what 'default' means? When you have exceptions, you can change from the default.
If the key intention for a downloadable Postgresql is developer productivity, and the intended environment is local on a laptop communicating to a client local there too, then this would make alot more sense.