On Thu, 24 Apr 2025 at 18:46, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> > I'm generally in favor of making sslmode=verify-full the effective
> > default somehow.
>
> +many
Yes, +many
> Not to derail things too much, but I'd also like a postgress://
> scheme
Sounds great.
Let me derail some more, while we're at it I think it would be good to
add tls-prefixed aliases for all our ssl options. Like tlscert/tlskey.
Since such a new postgress:// scheme would be totally new, maybe we
can even disallow the ssl prefixed ones there.
> The hardest part, in my opinion, is that we'd have to start following
> the RFC concept of "authority". A URL of
> "postgress://example.com/db?host=evil.com&hostaddr=..." is outright
> dangerous
Why is this dangerous? As long as we'd validate that the provided cert
by the server is for example.com, I don't see any security problem in
having DNS resolution happen for evil.com, nor in having the IP
addresses hardcoded using hostaddr.
> as is "postgress://example.com/db?sslmode=disable"
Yeah that should be addressed, but seems like we mainly need to
disallow specifying sslmode completely there (or error if it's not
verify-full). And maybe there's some other options that we'd want to
disallow.
On Thu, 24 Apr 2025 at 18:46, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> > I'm generally in favor of making sslmode=verify-full the effective
> > default somehow.
>
> +many
>
> On Thu, Apr 24, 2025 at 3:53 AM Christoph Berg <myon@debian.org> wrote:
> > For
> > postgresql://-style strings, we would ideally have something like http://
> > vs https://, but I am not sure how to squeeze that into the syntax.
>
> Not to derail things too much, but I'd also like a postgress://
> scheme, and I've put a little bit of idle thought into it. I think
> we'd want it to imply sslnegotiation=direct and sslrootcert=system
> (modulo the Windows discussion already in progress), and potentially
> make a bunch of stricter decisions about TLS settings to better match
> modern practice. The intent would be to have a "browser-strength"
> scheme for people who care more about security than about raw
> compatibility with older systems, because they're connecting to
> someone else's servers on the open Web.
>
> The hardest part, in my opinion, is that we'd have to start following
> the RFC concept of "authority". A URL of
> "postgress://example.com/db?host=evil.com&hostaddr=..." is outright
> dangerous, as is "postgress://example.com/db?sslmode=disable". So if
> there's interest in that scheme, I think it should remain a separate
> feature from "verify-full by default", because there's a lot more to
> figure out.
>
> --Jacob
>
>
