Обсуждение: Re: [pgsql-hackers-win32] More SSL questions..

> > > win32 hackers, anyone know why it's like this?
> >
> > Looking through the code, it seems that it's because
> someone thought
> > that breaking SSL would be easier than replacing the pqGetpwuid()
> > calls that are used to find out the user's home directory.
> >
>
> I think what happened is that SSL was known to be broken on
> Win32 and someone submitted a patch and I thought it now
> worked, but obviously it doesn't.  Perhaps the fix was just
> so it compiled with SSL.

I think it's only broken when you fiddle with certificates. Unless
something broke fairly recently. Sometime back around beta2 or beta3 I
sent a patch to make it compile and work on win32. But I only touched
the server side of things. It worked in my simple tests using psql, but
I did nothing fancy with certificates.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> I think it's only broken when you fiddle with certificates.

Yeah, the commented-out stuff had to do with certificates, and would not
be executed unless the server demands a client certificate (which only
happens if the server has a root.crt file).

BTW, as of CVS tip, if the server has a root.crt file and the client
does not have any certificate files, the default behavior is that
connections fail:

$ psql -h localhost regression
psql: could not open certificate file "/home/tgl/.postgresql/postgresql.crt": No such file or directory
$

I'm not sure if this is desirable.  Should libpq try to fall back to a
non-SSL-encrypted connection, instead?

            regards, tom lane

Tom Lane wrote:

> BTW, as of CVS tip, if the server has a root.crt file and the client
> does not have any certificate files, the default behavior is that
> connections fail:
>
> $ psql -h localhost regression
> psql: could not open certificate file "/home/tgl/.postgresql/postgresql.crt": No such file or directory
> $
>
> I'm not sure if this is desirable.  Should libpq try to fall back to a
> non-SSL-encrypted connection, instead?

Only if the server certificate validates, otherwise an active attacker
could intercept the SSL connection to force libpq to fall back to
non-SSL and then intercept the unencrypted/unauthenticated connection.
Does openssl lets you detect a "server cert OK but no suitable client
cert provided" error easily?

-O

Oliver Jowett <oliver@opencloud.com> writes:
> Tom Lane wrote:
>> I'm not sure if this is desirable.  Should libpq try to fall back to a
>> non-SSL-encrypted connection, instead?

> Only if the server certificate validates, otherwise an active attacker
> could intercept the SSL connection to force libpq to fall back to
> non-SSL and then intercept the unencrypted/unauthenticated connection.

The problem case is where there are no SSL support files, and so the client
isn't going to be able to validate the server cert anyway.  So the above
doesn't seem real helpful...

Basically my point here is that the default "prefer" SSL mode
effectively becomes "require" if the server has a root.crt.

            regards, tom lane

Tom Lane wrote:

> Basically my point here is that the default "prefer" SSL mode
> effectively becomes "require" if the server has a root.crt.

Ok, in the scenario where validation is important, clients should be
using "require" anyway, so it's not an issue so long as libpq doesn't
try to fall back to non-SSL when "require" is in effect.

A default SSL mode of "prefer" does seem a bit dodgy, though -- it only
protects against passive attacks. I'd be tempted to make "disable" the
default, so that you have a better chance of visible errors if clients
are not correctly configured rather than silently forging ahead with a
connection that might be unintentionally insecure. That would mean lots
of pain for existing installs though :(

I had to dig into the libpq docs to find any mention of the environment
variables / config files that set the SSL behaviour. It'd be useful to
have details in the psql manpage too..

-O