Thread: sslmode verify-ca and verify-full: essentialy the same?
Hi, there. Firstly, as this is my first post on a PgSQL ML, I hope this ML is the good one for my question. I'm trying to secure further some PgSQL servers and am reading documentation about libpq sslmode option. I have a question about that: as I understand the internals of this option, the difference between verify-ca and verify-full is that, for verify-full, client will compare the hostname the server gave and the one in the SSL certificate, and will give up if these two values differ. Am I right up to now? If I'm right, I feel like the extra security of verify-full compared to verify-ca is merely a smoke screen because, as far as I know, nothing prevents a crafted server to read the certificate's hostname and give this one as its own, and the libpq shouldn't show a better MitM protection with verify-full than with verify-ca. If I'm wrong, where am I wrong? How does libpq verify the server's name? Reverse DNS? Other mean? Hoping someone can enlighten me about this, Regards. -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85
Attachment
On Tue, Jan 27, 2015 at 2:29 PM, David Guyot <david.guyot@europecamions-interactive.com> wrote:
Hi, there.
Firstly, as this is my first post on a PgSQL ML, I hope this ML is the
good one for my question.
I'm trying to secure further some PgSQL servers and am reading
documentation about libpq sslmode option. I have a question about that:
as I understand the internals of this option, the difference between
verify-ca and verify-full is that, for verify-full, client will compare
the hostname the server gave and the one in the SSL certificate, and
will give up if these two values differ. Am I right up to now?
Almost correct. It will compare the hostname that the client used (in the connection string) with the hostname in the SSL certificate, and give up if the two values differ.
The server does not give the client a hostname at any point (other than the CN of the certificate).
If I'm right, I feel like the extra security of verify-full compared to
verify-ca is merely a smoke screen because, as far as I know, nothing
prevents a crafted server to read the certificate's hostname and give
this one as its own, and the libpq shouldn't show a better MitM
protection with verify-full than with verify-ca. If I'm wrong, where am
I wrong? How does libpq verify the server's name? Reverse DNS? Other
mean?
libpq uses the hostname that you specify in the connection string (or in an environment variable, or however you end up specifying it).
Ah! So there was my error! Should be good to explain this in the official libpq documentation, don't you think? If I correctly read, the connection string as source of the hostname isn't explicit, there is only the mention that libpq will check that the responding server is “the one I specify”. Once I know that it means “the one I specify in the connection string”, it's all clear, but, IMHO, there's still a doubt when you don't know what that does mean. Anyway, thanks for your help, Magnus. Regards. Le mardi 27 janvier 2015 à 14:37 +0100, Magnus Hagander a écrit : > On Tue, Jan 27, 2015 at 2:29 PM, David Guyot > <david.guyot@europecamions-interactive.com> wrote: > Hi, there. > > Firstly, as this is my first post on a PgSQL ML, I hope this > ML is the > good one for my question. > > I'm trying to secure further some PgSQL servers and am reading > documentation about libpq sslmode option. I have a question > about that: > as I understand the internals of this option, the difference > between > verify-ca and verify-full is that, for verify-full, client > will compare > the hostname the server gave and the one in the SSL > certificate, and > will give up if these two values differ. Am I right up to > now? > > > Almost correct. It will compare the hostname that the client used (in > the connection string) with the hostname in the SSL certificate, and > give up if the two values differ. > > > The server does not give the client a hostname at any point (other > than the CN of the certificate). > > > > > If I'm right, I feel like the extra security of verify-full > compared to > verify-ca is merely a smoke screen because, as far as I know, > nothing > prevents a crafted server to read the certificate's hostname > and give > this one as its own, and the libpq shouldn't show a better > MitM > protection with verify-full than with verify-ca. If I'm wrong, > where am > I wrong? How does libpq verify the server's name? Reverse DNS? > Other > mean? > > > libpq uses the hostname that you specify in the connection string (or > in an environment variable, or however you end up specifying it). > > > > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ -- David Guyot Administrateur système, réseau et télécom / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt 03 29 30 47 85
Attachment
On Tue, Jan 27, 2015 at 02:55:56PM +0100, David Guyot wrote: > Ah! So there was my error! Should be good to explain this in the > official libpq documentation, don't you think? If I correctly read, the > connection string as source of the hostname isn't explicit, there is > only the mention that libpq will check that the responding server is > “the one I specify”. Once I know that it means “the one I specify in the > connection string”, it's all clear, but, IMHO, there's still a doubt > when you don't know what that does mean. > > Anyway, thanks for your help, Magnus. Clarification doc patch attached and applied. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +