Date: Tue, 19 Aug 2014 11:44:36 -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: <20140819154436.GD16422@tamriel.snowman.net>
References: <53F1E989.8020609@vmware.com>
 <20140819144841.GA16422@tamriel.snowman.net>
 <53F36B6E.6040105@vmware.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="GU+PZwHl6Z3aQ7D4"
Content-Disposition: inline
In-Reply-To: <53F36B6E.6040105@vmware.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
> I think it would be nice to be able to query those attributes
> explicitly, rather than just expect libpq to reject the connection
> if something's wrong. For example, I'm thinking that an interactive
> client might present an annoying pop-up window to the user if the
> server cert is not valid, asking if he wants to connect anyway, and
> perhaps remember the certificate and not ask again (TOFU).

Alright, I could see that being useful, though as you say, it'd really
be new functionality.

> Hmm. That seems a bit too much. Perhaps provide just the certificate
> itself in DER/PEM format, and have the client parse it (using
> OpenSSL or something else) if it wants more details.

I really don't care for that approach.  Our SSL support has always been
horrible- I was hoping we'd actually improve that situation.  Adding
things in piecemeal over time will just be painful for our users and I
don't see why we should wait.

> >OCSP used?
>=20
> We don't support OCSP.

Another thing that we really should address (actually- can't you enable
it in OpenSSL directly?  I seem to recall something along those lines
anyway, though it's been quite a few years now).

> >This really shouldn't be for *just* the server's certificate but rather
> >available for all certificates involved- on both sides.
>=20
> Ok, but why? All the other stuff is readily available in the
> configuration you use to connect. I guess it doesn't hurt to expose
> them through this interface as well, but I can't immediately think
> of an example that would use them.

For starters, certificates can be passed between the client and the
server to complete the chain, so I don't see how it's "readily
available", not to mention that even if the location of the certs was in
simple files locally, the application would need to bring in their own
library to parse and extract out this information, which we've
more-or-less already got.

> Indeed, the ODBC driver only uses libpq for authentication, then
> calls PQgetssl(), and takes over the whole show calling SSL_read()
> and SSL_write() itself. Ideally, we'd modify psqlodbc to stop doing
> that, but that's not an easy job. In the short-term, I think we need
> to export pqsecure_read() and pqsecure_write() functions in libpq,
> so that the ODBC driver can use those instead of SSL_read() and
> SSL_write().

Yeah, that's what I remembered.  There was an attempt to make that
change at one point, but it was reverted due to the lack of batching
ability in libpq (without resorting to cursors, as I recall...),
requiring double the memory usage.  Still, if pqsecure_read and
pqsecure_write are sufficient to make the ODBC driver work, that's good
news.  I had been worried it did other things with the OpenSSL struct
beyond just using those.

	Thanks,

		Stephen

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

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

iQIcBAEBAgAGBQJT83DjAAoJEO1sijiDR2RVteUQALnxIIeJPbZxz0nj1l+g44PK
8gyJDpf8p0P+i8l6XLTd9GpeTLeg/9SPJhkwaGsDZ1AjTTPXNskgnyMd5BbgKFgy
F/xnOTEFTeh9mK2OMMKJGlKrHQXbHLpHl9mV/G+zGNEdHN6uDZnfG6AQAUmCT9UY
0Cydr+iYU8fOoeDDIT13haosVMAuVT8ZwAiKY3d+dkUcy9nt5UuS+EJ+SpsOiWxF
0NMIIIlgZaKD3MRCX3jsk9SsfHUBl1NDFzdtqHNnDZwtmhd3zfvclOk41MoO8iE3
tgmmCNolXcxfRMMppiUS7eykU7ff+hv1KQvHKMpqcVTul23X/n+PP20I+CKWNOdn
wu8FRbUXd7Ah7TApUp0NC1CEp1boTqD2+tqlvx1rdiBe0pNnoq3zdsX0aSNXylV7
Z7PFe2SfIZx94F/+QqapEIklt4kuNIE5ZFRb0uAvb413AubQ5zKIDNxVj42WSMJn
oVQdgnA3gXzohPPS+qtI/vLYPth85Kyf2Vm9KGK+OECr8BnfXvXy23qx6p4q2KRu
JySkZr9erWmCVUw9VtJFc3AgD3NF7AEuEuo7pQohS4TFxGbdwh5d13Bugmmtw/yA
c/M3R4r/tZaB6EmjbF/kjncGPn74q1nxBmluM3igUSwpWEX4mp60gG8PrcGzSwWp
ursilZBn/MC9mGvjEcYl
=ZDDC
-----END PGP SIGNATURE-----

--GU+PZwHl6Z3aQ7D4--