Earlier quoted context omitted.
> configure a root cert and use verify-full Edit: The interpretation below is incorrect, see the answers to understand why. I don't understand why the post insists on using self signed certificates and ?sslmode=verify-*. It's MitM-prone by design. Just use ?sslmode=require and a CA-issued certificate. It's even easier than with a webserver and clients can identify that you are the domain you pretend to be. Obviously…
> Just use ?sslmode=require and a CA-issued certificate. This is not secure. See Table 31-1 here: https://www.postgresql.org/docs/9.5/static/libpq-ssl.html#LI... As you can see, "require" provides no MitM protection. The only option among the six options that provides both eavesdropping and MitM protection under all scenarios is "verify-full". Your misunderstanding is reasonable, and shows what can happen when softwa…
MitM-ing Postgres
11–16 of 16 posts
Re: MitM-ing Postgres
#12Earlier quoted context omitted.
> Just use ?sslmode=require and a CA-issued certificate. This is not secure. See Table 31-1 here: https://www.postgresql.org/docs/9.5/static/libpq-ssl.html#LI... As you can see, "require" provides no MitM protection. The only option among the six options that provides both eavesdropping and MitM protection under all scenarios is "verify-full". Your misunderstanding is reasonable, and shows what can happen when softwa…
he is not incorrect. if you are on a secure network you can stick with the default i.e. a aws network could be secure.
Re: MitM-ing Postgres
#13Correct me if I am wrong, but this doesn't sound like a problem with Postgres. It seems like a problem with the author's specific implementation (self-signed certificates) specifically on Heroku. Anyone else take something else away from this piece?
The blog post raises several distinct issues. Heroku's poor configuration is the most significant issue, but it's also concerning that Postgres is insecure by default, and supports several different options to sslmode with confusingly-similar names, only one of which is secure under normal circumstances. That's a recipe for developers and database administrators to shoot themselves in the foot. If Postgres had been s…
Re: MitM-ing Postgres
#14Earlier quoted context omitted.
he is not incorrect. if you are on a secure network you can stick with the default i.e. a aws network could be secure.
tajen advocated a CA-issued certificate along with the "require" option, which makes sense under no common scenario. If your network really is secure, you don't need TLS at all, so you can use "disable" and not bother with a cert. If your network isn't secure, then you need "verify-full" to actually have security.
Re: MitM-ing Postgres
#15Earlier quoted context omitted.
> Just use ?sslmode=require and a CA-issued certificate. This is not secure. See Table 31-1 here: https://www.postgresql.org/docs/9.5/static/libpq-ssl.html#LI... As you can see, "require" provides no MitM protection. The only option among the six options that provides both eavesdropping and MitM protection under all scenarios is "verify-full". Your misunderstanding is reasonable, and shows what can happen when softwa…
he is not incorrect. if you are on a secure network you can stick with the default i.e. a aws network could be secure.
I'd suggest avoiding shortcuts and using certificates.