5 ms·

The Majority of PostgreSQL Servers on the Internet Are Insecure

49 points by teichmann 4y ago

koollman 4y ago
That's a strange take on the subject of db servers and ssl usage. Most db servers shouldn't be accessible on internet, which skews the announced result a lot. And, obviously, clients and servers generally won't require ssl by default, because it would make no sense in most situations. (but at least the 'prefer' default setting is mentionned) Requiring a certificate to run the server isn't something that is likely to become the default setting for a while...
- _bohm 4y ago
  I think the announced results are specifically referring to servers available on the internet.
  - OJFord 4y ago
    That's GP's point, that's already a 'smell' (in the strict 'hm, that seems suspiciously like it might not be right' sense).
  - deleted 4y ago
    [deleted]
- adam_gyroscope 4y ago
  (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.
  - mistrial9 4y ago
    do you understand that Postgres devs have been all over this since (likely) the time you were born? The conventional, real and actual servers that matter are generally not at all visible on the Internet, period. Because they know this.. its like this paper tests servers that dont care, and declare the entire product unsecure. Bad take, scare-mongering
  - RL_Quine 4y ago
    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.
    - orev 4y ago
      Many places have security policies that require all traffic to be encrypted, even over local networks.
      - RL_Quine 4y ago
        So, a VPN then?
        orev 4y ago
        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?
        RL_Quine 4y ago
        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.
        imtringued 4y ago
        This is one of the most disappointing hackernews submissions I have seen in a while. I use a private CA and client certificate authentication. It might be overkill but it is easy to implement.
      - thayne 4y ago
        So in that case, require ssl. But, that probably shouldn't be the default.
- chasil 4y ago
  Still, Oracle is the worst. All the SQL transit is cleartext by default. A "wallet" can be defined for TLS, but the Oracle Instant Client doesn't (appear to) support this functionality. I push all my local Oracle database links over stunnel. Oracle SQL Developer even has an SSH pane, because wallets are so very unusable.
meken 4y ago
* unsecure
- levkk 4y ago
  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.
  - dave_universetf 4y ago
    Google doesn't source its definition, but all reputable dictionaries I could find disagree: https://www.merriam-webster.com/dictionary/insecure https://www.merriam-webster.com/dictionary/insecure definition 3, https://dictionary.cambridge.org/dictionary/english/insecure https://dictionary.cambridge.org/dictionary/english/insecure definition 2, https://www.collinsdictionary.com/dictionary/english/insecure https://www.collinsdictionary.com/dictionary/english/insecur... definition 2, https://www.oxfordlearnersdictionaries.com/definition/english/insecure https://www.oxfordlearnersdictionaries.com/definition/englis... definition 2 Dictionaries have also by and large given up on prescriptivism. The correct use of language is the way language is being used, with dictionaries trailing and recording consensus reality, not defining it.
    - doodlesdev 4y ago
      Google's dictionary is sourced from Oxford Languages, at least for the English dictionary [0][1]. [0]: https://languages.oup.com/google-dictionary-en/ https://languages.oup.com/google-dictionary-en/ [1]: https://support.google.com/websearch/answer/10106608 https://support.google.com/websearch/answer/10106608?
beep_boop_beep_ 4y ago
Maybe they’re insecure because they’re unsecured?
inopinatus 4y ago
Unfortunately the clickbait headline does not convey the enormous streetlight-effect skew in the sample. This article is essentially content marketing for a DBaaS company, for which the author appears to serve as CTO, to promote a alternative default configuration that favours their business model.
tomrod 4y ago
Is a reasonable interpretation here that SSL is hard?
eric4smith 4y ago
PostgreSQL by itself is hard to put on the internet. The pg_hba file goes out or it’s way to make it difficult to even connect locally easily. Nevertheless you would do it so that your db server can be reached by the other machines. Sigh. I suppose not fire-walling everything would be someone’s own fault. And not setting proper passwords. And not turning on SSL.
Areading314 4y ago
I would expect most databases that are listening to public internet connections are doing so by accident
- imtringued 4y ago
  That sounds like a very good reason to add another security layer like client certificate authentication.
  - Areading314 4y ago
    Not really. Most of the time setting up a segregated network architecture is actually easier than dealing with encrypted database connections -- certificate management is by nature dynamic vs. the static nature of a secure network
OrvalWintermute 4y ago
While I am a security person, and I <3 Postgres, there are assumptions in this article that are false in this marketing masquerading as an article. > 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 for a trap! > most popular SQL clients are more than happy to accept unencrypted connections without a warning 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. While secure by default is a consideration, I'd dare say that the likely use-case is more so get Postgres running on a developer machine, connect to it locally, only! > Connections to servers with self-signed certificates are encrypted, but the certificates often do not confer trust: generally, they are neither issued nor validated by a certificate authority, they don’t expire, and they can’t be revoked. There is another giant assumption in this case, that a self-signed, enterprise, or private PKI is a bad one. Foremost it may be self-signed because that is the standard for honeypots. But the idea that self-signed is bad is not just false, it is actually wrong . Because many public PKIs, particularly ones adherent to CAB, are making trades that may be good for general use, but are very bad for specific other use-cases. To add to that, when you see a private PKI, an enterprise PKI, etc, you don't know if they can be revoked, or can't be revoked because you don't have access to the PKI internals, and you don't know them. I doubt many public CAs have the security characteristics I've seen in private PKIs around attack resistance, existence on multiple networks, splitting CA and VA functions, using high assurance functions for those interacting with the PKI, and willingness to invest in the correct hardware and proper staff to operate it. Most private PKIs distribute and configure trust stores as a part of an enterprise or govt function, but how they do that does not mean secure or insecure automatically. However, given that they are not configured to fail open like most of the internet, and much of the private PKIs are highly regulated, I cannot concur with the idea that private is bad. Some private PKIs are actually far more secure than public CAs because they are redundant in a way that Commercial CAs generally are not, given their mission to support Operational Technology, ICS/SCADA, among other things. Right now, the CAB forum has some pretty weak activities written into their procedures. 2FA phishing resistant MFA? NOPE! A CAB Forum CA recently admitted as much "we'd love to move to more secure authentication procedures but we are constrained by CAB". So, they are making insecure phone calls verifying things, creating certs based in part off a phone call. What a joke! Most of the article just touches on encryption, languages using TLS, and Authentication only. There is alot more to Postgres security than just AuthN, and there is no mention of the platform upon which it runs. For example there is the DISA STIG for Postgres [1] and a CIS Benchmark also [2] and a CIS Prehardened Image [3] for running it in the cloud There are lots of guides on automating this [4] There are even pre-secured Postgres databases with nifty security features [5] More than all of these references though, Postgres has a great community that is available on IRC [6] that is highly willing to help you work through some of these options for your own. Long ago I got a great deal of help when working on PG, and they are a truly awesome group. [1] https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_PGS_SQL_9-x_V2R3_STIG.zip https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_PGS_... && https://www.stigviewer.com/stig/postgresql_9.x/ https://www.stigviewer.com/stig/postgresql_9.x/ [2] https://www.cisecurity.org/cis-benchmarks/ https://www.cisecurity.org/cis-benchmarks/ [3] https://www.cisecurity.org/cis-hardened-image-list/ https://www.cisecurity.org/cis-hardened-image-list/ [4] https://medium.com/hackernoon/automate-implementing-the-disa-stig-for-postgresql-a7e3267c83d0 https://medium.com/hackernoon/automate-implementing-the-disa... [5] https://www.crunchydata.com/products/hardened-postgres https://www.crunchydata.com/products/hardened-postgres [6] https://www.postgresql.org/community/irc/ https://www.postgresql.org/community/irc/

49 points by teichmann 4y ago

That's a strange take on the subject of db servers and ssl usage. Most db servers shouldn't be accessible on internet, which skews the announced result a lot. And, obviously, clients and servers generally won't require ssl by default, because it would make no sense in most situations. (but at least the 'prefer' default setting is mentionned) Requiring a certificate to run the server isn't something that is likely to become the default setting for a while...

_bohm 4y ago
I think the announced results are specifically referring to servers available on the internet.
- OJFord 4y ago
  That's GP's point, that's already a 'smell' (in the strict 'hm, that seems suspiciously like it might not be right' sense).
- deleted 4y ago
  [deleted]
adam_gyroscope 4y ago
(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.
- mistrial9 4y ago
  do you understand that Postgres devs have been all over this since (likely) the time you were born? The conventional, real and actual servers that matter are generally not at all visible on the Internet, period. Because they know this.. its like this paper tests servers that dont care, and declare the entire product unsecure. Bad take, scare-mongering
- RL_Quine 4y ago
  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.
  - orev 4y ago
    Many places have security policies that require all traffic to be encrypted, even over local networks.
    - RL_Quine 4y ago
      So, a VPN then?
      - orev 4y ago
        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?
        RL_Quine 4y ago
        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.
        imtringued 4y ago
        This is one of the most disappointing hackernews submissions I have seen in a while. I use a private CA and client certificate authentication. It might be overkill but it is easy to implement.
    - thayne 4y ago
      So in that case, require ssl. But, that probably shouldn't be the default.
chasil 4y ago
Still, Oracle is the worst. All the SQL transit is cleartext by default. A "wallet" can be defined for TLS, but the Oracle Instant Client doesn't (appear to) support this functionality. I push all my local Oracle database links over stunnel. Oracle SQL Developer even has an SSH pane, because wallets are so very unusable.

meken 4y ago

* unsecure

levkk 4y ago
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.
- dave_universetf 4y ago
  Google doesn't source its definition, but all reputable dictionaries I could find disagree: https://www.merriam-webster.com/dictionary/insecure https://www.merriam-webster.com/dictionary/insecure definition 3, https://dictionary.cambridge.org/dictionary/english/insecure https://dictionary.cambridge.org/dictionary/english/insecure definition 2, https://www.collinsdictionary.com/dictionary/english/insecure https://www.collinsdictionary.com/dictionary/english/insecur... definition 2, https://www.oxfordlearnersdictionaries.com/definition/english/insecure https://www.oxfordlearnersdictionaries.com/definition/englis... definition 2 Dictionaries have also by and large given up on prescriptivism. The correct use of language is the way language is being used, with dictionaries trailing and recording consensus reality, not defining it.
  - doodlesdev 4y ago
    Google's dictionary is sourced from Oxford Languages, at least for the English dictionary [0][1]. [0]: https://languages.oup.com/google-dictionary-en/ https://languages.oup.com/google-dictionary-en/ [1]: https://support.google.com/websearch/answer/10106608 https://support.google.com/websearch/answer/10106608?

beep_boop_beep_ 4y ago

Maybe they’re insecure because they’re unsecured?

inopinatus 4y ago

Unfortunately the clickbait headline does not convey the enormous streetlight-effect skew in the sample. This article is essentially content marketing for a DBaaS company, for which the author appears to serve as CTO, to promote a alternative default configuration that favours their business model.

tomrod 4y ago

Is a reasonable interpretation here that SSL is hard?

eric4smith 4y ago

PostgreSQL by itself is hard to put on the internet. The pg_hba file goes out or it’s way to make it difficult to even connect locally easily. Nevertheless you would do it so that your db server can be reached by the other machines. Sigh. I suppose not fire-walling everything would be someone’s own fault. And not setting proper passwords. And not turning on SSL.

Areading314 4y ago

I would expect most databases that are listening to public internet connections are doing so by accident

imtringued 4y ago
That sounds like a very good reason to add another security layer like client certificate authentication.
- Areading314 4y ago
  Not really. Most of the time setting up a segregated network architecture is actually easier than dealing with encrypted database connections -- certificate management is by nature dynamic vs. the static nature of a secure network

OrvalWintermute 4y ago

While I am a security person, and I <3 Postgres, there are assumptions in this article that are false in this marketing masquerading as an article. > 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 for a trap! > most popular SQL clients are more than happy to accept unencrypted connections without a warning 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. While secure by default is a consideration, I'd dare say that the likely use-case is more so get Postgres running on a developer machine, connect to it locally, only! > Connections to servers with self-signed certificates are encrypted, but the certificates often do not confer trust: generally, they are neither issued nor validated by a certificate authority, they don’t expire, and they can’t be revoked. There is another giant assumption in this case, that a self-signed, enterprise, or private PKI is a bad one. Foremost it may be self-signed because that is the standard for honeypots. But the idea that self-signed is bad is not just false, it is actually wrong . Because many public PKIs, particularly ones adherent to CAB, are making trades that may be good for general use, but are very bad for specific other use-cases. To add to that, when you see a private PKI, an enterprise PKI, etc, you don't know if they can be revoked, or can't be revoked because you don't have access to the PKI internals, and you don't know them. I doubt many public CAs have the security characteristics I've seen in private PKIs around attack resistance, existence on multiple networks, splitting CA and VA functions, using high assurance functions for those interacting with the PKI, and willingness to invest in the correct hardware and proper staff to operate it. Most private PKIs distribute and configure trust stores as a part of an enterprise or govt function, but how they do that does not mean secure or insecure automatically. However, given that they are not configured to fail open like most of the internet, and much of the private PKIs are highly regulated, I cannot concur with the idea that private is bad. Some private PKIs are actually far more secure than public CAs because they are redundant in a way that Commercial CAs generally are not, given their mission to support Operational Technology, ICS/SCADA, among other things. Right now, the CAB forum has some pretty weak activities written into their procedures. 2FA phishing resistant MFA? NOPE! A CAB Forum CA recently admitted as much "we'd love to move to more secure authentication procedures but we are constrained by CAB". So, they are making insecure phone calls verifying things, creating certs based in part off a phone call. What a joke! Most of the article just touches on encryption, languages using TLS, and Authentication only. There is alot more to Postgres security than just AuthN, and there is no mention of the platform upon which it runs. For example there is the DISA STIG for Postgres [1] and a CIS Benchmark also [2] and a CIS Prehardened Image [3] for running it in the cloud There are lots of guides on automating this [4] There are even pre-secured Postgres databases with nifty security features [5] More than all of these references though, Postgres has a great community that is available on IRC [6] that is highly willing to help you work through some of these options for your own. Long ago I got a great deal of help when working on PG, and they are a truly awesome group. [1] https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_PGS_SQL_9-x_V2R3_STIG.zip https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_PGS_... && https://www.stigviewer.com/stig/postgresql_9.x/ https://www.stigviewer.com/stig/postgresql_9.x/ [2] https://www.cisecurity.org/cis-benchmarks/ https://www.cisecurity.org/cis-benchmarks/ [3] https://www.cisecurity.org/cis-hardened-image-list/ https://www.cisecurity.org/cis-hardened-image-list/ [4] https://medium.com/hackernoon/automate-implementing-the-disa-stig-for-postgresql-a7e3267c83d0 https://medium.com/hackernoon/automate-implementing-the-disa... [5] https://www.crunchydata.com/products/hardened-postgres https://www.crunchydata.com/products/hardened-postgres [6] https://www.postgresql.org/community/irc/ https://www.postgresql.org/community/irc/