Re: "cert" + clientcert=verify-ca in pg_hba.conf?

At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > > I don't see "no-verify" mentioned anywhere in our docs.
> > > > 
> > > > no-verify itself is mentioned here.
> > > > 
> > > > https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES
> > > 
> > > Oh, I see it now, thanks.  Do you have any idea what this part of the
> > > docs means?
> > > 
> > >     When <literal>clientcert</literal> is not specified or is set to
> > >     <literal>no-verify</literal>, the server will still verify any presented
> > >     client certificates against its CA file, if one is configured —
> > >     but it will not insist that a client certificate be presented.
> > 
> > Ah.. Indeed.
> > 
> > Even if clientcert is not set or set to no-verify, it checks client
> > certificate against the CA if any. If verify-ca, client certificate
> > must be provided. As the result, no-verify actually fails if client
> > had a certificate that is not backed by the CA.
> 
> I think there are a few problems here.  In the docs, it says "will still
> verify", but it doesn't say if it verifies the CA, or the CA _and_ the
> CN/username.

It verifies only CA.

> Second, since it is optional, what value does it have?
> 
> > > Why is this useful?
> > 
> > I agree, but there seems to be an implementation reason for the
> > behavior. To identify an hba-line, some connection parameters like
> > user name and others sent over a connection is required.  Thus the
> > clientcert option in the to-be-identified hba-line is unknown prior to
> > the time SSL connection is made. So the documentation might need
> > amendment. Roughly something like the following?
> 
> Well, I realize internally we need a way to indicate clientcert is not
> used, but why do we bother exposing that to the user as a named option?

Because we think we need any named value for every alternatives
including the default value?

> And you are right that the option name 'no-verify' is wrong since it
> will verify the CA if it exists, so it more like 'optionally-verify',
> which seems useless from a user interface perspective.
> 
> I guess the behavior of no-verify matches our client-side
> sslmode=prefer, but at least that has the value of using SSL if
> available, which prevents user-visible network traffic, but doesn't
> force it, but I am not sure what the value of optional certificate
> verification is, since verification is all it does.  I guess it should
> be called "prefer-verify".

The point of no-verify is to allow the absence of client
certificate. It is similar to "prefer" in a sense that it allows the
absence of availability of an SSL connection. (In a similar way to
"prefer", we could "fall back" to "no client cert" SSL connection
after verification failure but I think it's not worth doing.)

"prefer-verify" seems right in that sense. But I'm not sure we may
break backward compatibility for the reason.

> > ===
> > When <literal>clientcert</literal> is not specified or is set
> > to<literal>no-verify</literal>, clients can connect to server without
> > having a client certificate.
> > 
> > Note: Regardless of the setting of <literal>clientcert</literal>,
> > connection can end with failure if a client certificate that cannot be
> > verified by the server is stored in the ~/.postgresql directory.
> > ===
> > 
> > By the way, the following table line might need to be changed?
> > 
> > libpq-ssl.html:
> > 
> > >      <entry><filename>~/.postgresql/postgresql.crt</filename></entry>
> > >      <entry>client certificate</entry>
> > -      <entry>requested by server</entry>
> > 
> > The file is actually not requested by server, client just pushes to
> > server if any, unconditionally.
> > 
> > +      <entry>sent to server</entry>
> 
> I have just applied this change to all branches, since it is an
> independent fix.  Thanks.

Thanks.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center