On Thu, Apr 24, 2025 at 3:16 PM Jelte Fennema-Nio wrote:
> Why is this dangerous? As long as we'd validate that the provided cert
> by the server is for example.com
I can't help but read this as "as long as everyone mitigates the
danger, what's the danger?" We won't be the only implementers of an
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> Another detail to think about is how this affects psql -h localhost. In
> principle, this should require full SSL, but you're probably not going
> to have certificates that allow "localhost". And connections to
> localhost are the default
> On 25 Apr 2025, at 15:40, George MacKerron wrote:
>
>> On 25 Apr 2025, at 13:53, Daniel Gustafsson wrote:
>>>
(2) sslrootcert=system on Windows doesn’t do a thing that would be
extremely useful in some common situations. Namely: connecting securely to
servers that present a c
> On 25 Apr 2025, at 13:53, Daniel Gustafsson wrote:
>>
>>> (2) sslrootcert=system on Windows doesn’t do a thing that would be
>>> extremely useful in some common situations. Namely: connecting securely to
>>> servers that present a certificate signed by a public CA.
>>
>> Just to be clear, do
> On 25 Apr 2025, at 00:16, Jelte Fennema-Nio wrote:
> 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
> On 3 Apr 2025, at 16:26, Daniel Gustafsson wrote:
>
>> On 3 Apr 2025, at 14:41, George MacKerron wrote:
>
>> (2) sslrootcert=system on Windows doesn’t do a thing that would be extremely
>> useful in some common situations. Namely: connecting securely to servers
>> that present a certificate
> On Fri, 25 Apr 2025 at 12:22, George MacKerron wrote:
>> I know the documentation has now been changed to reflect that ‘system’
>> actually means OpenSSL.
>
> I didn't realize that. I'm definitely not in favor of that doc change.
> It's describing behaviour that I believe is incorrect, as if
On Fri, 25 Apr 2025 at 12:22, George MacKerron wrote:
> I know the documentation has now been changed to reflect that ‘system’
> actually means OpenSSL.
I didn't realize that. I'm definitely not in favor of that doc change.
It's describing behaviour that I believe is incorrect, as if it's
actual
> On Thu, 24 Apr 2025 at 23:52, Jelte Fennema-Nio wrote:
>
>> How about we add a *compile time*
>> option that allows the person that compiles libpq to choose which cert
>> store it should use if sslrootcert=system is provided. Something like
>> --system-cert-store=openssl and --system-cert-store
> On 24 Apr 2025, at 18:45, Jacob Champion
> wrote:
>
> On Wed, Apr 23, 2025 at 8:47 AM George MacKerron
> wrote:
>> I’d suggest two new special sslrootcert values:
>>
>> (1) sslrootcert=openssl
>>
>> This does exactly what sslrootcert=system does now, but is less confusingly
>> named fo
On Thu, 24 Apr 2025 at 23:52, Jelte Fennema-Nio wrote:
> How about we add a *compile time*
> option that allows the person that compiles libpq to choose which cert
> store it should use if sslrootcert=system is provided. Something like
> --system-cert-store=openssl and --system-cert-store=winstore
On Thu, 24 Apr 2025 at 18:46, Jacob Champion
wrote:
>
> On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut 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://
> sc
On Wed, 23 Apr 2025 at 17:47, George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> thi
On Wed, Apr 23, 2025 at 8:47 AM George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> t
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut 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 wrote:
> For
> postgresql://-style strings, we would ideally have something like http://
> vs http
On 24.04.25 12:53, Christoph Berg wrote:
Now you can say `psql -h db.example.com -p 5433 dbfoo`, but for
specifying the sslmode, you have to rewrite at least the last argument
to use connection string syntax, `psql "dbname=dbfoo sslmode=verify-full`.
This needs be be less cumbersome. (And the nam
Re: George MacKerron
> > Before we can make this change, I think we would have to improve the
> > UX. psql does not even have any --switch for it. PostgreSQL serving
> > non-SSL and SSL on the same port doesn't make the UX better... :-/
>
> How do you think the UX could be improved? Maybe by using
> On Linux/*ix, there would be 3 things that are all the same.
>
> If the Windows Openssl store is that bad, wouldn't the smarter thing
> to do for PG19 to use winstore by default? The Openssl one would still
> be available when requested explicitly. This would avoid the
> proliferation of default
> On 3 Apr 2025, at 15:26, Daniel Gustafsson wrote:
>
>> I quite like sslrootcert=os: it’s snappy, and it implies that the Operating
>> System root certs are going to be used (which is what I would have liked
>> sslrootcert=system to mean). Some possible alternatives might be
>> sslrootcert=pu
Re: George MacKerron
> SMALLER IDEA
>
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> this option.
>
>
> On 3 Apr 2025, at 16:26, Daniel Gustafsson wrote:
>> On 3 Apr 2025, at 14:41, George MacKerron wrote:
>> Your diff certainly fixes (1b), so it’s definitely an improvement.
>
> Thanks, unless Jacob objects I propose to apply that backpatched down to when
> sslrootcert=system went in.
Hearing
> On 3 Apr 2025, at 14:28, Christoph Berg wrote:
>
> What are the chances of making "use the system/os default CA store"
> the default? "sslmode=require" would then already actually "require" a
> certificate if I'm reading the docs right. This would match user
> expectation for POLA.
Right: the
On Wed, Apr 2, 2025 at 7:15 AM George MacKerron wrote:
> > But happily, I don’t think we need to choose. Can’t we just use the Windows
> > system store if neither of the relevant environment variables is set?
>
> Thinking about this a little more, I guess the remaining concern is about
> people
> On 3 Apr 2025, at 14:41, George MacKerron wrote:
> (2) sslrootcert=system on Windows doesn’t do a thing that would be extremely
> useful in some common situations. Namely: connecting securely to servers that
> present a certificate signed by a public CA.
Just to be clear, does (2) happens wh
Re: George MacKerron
> (3) Any other ideas?
I'm not a fan of "security by adding more connection parameters".
What are the chances of making "use the system/os default CA store"
the default? "sslmode=require" would then already actually "require" a
certificate if I'm reading the docs right. This
> On 3 Apr 2025, at 11:41, Daniel Gustafsson wrote:
>
> org.openssl.winstore isn't by OpenSSL defined as the default even on Windows,
> but a future version might change that.
Right — there’s definitely an argument that OpenSSL should in future make it
possible to have this be the default via a
On Wed, Apr 2, 2025 at 2:35 AM George MacKerron
wrote:
> I was very pleased to see the sslrootcert=system connection option added
> in Postgres 16 (I even blogged about it:
> https://neon.tech/blog/avoid-mitm-attacks-with-psql-postgres-16). But
> sslrootcert=system has not been widely supported b
> On 3 Apr 2025, at 03:21, Jacob Champion
> wrote:
>
> On Wed, Apr 2, 2025 at 7:15 AM George MacKerron
> wrote:
>>> But happily, I don’t think we need to choose. Can’t we just use the Windows
>>> system store if neither of the relevant environment variables is set?
The env vars are only over
> On 2 Apr 2025, at 14:39, George MacKerron wrote:
> But happily, I don’t think we need to choose. Can’t we just use the Windows
> system store if neither of the relevant environment variables is set?
Thinking about this a little more, I guess the remaining concern is about
people on Windows c
Daniel, Jacob: thanks. My feeling is that it would be a bit odd to prioritise
the preservation of a secondary behaviour (users can customise what cert store
is used via environment variables) over fixing the feature’s basic reason for
existing (certificates will be validated against the system C
> On 1 Apr 2025, at 23:46, Jacob Champion
> wrote:
> On Tue, Apr 1, 2025 at 2:05 PM George MacKerron
> wrote:
>> I’ve recently been trying to get it more widely supported, with some success
>> (details at end of this message).
>
> (Thank you!)
+many
>> I’m not a Windows or OpenSSL expert,
I was very pleased to see the sslrootcert=system connection option added in
Postgres 16 (I even blogged about it:
https://neon.tech/blog/avoid-mitm-attacks-with-psql-postgres-16). But
sslrootcert=system has not been widely supported by psql installations, perhaps
because people compiling Postgr
On Tue, Apr 1, 2025 at 2:05 PM George MacKerron wrote:
>
> I was very pleased to see the sslrootcert=system connection option added in
> Postgres 16 (I even blogged about it:
> https://neon.tech/blog/avoid-mitm-attacks-with-psql-postgres-16). But
> sslrootcert=system has not been widely support
33 matches
Mail list logo
