Re: Experiments with Postgres and SSL - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Experiments with Postgres and SSL
Date
Msg-id CAM-w4HMPCL5ZcyyyykGJsOBeo3PmExPxyMk7aoL7rt_sL7zGLg@mail.gmail.com
Whole thread Raw
In response to Re: Experiments with Postgres and SSL  (Greg Stark <stark@mit.edu>)
Responses Re: Experiments with Postgres and SSL  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Here's an updated patch for direct SSL connections.

I've added libpq client support with a new connection parameter. This
allows testing it easily with psql. It's still a bit hard to see
what's going on though. I'm thinking it would be good to have libpq
keep a string which describes what negotiations were attempted and
failed and what was eventually accepted which psql could print with
the SSL message or expose some other way.

In the end I didn't see how adding an API for this really helped any
more than just saying the API is to stuff the unread data into the
Port structure. So I just documented that. If anyone has any better
idea...

I added documentation for the libpq connection setting.

One thing, I *think* it's ok to replace the send(2) call with
secure_write() in the negotiation. It does mean it's possible for the
connection to fail with FATAL at that point instead of COMMERROR but I
don't think that's a problem.

I haven't added tests. I'm not sure how to test this since to test it
properly means running the server with every permutation of ssl and
gssapi configurations.

Incidentally, some of the configuration combinations -- namely
sslnegotiation=direct and default gssencmode and sslmode results in a
counter-intuitive behaviour. But I don't see a better option that
doesn't mean making the defaults less useful.

Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: The use of atooid() on non-Oid results
Next
From: Andrew Dunstan
Date:
Subject: Re: slapd logs to syslog during tests