Обсуждение: libpq and sslmode=require
In testing an SSL patch, I found that if I use 'sslmode=require' in the libpq connection string, it does not use SSL over a unix-domain socket. libpq should either use SSL (which I don't think it can), or error out, or we should at least document this behavior. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > In testing an SSL patch, I found that if I use 'sslmode=require' in the > libpq connection string, it does not use SSL over a unix-domain socket. > > libpq should either use SSL (which I don't think it can), or error out, > or we should at least document this behavior. We discussed this before 8.3 already. It might be time to address this now that the SSL support is being redesigned. SSL over Unix-domain sockets with libpq works perfectly fine if you remove the code in libpq and/or the postmaster (forgot which exactly) that thinks that it doesn't work. The issue previously was the libpq defaults to sslmode=prefer and that would impose a noticeable connection initiation overhead on everyone's Unix-domain socket uses. You could make it use SSL in require mode, but it seems weird that prefer mode would end up doing something different than require mode. Maybe Magnus has an opinion on how we could make this fit into the new scheme of things. I assume since we require certificates to be set up now, SSL will by default be off and so using it over Unix-domain sockets when enabled would not be in the common path, which was the objection previously.
Bruce Momjian <bruce@momjian.us> writes:
> In testing an SSL patch, I found that if I use 'sslmode=require' in the
> libpq connection string, it does not use SSL over a unix-domain socket.
It's always done that.
regards, tom lane
Peter Eisentraut wrote: > Bruce Momjian wrote: > > In testing an SSL patch, I found that if I use 'sslmode=require' in the > > libpq connection string, it does not use SSL over a unix-domain socket. > > > > libpq should either use SSL (which I don't think it can), or error out, > > or we should at least document this behavior. > > We discussed this before 8.3 already. It might be time to address this > now that the SSL support is being redesigned. > > SSL over Unix-domain sockets with libpq works perfectly fine if you > remove the code in libpq and/or the postmaster (forgot which exactly) > that thinks that it doesn't work. > > The issue previously was the libpq defaults to sslmode=prefer and that > would impose a noticeable connection initiation overhead on everyone's > Unix-domain socket uses. You could make it use SSL in require mode, but > it seems weird that prefer mode would end up doing something different > than require mode. > > Maybe Magnus has an opinion on how we could make this fit into the new > scheme of things. I assume since we require certificates to be set up > now, SSL will by default be off and so using it over Unix-domain sockets > when enabled would not be in the common path, which was the objection > previously. Yep, the problem is that sslmode doesn't have any way to specify if we want unix domain sockets to behave differently from tcp sockets, and our default for sslmode makes that even worse. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Peter Eisentraut wrote: > Bruce Momjian wrote: >> In testing an SSL patch, I found that if I use 'sslmode=require' in the >> libpq connection string, it does not use SSL over a unix-domain socket. >> >> libpq should either use SSL (which I don't think it can), or error out, >> or we should at least document this behavior. > > We discussed this before 8.3 already. It might be time to address this > now that the SSL support is being redesigned. > > SSL over Unix-domain sockets with libpq works perfectly fine if you > remove the code in libpq and/or the postmaster (forgot which exactly) > that thinks that it doesn't work. Well, "perfectly fine" I'm not sure. What would you verify the CN in the certificate against, if there is no hostname? And doing this CN verification would actually be the only reason you'd want to use SSL over Unix sockets, I think. If we can figure out something "reasonable" to do here, it might be worthwhile to support it. > The issue previously was the libpq defaults to sslmode=prefer and that > would impose a noticeable connection initiation overhead on everyone's > Unix-domain socket uses. You could make it use SSL in require mode, but > it seems weird that prefer mode would end up doing something different > than require mode. > > Maybe Magnus has an opinion on how we could make this fit into the new > scheme of things. I assume since we require certificates to be set up > now, SSL will by default be off and so using it over Unix-domain sockets > when enabled would not be in the common path, which was the objection > previously. The only difference is that we require certificate or CA on the client. Well, not require, but by default request it. We have always required a certificate on the server. SSL is still controlled by the "ssl=on" on the server side primarily. //Magnus
Bruce Momjian wrote: > > would impose a noticeable connection initiation overhead on everyone's > > Unix-domain socket uses. You could make it use SSL in require mode, but > > it seems weird that prefer mode would end up doing something different > > than require mode. > > > > Maybe Magnus has an opinion on how we could make this fit into the new > > scheme of things. I assume since we require certificates to be set up > > now, SSL will by default be off and so using it over Unix-domain sockets > > when enabled would not be in the common path, which was the objection > > previously. > > Yep, the problem is that sslmode doesn't have any way to specify if we > want unix domain sockets to behave differently from tcp sockets, and our > default for sslmode makes that even worse. I have added the following documentation patch to mention that 'sslmode' is ignored for unix domain sockets; backpatched to 8.3.X. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.266 diff -c -c -r1.266 libpq.sgml *** doc/src/sgml/libpq.sgml 27 Oct 2008 09:42:31 -0000 1.266 --- doc/src/sgml/libpq.sgml 4 Nov 2008 22:33:49 -0000 *************** *** 233,240 **** <term><literal>sslmode</literal></term> <listitem> <para> ! This option determines whether or with what priority an ! <acronym>SSL</> connection will be negotiated with the server. There are four modes: <literal>disable</> will attempt only an unencrypted <acronym>SSL</> connection; <literal>allow</> will negotiate, trying first a --- 233,240 ---- <term><literal>sslmode</literal></term> <listitem> <para> ! This option determines whether or with what priority a ! <acronym>SSL</> TCP/IP connection will be negotiated with the server. There are four modes: <literal>disable</> will attempt only an unencrypted <acronym>SSL</> connection; <literal>allow</> will negotiate, trying first a *************** *** 243,249 **** will negotiate, trying first an <acronym>SSL</> connection, then if that fails, trying a regular non-<acronym>SSL</> connection; <literal>require</> will try only an ! <acronym>SSL</> connection. </para> <para> --- 243,250 ---- will negotiate, trying first an <acronym>SSL</> connection, then if that fails, trying a regular non-<acronym>SSL</> connection; <literal>require</> will try only an ! <acronym>SSL</> connection. <literal>sslmode</> is ignored ! for Unix domain socket communication. </para> <para>