Date: Tue, 19 Aug 2014 10:48:41 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: PQgetssl() and alternative SSL implementations
Message-ID: <20140819144841.GA16422@tamriel.snowman.net>
References: <53F1E989.8020609@vmware.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="ZCgjFK3u1ZxO+OFD"
Content-Disposition: inline
In-Reply-To: <53F1E989.8020609@vmware.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--ZCgjFK3u1ZxO+OFD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
>   server_cert_valid: Did the server present a valid certificate?
> "yes" or "no"
>=20
>   server_cert_matches_host: Does the Common Name of the certificate
> match the host connected to? "yes" or "no"

Aren't these questions addressed by sslmode?

> Exposing the SSL information as generic key/value pairs allows
> adding more attributes in the future, without breaking the ABI, and
> it also allows exposing implementation-specific information in a
> generic way. The attributes listed above cover the needs of psql.
> What else do we need?

At first blush, I'd say a whole bunch..  Off the top of my head I can
think of:

For all certificates:
(client, server, cert that signed each, any intermediate CAs, root CAs)
  Certificate itself (perhaps in DER, PEM, X509 formats..)
  Fingerprint
  Signed-By info
  Common Name
  Organization (et al)
  Alternate names
  Issue date, expiration date
  CRL info, OCSP info
  Allowed usage (encryption, signing, etc)

CRL checking done?
OCSP used?

> I think it would also be nice to get more information from the
> server's certificate, like the hostname and the organization its
> issued to, and expiration date, so that an interactive client like
> pgAdmin or even psql could display that information like a web
> browser does. Would it be best to add those as extra attributes in
> the above list, perhaps with a "server_cert_*" prefix, or add a new
> function for extracting server cert's attributes?

This really shouldn't be for *just* the server's certificate but rather
available for all certificates involved- on both sides.

> The other question is: What do we do with PQgetssl()? We should
> document it as deprecated, but we'll have to keep it around for the
> foreseeable future for backwards-compatibility. We obviously cannot
> return a valid OpenSSL struct when using any other implementation,
> so I think it'll have to just return NULL when not using OpenSSL.
> Probably the most common use of PQgetssl() is to just check if it
> returns NULL or not, to determine if SSL is enabled, so a client
> that does that would incorrectly think that SSL is not used, even
> when it is. I think we can live with that.

That's not ideal, but the only other option I can think of offhand is to
break the existing API and force everyone to update and that seems
worse.

Have you looked at how this change will play out with the ODBC driver..?
Especially on Windows with the SSL library you're proposing we use
there..  I recall that at one point the ODBC driver simply used libpq to
handle the authentication and set everything up, and then switched to
talking directly without libpq.  In any case, it'd probably be good to
make sure the attributes you're suggesting are sufficient to meet the
needs of the ODBC driver too.

	Thanks,

		Stephen

--ZCgjFK3u1ZxO+OFD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT82PIAAoJEO1sijiDR2RVED8QAKNQI2JFcz2n8AI9Cp6pBcrF
advChvZbKPz5BzjH8GlrDI/+bn5UZW9y6Z2Uwzhz/ThRp6WVUHAZRapJW9J3UojC
hcwCnB9d24tv8Ab4az5iBy42CJ+6i3Ygt3UUoTyIPCUt0gfEs7bJJoCtu+F7fBpQ
DqbiO6hreQOPFsAu75Le90zfVzFSXwI5mEMV8/MuUZpZ9wq0SMUMdwUH2B6dwxFs
KUgYPpcfjGAKiwbf+A4MjqldpyU0Tq9s+7kCGYDND5EYWo2otJwmZVKXf3iOFSOa
SZkKvJOSwjc9zXxby+/P/jgA3B836g+76RSziX2+Jen4KTSj3UzvH1Xqxt2YY7eA
F/rPgGSgedrE49PjK5SVLlXre0h+JTnTZbJbMgQmPva0S8mDaHmOcfVx+ej9Ewiz
i0xaXBmrj9+5EMqvB9dLpZGEchxj28Kw8LJgN71gEKfal52Ucz04yuzd5jFl84Sh
m2MA48Z1z6Sd29kyPoDO2ngH11r0Yr1nzar/L6L3C4CCCqVvAcK2W8xZGViO3seP
hckvQVGrnaP/DdWAOYKqGD96cJ0lTHnuENgZWMes6v71DyBgy0ILOiMSLNQlmTYC
sa0Flvag8/d1hV0R9FCzcXW9hbX3GXn+kvsa1ol8vCqw0kkGohFz0mJB6sxzKpAv
aUgOKYSaowKAFSP8AVEf
=Grzb
-----END PGP SIGNATURE-----

--ZCgjFK3u1ZxO+OFD--