On Thu, 24 Apr 2025 at 18:46, Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > > On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut <pe...@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.champ...@enterprisedb.com> wrote: > > On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut <pe...@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 <m...@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 > >
