Add various SSL modes

[ghivert]

Hi!

Continuing on my work on PGO, I think it would be better to support the diverse options supported by PG, to try to get a 1:1 support of connection strings, but also to solve common problems when people don't know how to handle CA certificates. More arguments:

As I suspected here, but it seems to be a common issue across PG users. For example, node-pg assumes user is in mode sslmode=require when activating SSL. Digital Ocean too recommend to use sslmode=require by default. If we don't support the different modes, I'm afraid we'll have a lot of issues because providers assumes whether users are powerful DevOps, able to manage CA certificates by hand, or they will just bypass SSL security. Or we'll have a lot of education to do.

Talking about education, while I think it's important to let users be able to do what they want, I think it's important to do things right on security. README now includes a full section on SSL, and how it should be configured. I'm not sure it's desired here. Maybe we should have it in a separated doc, and reference it in gleam.toml docs section? I'm afraid people won't read it then. 😂

[lpil]

Hello! Thank you for this and the detail you've gone into here.

After reading the documentation I no longer know what the correct configuration is. Why is it that it's called verify and enabled when the others talk of a "require"? How do they match up? What's the optimal configuration?

[ghivert]

If you're not able to understand the correct configuration by reading the README, it means the README is badly worded! I'll cook another version and come back with it 🙂

---

To answer your question, psql defines some sslmode which seems to can't be mapped to Erlang easily, and which does not make much sense in my opinion. require is "SSL activated, not checking CA certificate", verify-full and verify-ca are "SSL activated, checking CA certificate", but there's some subtleties. Documentation is here, table 34.1. I find the difference between the two rather unclear, and I think verify-ca and verify-full can't be easily distinguished with Erlang.
Reworded, require => {verify, verify_none} while verify-full => {verify, verify_peers}. The best configuration is always verify-full. But require allow to skip CA cert validation (and so, injection of CA cert in your OS).

I wanted to stick with standard PG connection URI, so that's why there's require and other stuff.

[lpil]

Gosh that's confusing, I feel both Erlang and PostgreSQL could have done better here!

I think the most important thing for me is that it's clear what the optimal and most secure option is, and that it's the default to prevent people accidentally being insecure.

Thanks again

[TorstenDittmann]

Is there any progress on this? 👀 Using hosted postgres services like neon.tech or xata.io requires developers to set ssl options 👍🏻

[ghivert]

It took me long time, but I think it's finally in a much better way than before. Tell me @lpil if it seems better to you, or if you think there's still things to change.

[lpil]

This is looking super nice! I've left 1 bike-sheddy question below.

Could you also add annotations to all the functions please, some are missing the return annotation.

[lpil]

Bike shedding on names here!

It kinda sounds like "disabled" is more safe than "unsafe", but I would have thought that enabled > verified but unchecked > unverified. Is that right? Could the names get scarier and uglier as they get less secure?

[ghivert]

The idea is SslEnabled > SslUnsafe > SslDisabled. Maybe we can use SslVerified > SslUnverified > SslDisabled?

[ghivert]

Implemented this.

[dandeduck]

Thank you for the work on this! Just wanted to add that it should fix issues like this one from squirrel with connecting to DBs that require SSL, since currently the sslmode=require query doesn't work as expected, they are kinda stuck (except for adding some additional parsing on top 😄)

Hope this can be added soon!

[lpil]

Thank you!!!