SSL cleanups/hostname verification
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
"sslverify", and can be set to:
* cn = default = will validate that the certificate chains to a trusted
root, *and* that the cn on the certificate matches the hostname
specificed in the connection. This is the only option that prevents
man-in-the-middle attacks completely, and therefor is the default.
* cert = what we had before if there was a root certificate file = will
validate that the certificate chains to a trusted root, but ignore the cn.
* none = will disable certificate validation completely
This means that the connection string is now in charge of the security
policy, and not just the "if file exists or not". IMHO this is the only
proper way to do it. Now, if you for some reason loose the root
certificate file, libpq will refuse to connect unless you have
explicitly told it to connect without verifying the certificate.
Previously if you accidentally lost the file, you would connect
insecurely without knowing about it.
The error messages from the patch requires the
libpq-error-message-stacking patch as well (or something like it),
otherwise the error message will often get overwritten by a later one if
we retry without SSL.
I intend to follow this up with a similar patch for the server side,
which will make it a connection option instead of being dependent on the
presence of a file. This is depending on the pg_hba options patch,
however, so it's not ready yet.
//Magnus
Attachments:
libpq_ssl.patchtext/x-diff; name=libpq_ssl.patchDownload+167-98
Magnus Hagander <magnus@hagander.net> writes:
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
"sslverify", and can be set to:
* cn = default = will validate that the certificate chains to a trusted
root, *and* that the cn on the certificate matches the hostname
specificed in the connection. This is the only option that prevents
man-in-the-middle attacks completely, and therefor is the default.
How can you make that the default? Won't it immediately break every
installation without certificates?
The patch seems pretty far short of sufficient as far as supporting a
new conninfo option goes --- for instance it appears to leak the string
at disconnect. Check through all the references to some existing option
field to see if you missed anything else.
regards, tom lane
Tom Lane wrote:
Magnus Hagander <magnus@hagander.net> writes:
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
"sslverify", and can be set to:* cn = default = will validate that the certificate chains to a trusted
root, *and* that the cn on the certificate matches the hostname
specificed in the connection. This is the only option that prevents
man-in-the-middle attacks completely, and therefor is the default.How can you make that the default? Won't it immediately break every
installation without certificates?
*all* SSL installations have certificate on the server side. You cannot
run without it.
And obviously the setting only has effect if you are actually running
over SSL.
The patch seems pretty far short of sufficient as far as supporting a
new conninfo option goes --- for instance it appears to leak the string
at disconnect. Check through all the references to some existing option
field to see if you missed anything else.
Hmm. yeah, I hadn't finished that part - and promptly forgot about that
:S Will look it over again.
//Magnus
How can you make that the default? Won't it immediately break every
installation without certificates?*all* SSL installations have certificate on the server side. You cannot
run without it.
s/without certificates/with self-signed certificates/
which I would guess to be a common configuration
...Robert
Robert Haas wrote:
How can you make that the default? Won't it immediately break every
installation without certificates?*all* SSL installations have certificate on the server side. You cannot
run without it.s/without certificates/with self-signed certificates/
which I would guess to be a common configuration
Self-signed still work. In a self-signed scenario, the server
certificate *is* the CA certificate.
//Magnus
Robert Haas wrote:
How can you make that the default? Won't it immediately break every
installation without certificates?*all* SSL installations have certificate on the server side. You cannot
run without it.s/without certificates/with self-signed certificates/
which I would guess to be a common configuration
Yeah, but those setups are already broken anyway; the users just appear
not to know it.
If you install a new web browser, would you want it to be configured by
default to warn about untrusted certificates or to "not bother" the user
about it? It's pretty much the same question here.
Magnus Hagander wrote:
Robert Haas wrote:
How can you make that the default? Won't it immediately break every
installation without certificates?*all* SSL installations have certificate on the server side. You cannot
run without it.s/without certificates/with self-signed certificates/
which I would guess to be a common configuration
Self-signed still work. In a self-signed scenario, the server
certificate *is* the CA certificate.
But the user needs to copy the CA to the client, which most people
probably don't do nowadays.
On 21 okt 2008, at 10.04, Peter Eisentraut <peter_e@gmx.net> wrote:
Magnus Hagander wrote:
Robert Haas wrote:
How can you make that the default? Won't it immediately break
every
installation without certificates?*all* SSL installations have certificate on the server side. You
cannot
run without it.s/without certificates/with self-signed certificates/
which I would guess to be a common configuration
Self-signed still work. In a self-signed scenario, the server
certificate *is* the CA certificate.But the user needs to copy the CA to the client, which most people
probably don't do nowadays.
True. I'll update the docs to make this even more clear, for those who
don't know ssl. I still consider that a feature and not a problem ..
/magnus
Then they may as well not have bothered with generating a key in the
first place since an attacker can generate one of his own just as
easily...
Actually that's not entirely true. A non-authenticated connection
still protects against passive attacks like sniffers. But active
attacks are known in the wild.
greg
On 21 Oct 2008, at 09:04 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
Show quoted text
Magnus Hagander wrote:
Robert Haas wrote:
How can you make that the default? Won't it immediately break
every
installation without certificates?*all* SSL installations have certificate on the server side. You
cannot
run without it.s/without certificates/with self-signed certificates/
which I would guess to be a common configuration
Self-signed still work. In a self-signed scenario, the server
certificate *is* the CA certificate.But the user needs to copy the CA to the client, which most people
probably don't do nowadays.--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 21, 2008 at 11:02:11AM +0300, Peter Eisentraut wrote:
If you install a new web browser, would you want it to be configured by
default to warn about untrusted certificates or to "not bother" the user
about it? It's pretty much the same question here.
We "don't bother" users when there is no certificate at all, so why
would you if the certificate is untrusted?
You seem to be making the assertion that making an encrypted connection
to an untrusted server is worse than making a plaintext connection to
an untrusted server, which seems bogus to me.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.
Martijn van Oosterhout <kleptog@svana.org> writes:
You seem to be making the assertion that making an encrypted connection
to an untrusted server is worse than making a plaintext connection to
an untrusted server, which seems bogus to me.
Hm, is it? If you use good old traditional telnet you know you're typing on an
insecure connection. If you use ssh you expect it to be secure and indeed ssh
throws up big errors if it fails to get a secure connection -- it doesn't
silently fall back to an insecure connection.
Actually even the example given before of the browsers follows this model. If
you visit an insecure web site you get your web page. But if you visit a
secure web site with a bogus certificate you get a big warning.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
On Tue, Oct 21, 2008 at 11:55:32AM +0100, Gregory Stark wrote:
Martijn van Oosterhout <kleptog@svana.org> writes:
You seem to be making the assertion that making an encrypted connection
to an untrusted server is worse than making a plaintext connection to
an untrusted server, which seems bogus to me.Hm, is it? If you use good old traditional telnet you know you're typing on an
insecure connection. If you use ssh you expect it to be secure and indeed ssh
throws up big errors if it fails to get a secure connection -- it doesn't
silently fall back to an insecure connection.
SSH is a good example, it only works with self-signed certificates, and
relies on the client to check it. Libpq provides a mechanism for the
client to verify the server's certificate, and that is safe even if it
is self-signed.
If the client knows the certificate the server is supposed to present,
then you can't have a man-in-the-middle attack, right? Whether it's
self-signed or not is irrelevent.
Preventing casual snooping without preventing MitM is a rational choice
for system administrators.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.
On 21 okt 2008, at 13.12, Martijn van Oosterhout <kleptog@svana.org>
wrote:
On Tue, Oct 21, 2008 at 11:55:32AM +0100, Gregory Stark wrote:
Martijn van Oosterhout <kleptog@svana.org> writes:
You seem to be making the assertion that making an encrypted
connection
to an untrusted server is worse than making a plaintext connection
to
an untrusted server, which seems bogus to me.Hm, is it? If you use good old traditional telnet you know you're
typing on an
insecure connection. If you use ssh you expect it to be secure and
indeed ssh
throws up big errors if it fails to get a secure connection -- it
doesn't
silently fall back to an insecure connection.SSH is a good example, it only works with self-signed certificates,
and
relies on the client to check it. Libpq provides a mechanism for the
client to verify the server's certificate, and that is safe even if it
is self-signed.
Are you referring to the method we have now? If so, it has two
problems: it's not enforceable from the app, and it's off by default.
Other than that, it works.
If the client knows the certificate the server is supposed to present,
then you can't have a man-in-the-middle attack, right? Whether it's
self-signed or not is irrelevent.
Yes. The importance being that it must know which, and not just
blindly accept anything.
Preventing casual snooping without preventing MitM is a rational
choice
for system administrators.
Yes, but it should not be the default. It still allows you to do this...
/mha
Martijn van Oosterhout wrote:
SSH is a good example, it only works with self-signed certificates, and
relies on the client to check it. Libpq provides a mechanism for the
client to verify the server's certificate, and that is safe even if it
is self-signed.If the client knows the certificate the server is supposed to present,
then you can't have a man-in-the-middle attack, right? Whether it's
self-signed or not is irrelevent.
That appears to be correct, but that was not the original issue under
discussion.
Both a web browser and an SSH client will, when faced with an untrusted
certificate, pop a question to the user. The user then verifies the
certificate some other way (in theory), answers/clicks yes, and then web
browser and SSH client store the certificate locally marked as trusted,
so this question goes away the next time.
An SSL-enabled libpq program will, when faced with an untrusted
certificate, go ahead anyway, without notification. (Roughly speaking.
If I understand this right, there are other scenarios depending on
whether the client user has set up the requires files in ~/.postgresql.
All this just leads users to do the wrong thing by neglect, ignorance,
or error.)
The change Magnus proposes is that SSL-enabled libpq programs will in
the future refuse to connect without a trusted certificate. Being a
library, we cannot really go ask the user, as web browser and SSH client
do, but I could imagine that we could make psql do that and store the
trusted certificate automatically in a local place. Then we would be
close to the usual operating mode for SSH and web browsers, and then
chances are better that users can understand this setup and use it
securely and easily.
Preventing casual snooping without preventing MitM is a rational choice
for system administrators.
I am not an expert in these things, but it seems to me that someone who
can casually snoop can also casually insert DHCP or DNS packages and
redirect traffic. There is probably a small niche where just encryption
without server authentication prevents information leaks, but it is not
clear to me where this niche is or how it can be defined, and I
personally wouldn't encourage this sort of setup.
On 21 okt 2008, at 13.41, Peter Eisentraut <peter_e@gmx.net> wrote:
Show quoted text
Martijn van Oosterhout wrote:
SSH is a good example, it only works with self-signed certificates,
and
relies on the client to check it. Libpq provides a mechanism for the
client to verify the server's certificate, and that is safe even if
it
is self-signed.
If the client knows the certificate the server is supposed to
present,
then you can't have a man-in-the-middle attack, right? Whether it's
self-signed or not is irrelevent.That appears to be correct, but that was not the original issue
under discussion.Both a web browser and an SSH client will, when faced with an
untrusted certificate, pop a question to the user. The user then
verifies the certificate some other way (in theory), answers/clicks
yes, and then web browser and SSH client store the certificate
locally marked as trusted, so this question goes away
Preventing casual snooping without preventing MitM is a rational
choice
for system administrators.I am not an expert in these things, but it seems to me that someone
who can casually snoop can also casually insert DHCP or DNS packages
and redirect traffic. There is probably a small niche where just
encryption without server authentication prevents information leaks,
but it is not clear to me where this niche is or how it can be
defined, and I personally wouldn't encourage this sort of setup.
On 21 okt 2008, at 13.41, Peter Eisentraut <peter_e@gmx.net> wrote:
Martijn van Oosterhout wrote:
SSH is a good example, it only works with self-signed certificates,
and
relies on the client to check it. Libpq provides a mechanism for the
client to verify the server's certificate, and that is safe even if
it
is self-signed.
If the client knows the certificate the server is supposed to
present,
then you can't have a man-in-the-middle attack, right? Whether it's
self-signed or not is irrelevent.That appears to be correct, but that was not the original issue
under discussion.Both a web browser and an SSH client will, when faced with an
untrusted certificate, pop a question to the user. The user then
verifies the certificate some other way (in theory), answers/clicks
yes, and then web browser and SSH client store the certificate
locally marked as trusted, so this question goes away the next time.An SSL-enabled libpq program will, when faced with an untrusted
certificate, go ahead anyway, without notification. (Roughly
speaking. If I understand this right, there are other scenarios
depending on whether the client user has set up the requires files
in ~/.postgresql. All this just leads users to do the wrong thing
by neglect, ignorance, or error.)The change Magnus proposes is that SSL-enabled libpq programs will
in the future refuse to connect without a trusted certificate.
Being a library, we cannot really go ask the user, as web browser
and SSH client do, but I could imagine that we could make psql do
that and store the trusted certificate automatically in a local
place. Then we would be close to the usual operating mode for SSH
and web browsers, and then chances are better that users can
understand this setup and use it securely and easily.Preventing casual snooping without preventing MitM is a rational
choice
for system administrators.I am not an expert in these things, but it seems to me that someone
who can casually snoop can also casually insert DHCP or DNS packages
and redirect traffic. There is probably a small niche where just
encryption without server authentication prevents information leaks,
but it is not clear to me where this niche is or how it can be
defined, and I personally wouldn't encourage this sort of setup.
Yes, see the discussion with Dan Kaminsky on list a while back, which
is what prompted me to finally getting around to fixing this long-time
todo...
/mha
Martijn van Oosterhout <kleptog@svana.org> writes:
SSH is a good example, it only works with self-signed certificates, and
relies on the client to check it. Libpq provides a mechanism for the
client to verify the server's certificate, and that is safe even if it
is self-signed.
Sort of. SSH requires you to install the certificate of the server locally
before connecting. If you don't it pops up a big warning and asks if you want
to install it. On subsequent connections it looks up the key for the name of
the host you're trying to connect to and insists it match. If it doesn't it
pops up a *huge* error and refuses to connect.
Preventing casual snooping without preventing MitM is a rational choice
for system administrators.
I think the word you're looking for is "naive" :)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
Gregory Stark <stark@enterprisedb.com> writes:
Sort of. SSH requires you to install the certificate of the server locally
before connecting. If you don't it pops up a big warning and asks if you want
to install it. On subsequent connections it looks up the key for the name of
the host you're trying to connect to and insists it match. If it doesn't it
pops up a *huge* error and refuses to connect.
Um, IIRC what it's checking there is the server's key signature, which
has nada to do with certificates.
regards, tom lane
On Tue, Oct 21, 2008 at 08:47:35AM -0400, Tom Lane wrote:
Um, IIRC what it's checking there is the server's key signature, which
has nada to do with certificates.
That depends on whether you used an X.509 certificate to authenticate
the original signature. Just about nobody does, but AIUI, there's a
way to do so. Anyway, in the strict sense you're right, but the
comparison is wrong anyway. SSH doesn't pretend to be authenticating
over SSL. It's authenticating using the SSH protocol, which has its
own RFCs describing it.
If I understand the description of the current behaviour, I have to
agree with those who say the current behaviour is almost worse than
nothing. In the presence of DNS forgery (and I'll bet a pretty good
lunch most people aren't using DNSSEC), it's not hard to send a client
to the wrong server. If the ssl-using client will blithely proceed if
it can't authenticate the server, it's pretty hard to see in what
sense this is a conforming use of anything I know as SSL. SSL is
supposed to provide both encryption and authentication (the
self-signed certificate nonsense is actually breakage that everyone in
the protocol community wails about whenever given the opportunity,
because of the results in user behaviour. It was a compromise that
people made back in the period when Verisign had a lock on the market
and would charge you an arm and a leg for a cert).
A
[Actually, to be pedantic, it might be better to call the
authentication method TLS, so as not to conflate it with the
Netscape-defined SSL. But this is maybe straying into a different
topic.]
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
On Tuesday 21 October 2008 15:47:35 Tom Lane wrote:
Gregory Stark <stark@enterprisedb.com> writes:
Sort of. SSH requires you to install the certificate of the server
locally before connecting. If you don't it pops up a big warning and asks
if you want to install it. On subsequent connections it looks up the key
for the name of the host you're trying to connect to and insists it
match. If it doesn't it pops up a *huge* error and refuses to connect.Um, IIRC what it's checking there is the server's key signature, which
has nada to do with certificates.
It checks the fingerprint of the server public key. And a certificate is
exactly a public key with additional information that explains whose public
key that is. So when you install the fingerprint sent by the SSH server in
your local known_hosts, then the server public key becomes a certificate.
Sort of. But it's related.
