sslmode=require fallback
Hi!
I've looked at the way libpq handles TLS certificates and plaintext fallback, and I am somewhat surprised.
The default ssmode is prefer. According to the documentation, this will make libpq use an SSL connection if possible, but will use a plain text connection as a fallback. The certificate will not be verified.
If, however, there is a root certificate in ~/.postgresql/root.crt, libpq will check if the server cert matches this certificate, and refuse any certfificates that don't match. This means that libpq will fall back to a plain text connection!
This is very unexpected behavior! Shouldn't libpq prefer an *unauthenticated but encrypted* connection over an *unauthenticated and unencrypted* connection?
This behavior also causes sslmode=require to behave like sslmode=verify-ca when ~/.postgresql/root.crt exists.
From my limited understanding, it seems the way to fix this would be in fe-secure-openssl.c, to change initialize_SSL() to only read the root certificate file when sslmode=verify_*
However, if this is the expected behavior, the documentation at https://www.postgresql.org/docs/current/static/libpq-ssl.html <https://www.postgresql.org/docs/current/static/libpq-ssl.html> should be updated to make this more clear. It should be made clear that the existence of the file ~/.postgresql/root.crt changes the behavior of sslmode=require and sslmode=prefer.
Best regards,
Jakob
On Thu, Jun 16, 2016 at 10:39 AM, Jakob Egger <jakob@eggerapps.at> wrote:
Hi!
I've looked at the way libpq handles TLS certificates and plaintext
fallback, and I am somewhat surprised.The default ssmode is prefer. According to the documentation, this will
make libpq use an SSL connection if possible, but will use a plain text
connection as a fallback. The certificate will not be verified.If, however, there is a root certificate in ~/.postgresql/root.crt, libpq
will check if the server cert matches this certificate, and refuse any
certfificates that don't match. This means that libpq will fall back to a
plain text connection!This is very unexpected behavior! Shouldn't libpq prefer an
*unauthenticated but encrypted* connection over an *unauthenticated and
unencrypted* connection?
You would think so.
The default mode of "prefer" is ridiculous in a lot of ways. If you are
using SSL in any shape or form you should simply not use "prefer". That's
really the only answer at this point, unfortunately.
This behavior also causes sslmode=require to behave like sslmode=verify-ca
when ~/.postgresql/root.crt exists.
Correct. That's mainly for really old backwards compatibility. We could
have a "sslmode=verify-none" to reverse that, I guess. I'm not sure if this
scenario is common enough to care about though?
From my limited understanding, it seems the way to fix this would be in
fe-secure-openssl.c, to change initialize_SSL() to only read the root
certificate file when sslmode=verify_*However, if this is the expected behavior, the documentation at
https://www.postgresql.org/docs/current/static/libpq-ssl.html should be
updated to make this more clear. It should be made clear that the existence
of the file ~/.postgresql/root.crt changes the behavior of sslmode=require
and sslmode=prefer.
Agreed. It's basically backwards compatibility with something that was
badly documented in the first place :) That's not a particularly strong
argument for the way it is. Clarifying the documentation would definitely
be a good improvement.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote:
However, if this is the expected behavior, the documentation at�https://
www.postgresql.org/docs/current/static/libpq-ssl.html�should be updated to
make this more clear. It should be made clear that the existence of the
file ~/.postgresql/root.crt changes the behavior of sslmode=require and
sslmode=prefer.Agreed. It's basically backwards compatibility with something that was badly
documented in the first place :) That's not a particularly strong argument for
the way it is. Clarifying the documentation would definitely be a good
improvement.
Does this have to remain backward-compatible forever?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 23, 2016 at 1:50 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote:
However, if this is the expected behavior, the documentation
at https://
www.postgresql.org/docs/current/static/libpq-ssl.html should be
updated to
make this more clear. It should be made clear that the existence of
the
file ~/.postgresql/root.crt changes the behavior of sslmode=require
and
sslmode=prefer.
Agreed. It's basically backwards compatibility with something that was
badly
documented in the first place :) That's not a particularly strong
argument for
the way it is. Clarifying the documentation would definitely be a good
improvement.Does this have to remain backward-compatible forever?
In general no. But I think the problem here is that if somebody misses the
removal of something backwards compatible, it turns off their security.
Which is not good...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
You would think so.
The default mode of "prefer" is ridiculous in a lot of ways. If you are
using SSL in any shape or form you should simply not use "prefer". That's
really the only answer at this point, unfortunately.
Suppose we changed the default to "require". How crazy would that be?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
The default mode of "prefer" is ridiculous in a lot of ways. If you are
using SSL in any shape or form you should simply not use "prefer". That's
really the only answer at this point, unfortunately.
Suppose we changed the default to "require". How crazy would that be?
You mean, aside from the fact that it breaks every single installation
that hasn't configured with SSL?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
The default mode of "prefer" is ridiculous in a lot of ways. If you are
using SSL in any shape or form you should simply not use "prefer". That's
really the only answer at this point, unfortunately.Suppose we changed the default to "require". How crazy would that be?
You mean, aside from the fact that it breaks every single installation
that hasn't configured with SSL?
No, including that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Suppose we changed the default to "require". How crazy would that be?
You mean, aside from the fact that it breaks every single installation
that hasn't configured with SSL?
No, including that.
I cannot imagine such a plan surviving the first wave of villagers with
torches and pitchforks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 13 Jul 2016 9:28 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Suppose we changed the default to "require". How crazy would that be?
You mean, aside from the fact that it breaks every single installation
that hasn't configured with SSL?No, including that.
Well what's required to "configure SSL" anyways? If you don't have
verify-ca set or a root canal cert present then the server just needs a
certificate -- any certificate. Can the server just cons one up on demand
(or server startup or initdb)?
Yes, that would not help with active MITM attacks but at least removes any
chance that people are unknowingly using an unencrypted connection
vulnerable to passive sniffers.
Import Notes
Reply to msg id not found: CAM-w4HM6vUVckLf0aT0n12Gu8DTPNuqstmB-0Gr2+o00A02uA@mail.gmail.com
Greg Stark <stark@mit.edu> writes:
Well what's required to "configure SSL" anyways? If you don't have
verify-ca set or a root canal cert present then the server just needs a
certificate -- any certificate. Can the server just cons one up on demand
(or server startup or initdb)?
Hmm, good old "snake oil certificate" approach. Yeah, we could probably
have initdb create a cert all the time. I had memories of this taking
an undue amount of time, but it seems pretty fast on a modern server.
Also, we could offer a switch to turn it off if necessary, with the
understanding that non-Unix-socket connections can be expected to fail
if user doesn't install a cert.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Greg Stark <stark@mit.edu> writes:
Well what's required to "configure SSL" anyways? If you don't have
verify-ca set or a root canal cert present then the server just needs a
certificate -- any certificate. Can the server just cons one up on demand
(or server startup or initdb)?Hmm, good old "snake oil certificate" approach. Yeah, we could probably
have initdb create a cert all the time. I had memories of this taking
an undue amount of time, but it seems pretty fast on a modern server.
It can still take a very significant amount of time in some virtual
environments, due to lack of entropy. And virtual environments aren't
exactly uncommon these days...
Also, we could offer a switch to turn it off if necessary, with the
understanding that non-Unix-socket connections can be expected to fail
if user doesn't install a cert.
If we do it we should also ensure it's not enabled on localhost by default.
Though that's a nice "consultant switch" -- more than once just turning
that off (since it's on by default on debian/ubuntu) has fixed a customers
entire performance issue and I could go back home again...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Also, we could offer a switch to turn it off if necessary, with the
understanding that non-Unix-socket connections can be expected to fail
if user doesn't install a cert.
If we do it we should also ensure it's not enabled on localhost by default.
If we could make sure that both Unix-socket and localhost connections do
not do SSL by default, that would make it possible to skip cert generation
in "make check" and buildfarm scenarios, which would be awfully nice for
slower buildfarm critters. I'm not sure though whether libpq should be
given that sort of hardwired knowledge about "localhost".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7/13/16 4:11 PM, Robert Haas wrote:
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander <magnus@hagander.net> wrote:
You would think so.
The default mode of "prefer" is ridiculous in a lot of ways. If you are
using SSL in any shape or form you should simply not use "prefer". That's
really the only answer at this point, unfortunately.Suppose we changed the default to "require". How crazy would that be?
If we think that that is appropriate, should we not also change the
default pg_hba.conf to hostssl lines?
I'm not convinced either of these would go over well.
The original complaint was not actually that "prefer" is a bad default,
but that in the presence of a root certificate on the client, a
certificate validation failure falls back to plain text. That seems
like a design flaw of the "prefer" mode, no matter whether it is the
default or not.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 15, 2016 at 5:10 AM, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
On 7/13/16 4:11 PM, Robert Haas wrote:
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander <magnus@hagander.net>
wrote:
You would think so.
The default mode of "prefer" is ridiculous in a lot of ways. If you are
using SSL in any shape or form you should simply not use "prefer".That's
really the only answer at this point, unfortunately.
Suppose we changed the default to "require". How crazy would that be?
If we think that that is appropriate, should we not also change the
default pg_hba.conf to hostssl lines?I'm not convinced either of these would go over well.
It would actually, IMO, make more sense to change the default pg_hba lines
and not change the client settings... But I'm not sure either of those
would go over well.
The original complaint was not actually that "prefer" is a bad default,
but that in the presence of a root certificate on the client, a
certificate validation failure falls back to plain text. That seems
like a design flaw of the "prefer" mode, no matter whether it is the
default or not.
The entire "prefer" mode is a design flaw, that we unfortunately picked as
default mode.
If it fails *for any reason*, it falls back to plaintext. Thus, you have to
assume it will make a plaintext connection. Thus, it gives you zero
guarantees, so it serves no actual purpose from a security perspective.
it will equally fall back on incompatible SSL configs. Or on a network
hiccup. The presence of the certificate is just one of many different
scenarios where it will fall back.
If you care about encryption, you should pick something else
(require/verify). If you don't care about encryption, you should pick
something else (allow, probably) so as not to pay unnecessary overhead.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 14.07.2016 23:34, Magnus Hagander wrote:
On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:Greg Stark <stark@mit.edu <mailto:stark@mit.edu>> writes:
Well what's required to "configure SSL" anyways? If you don't have
verify-ca set or a root canal cert present then the server just needs a
certificate -- any certificate. Can the server just cons one up on demand
(or server startup or initdb)?Hmm, good old "snake oil certificate" approach. Yeah, we could probably
have initdb create a cert all the time. I had memories of this taking
an undue amount of time, but it seems pretty fast on a modern server.It can still take a very significant amount of time in some virtual
environments, due to lack of entropy. And virtual environments aren't
exactly uncommon these days...
What expire time would you chose for the certificate? One year? Two years?
Which tool is going to re-generate your new cert, once this one expires?
You don't want to run initdb again ...
Regards,
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
The entire "prefer" mode is a design flaw, that we unfortunately picked as
default mode.
...
If you care about encryption, you should pick something else
(require/verify). If you don't care about encryption, you should pick
something else (allow, probably) so as not to pay unnecessary overhead.
Yeah. The problem with going over to any one of those as the built-in
default is that we can't know whether the user cares about encryption
or not; but all the other choices depend on making that value judgment.
"prefer" is surely an ugly compromise, but nonetheless it often manages
to do the right thing for both camps.
I'm inclined to think that a better answer than changing libpq's behavior
is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external
connections.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/15/2016 09:55 AM, Tom Lane wrote:
I'm inclined to think that a better answer than changing libpq's behavior
is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external
connections.
Do those packagers who install dummy certificates and turn SSL on also
change their pg_hba.conf.sample files to use hostssl?. That could go a
long way towards encouraging people.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 15, 2016 at 4:14 AM, Magnus Hagander <magnus@hagander.net> wrote:
The original complaint was not actually that "prefer" is a bad default,
but that in the presence of a root certificate on the client, a
certificate validation failure falls back to plain text. That seems
like a design flaw of the "prefer" mode, no matter whether it is the
default or not.The entire "prefer" mode is a design flaw, that we unfortunately picked as
default mode.
Well, you keep saying that, but what I'm saying is you should stop
complaining about and start figuring out how to fix it. :-)
If it fails *for any reason*, it falls back to plaintext. Thus, you have to
assume it will make a plaintext connection. Thus, it gives you zero
guarantees, so it serves no actual purpose from a security perspective.it will equally fall back on incompatible SSL configs. Or on a network
hiccup. The presence of the certificate is just one of many different
scenarios where it will fall back.If you care about encryption, you should pick something else
(require/verify). If you don't care about encryption, you should pick
something else (allow, probably) so as not to pay unnecessary overhead.
If we think trying to push everyone on to SSL isn't a good plan, then
how about changing the default to allow?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7/15/16 3:07 PM, Andrew Dunstan wrote:
Do those packagers who install dummy certificates and turn SSL on also
change their pg_hba.conf.sample files to use hostssl?. That could go a
long way towards encouraging people.
Debian, which I guess sort of started this, does not, but there are
allusions to it in the TODO list.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7/15/16 4:14 AM, Magnus Hagander wrote:
The entire "prefer" mode is a design flaw, that we unfortunately picked
as default mode.If it fails *for any reason*, it falls back to plaintext. Thus, you have
to assume it will make a plaintext connection. Thus, it gives you zero
guarantees, so it serves no actual purpose from a security perspective.
I could imagine a variant of "prefer" that tries SSL if available, but
fails the connection if the SSL setup fails for some reason (e.g.,
certificates). That would be more similar to how browsers with
HTTPS-Everywhere work.
Modulo that, I don't think that "prefer" is a bad default.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
