From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Sergio <sergio(dot)cinos(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Client SSL validation using root.crt |
Date: | 2006-11-21 15:06:45 |
Message-ID: | 4304.1164121605@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> It is possible to continue communicating after SSL negotiation failure.
> If SSL_accept/connect return 0, that means the negotiation failed
> cleanly and in theory libpq could continue in non-SSL mode.
We'd have to change the backend too, though, because in existing
releases it likewise will drop out on SSL negotiation failure.
> I think long term this would be the nicest solution (no double
> connections) but it's probably more complicated then looping around
> again after SSL failure.
I don't think it's that important. If the backend is configured with
ssl = off then we already fall through without using an extra connection
cycle. The double connection only occurs if both sides think they
should use SSL but something goes wrong ... which is probably a
situation that needs user attention anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shane Ambler | 2006-11-21 15:45:01 | Re: ORDER BY |
Previous Message | Richard Broersma Jr | 2006-11-21 15:01:44 | Re: Calculating percentages in Postgresql |
From | Date | Subject | |
---|---|---|---|
Next Message | Danny Milosavljevic | 2006-11-21 15:16:23 | Re: XA support (distributed transactions) |
Previous Message | Heikki Linnakangas | 2006-11-21 14:40:02 | Re: XA support (distributed transactions) |