Magnus Hagander wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander writes:
Tom Lane wrote:
> Having a connection that
> was encrypted in 8.3 silently become clear-text after installing 8.4
> is just plain NOT acceptable.
>
> I think the patch would be f
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander writes:
>>> Tom Lane wrote:
Having a connection that
was encrypted in 8.3 silently become clear-text after installing 8.4
is just plain NOT acceptable.
I think the patch would be fine if we simply keep the default
On Monday 20 April 2009 11:19:04 Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
> >>> Magnus Hagander wrote:
> > I would actually call the two parameters 'verify-cert' and 'verify-
> > cn',
> > and document t
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> Having a connection that
>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>> is just plain NOT acceptable.
>>>
>>> I think the patch would be fine if we simply keep the default where
>>> it is, however. Is t
Magnus Hagander writes:
> Tom Lane wrote:
>> Having a connection that
>> was encrypted in 8.3 silently become clear-text after installing 8.4
>> is just plain NOT acceptable.
>>
>> I think the patch would be fine if we simply keep the default where
>> it is, however. Is there some point I am mis
Tom Lane wrote:
> Magnus Hagander writes:
>> Patch also changes the default from "prefer" to "disable", per discussion.
>
> I confess to not having paid attention to this thread for awhile.
> I have to violently object to this conclusion --- it is throwing the
> baby out with the bathwater. Unde
Magnus Hagander writes:
> Patch also changes the default from "prefer" to "disable", per discussion.
I confess to not having paid attention to this thread for awhile.
I have to violently object to this conclusion --- it is throwing the
baby out with the bathwater. Under the pretense of being "se
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
>>
>>> Magnus Hagander wrote:
> I would actually call the two parameters 'verify-cert' and 'verify-
> cn',
> and document that they also have "require" behavior. Obviously you
> can't
Bruce Momjian wrote:
> > That's the intention. When you're turning off something, I think it
> > makes sense to use "no"
>
> But that doesn't scale: sslmode currently has four options, soon
> perhaps to be six. The idea is that the items should be of increasing
> security, and adding "no"
Applied. Depending on how we handle this the error text might need to
change but odds are we will still need to report something related to
sslmode/sslverify when root.crt is missing.
---
Bruce Momjian wrote:
> Peter Eisent
Magnus Hagander wrote:
> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
>
> > Magnus Hagander wrote:
> >>> I would actually call the two parameters 'verify-cert' and 'verify-
> >>> cn',
> >>> and document that they also have "require" behavior. Obviously you
> >>> can't verify certificates unle
On Tuesday 14 April 2009 17:05:45 Martin Pitt wrote:
> Of course I assumed that the server and client are on different
> systems. If they are on the same, then we just use the Unix socket and
> don't need all this SSL fuss at all.
That's what you think. Just read the hackers thread about SSL over
On Sunday 12 April 2009 12:52:53 Magnus Hagander wrote:
> This is a different way to do bruces suggestion of a different
> default. That's possibly even clearer. So I can definitely go with
> this, but I think two different parameters makes it more clear and is
> better.
I think altogether c
Stephen Frost [2009-04-14 9:18 -0400]:
> * Martin Pitt (mp...@debian.org) wrote:
> > We couldn't set this up by default, of course, since each installed
> > machine will have a different snakeoil cert (it gets generated during
> > installation).
>
> It's worse than that.. Obviously, you can hav
Stephen Frost [2009-04-14 9:09 -0400]:
> I disagree, and you *can* do authentication without SSL!
I know. But then you do have authentication as well, which was exactly
my point.
Also, I said "not a lot better", not "totally useless".
Martin
--
Martin Pitt| http://www.
* Martin Pitt (mp...@debian.org) wrote:
> Magnus Hagander [2009-04-11 11:50 +0200]:
> > That has just been brought up from previous versions. Perhaps we need to
> > have a system wide root store as well - then you could point that to
> > whatever snakeoil store you have, and it would find the cert
* Martin Pitt (mp...@debian.org) wrote:
> For the record, I don't agree. SSL certificate validation is good, and
> should be done as long as you have a cert installed. Encryption
> without authentication is not worth a lot, after all.
I disagree, and you *can* do authentication without SSL! The b
Hello Bruce,
Bruce Momjian [2009-04-11 8:33 -0400]:
> I noticed you didn't quote the next sentence:
>
> The SSL connection will fail if the server does not present a trusted
> certificate.
Indeed. When I read it first, it seemed unrelatead to me, but now I
understand where this was
Magnus Hagander [2009-04-12 0:58 +0200]:
> Which means that every time I connect, I need to first to make sure that
> the file is there, and that the proper user has permissions to read the
> file, *before* I connect.
Arguably the connection should fail if the file is present, but cannot
be read
Magnus Hagander [2009-04-11 11:50 +0200]:
> It treats self-signed certificates the same way it treats anything else.
> In the case of a self-signed one, the certificate and the CA certificate
> are the same. Thus, you have to copy the server certificate to the client.
Right, that's what I had expe
Magnus Hagander [2009-04-12 0:29 +0200]:
> The option is there already, it's called "none". That's what people are
> asking for - they don't care who they are connecting to, just that the
> traffic is encrypted (be it legitimate or hacked traffic, at least it's
> encrypted).
For the record, I don
On 14 apr 2009, at 04.33, Bruce Momjian wrote:
Magnus Hagander wrote:
I would actually call the two parameters 'verify-cert' and 'verify-
cn',
and document that they also have "require" behavior. Obviously you
can't verify certificates unless you require SSL.
I would prefer having "verify"
Magnus Hagander wrote:
> > I would actually call the two parameters 'verify-cert' and 'verify-cn',
> > and document that they also have "require" behavior. Obviously you
> > can't verify certificates unless you require SSL.
>
> I would prefer having "verify", "verify-no-cn" and "no-verify" or
> s
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Martin Pitt wrote:
I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
>>> Magnus Hagander wrote:
Bruce Momjian wrote:
> Martin Pitt wrote:
>> I do see the benefit of failing to connect to an SSL-enabled server
>> *if* I have a root.crt which doesn't match. But why fail if I don't
>
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> One random idea is to fold both of these settings into sslmode, with
>>> the
>>> following progression:
>>>
>>> disable, allow, prefer, require, require-cert, require-cn
>>>
>>> And then set the default to "disable", because as you say "prefer"
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Bruce Momjian wrote:
Martin Pitt wrote:
I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?
I have digested this thread, and have d
Magnus Hagander wrote:
> > One random idea is to fold both of these settings into sslmode, with
> > the
> > following progression:
> >
> > disable, allow, prefer, require, require-cert, require-cn
> >
> > And then set the default to "disable", because as you say "prefer"
> > is pretty
> > silly
On 12 apr 2009, at 11.13, Peter Eisentraut wrote:
On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
"sslmode=prefer" honestly makes no sense - if I don't care if it
ends up
encrypted or not (which it means), then why not just run with SSL off
and not have to deal with the overhead?
On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
> "sslmode=prefer" honestly makes no sense - if I don't care if it ends up
> encrypted or not (which it means), then why not just run with SSL off
> and not have to deal with the overhead?
Perhaps a large part of the problem at hand is in fac
Bruce Momjian wrote:
> Bruce Momjian wrote:
>> It would be nice if 'sslverify' mimicked 'sslmode', which has these
>> values:
>>
>> disable
>> allow
>> prefer
>> require
>>
>> I don't see how we could use 'allow', but 'disable', 'prefer', and
>> 'require' seem to work for sslver
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Bruce Momjian wrote:
>>> Martin Pitt wrote:
I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?
>>> I have digested this thread, and have don
Tom Lane wrote:
> Magnus Hagander writes:
>> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
>> something like "maybe" or "external" or "file". I'd find it very bad if
>> you can say "sslverify=on" and then *not* end up getting it because of
>> some external factor. That
Bruce Momjian wrote:
> It would be nice if 'sslverify' mimicked 'sslmode', which has these
> values:
>
> disable
> allow
> prefer
> require
>
> I don't see how we could use 'allow', but 'disable', 'prefer', and
> 'require' seem to work for sslverify, like sslmode.
OK, cra
Tom Lane wrote:
> I am of the opinion that sslverify should have these values:
>
> off = never verify
> on = verify if root.crt is present (default behavior)
> force = verify, failing if root.crt is not present
>
> and the people who actually want to be "sure they're secure" can
Magnus Hagander wrote:
Bruce Momjian wrote:
Martin Pitt wrote:
I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?
I have digested this thread, and have done two things: improved the
documentation an
Magnus Hagander writes:
> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
> something like "maybe" or "external" or "file". I'd find it very bad if
> you can say "sslverify=on" and then *not* end up getting it because of
> some external factor. That needs to be clear in t
Tom Lane wrote:
> Magnus Hagander writes:
>> Bruce Momjian wrote:
>>> The only other approach would be to add an sslverify value of
>>> 'try' that tries only if root.crt exists.
>
>> Doesn't "try" make the whole check pretty pointless, and you can just
>> set it to "none" then?
>
> Not at all.
Magnus Hagander writes:
> The option is there already, it's called "none". That's what people are
> asking for -
No, that is NOT what people are asking for. Please stop attacking a
straw man. What people are asking for is that by default, whether to
make the check or not should depend on whethe
Magnus Hagander writes:
> Bruce Momjian wrote:
>> The only other approach would be to add an sslverify value of
>> 'try' that tries only if root.crt exists.
> Doesn't "try" make the whole check pretty pointless, and you can just
> set it to "none" then?
Not at all. What it means is that you con
Tom Lane wrote:
> Bruce Momjian writes:
>> In terms of your suggestion about root.crt, I think sslverify != none
>> should error if it can't verify the server's certificate, whether the
>> root.crt file is there or not. If you are asking for sslverify, it
>> should do that or error, not ignore th
Bruce Momjian wrote:
> Martin Pitt wrote:
>> I do see the benefit of failing to connect to an SSL-enabled server
>> *if* I have a root.crt which doesn't match. But why fail if I don't
>> have one?
>
> I have digested this thread, and have done two things: improved the
> documentation and posted a
Bruce Momjian writes:
> In terms of your suggestion about root.crt, I think sslverify != none
> should error if it can't verify the server's certificate, whether the
> root.crt file is there or not. If you are asking for sslverify, it
> should do that or error, not ignore the setting if there is
Martin Pitt wrote:
> I do see the benefit of failing to connect to an SSL-enabled server
> *if* I have a root.crt which doesn't match. But why fail if I don't
> have one?
I have digested this thread, and have done two things: improved the
documentation and posted a patch to make the error message
Peter Eisentraut wrote:
> On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> > Tom Lane [2009-04-10 1:15 -0400]:
> > > Martin Pitt writesyuqhom#3:
> > > > The test suite detected one regression in libpq, though: Setting
> > > > $PGHOST now complains about a missing root.crt, although this is o
Martin Pitt wrote:
-- Start of PGP signed section.
> Peter Eisentraut [2009-04-10 14:56 +0300]:
> > I assume the server has the snakeoil certificate installed?
>
> It is a self-signed certificate indeed (Debian's ssl-cert package).
>
> > In that case, it is correct that the client refuses to proc
Martin Pitt wrote:
> Peter Eisentraut [2009-04-10 14:56 +0300]:
>> I assume the server has the snakeoil certificate installed? In that case,
>> it
>> is correct that the client refuses to proceed, although the exact manner of
>> breaking could perhaps be improved.
>
> Is it really refusing sel
John R Pierce wrote:
for self-signed certs, you first create a rootca, you can import the
rootca public key/cert to your browser, by offering it as the proper
mime type (I forget the specifics), once accepted into your browser,
the browser will trust any certs created off that root, same as if
Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
The new firefox just says "invalid certificate" and nothing else, and then
somewhere below there is a small link to "Add an exception" and you need a
total of four clicks to proceed. So that looks a lot like that they are
mov
* Peter Eisentraut (pete...@gmx.net) wrote:
> The new firefox just says "invalid certificate" and nothing else, and then
> somewhere below there is a small link to "Add an exception" and you need a
> total of four clicks to proceed. So that looks a lot like that they are
> moving away from easi
* Peter Eisentraut (pete...@gmx.net) wrote:
> On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> > A properly configured server could cause a failure too unless the client
> > is *also* properly configured. Sure, it's good for people to do. No, I
> > don't think we should break things if peo
Martin Pitt writes:
> Tom Lane [2009-04-10 19:01 -0400]:
>> How do you deal with that? If the root cert is real, how do you put
>> in self-signed server certs?
> I'm afraid I don't understand. If an admin replaces the default
> snakeoil cert with a real one which he got signed by a CA, then of
>
Tom Lane [2009-04-10 19:01 -0400]:
> This seems a bit handwavy --- there's a difference between the machine's
> own cert and what it thinks is a root cert.
Sure.
> How do you deal with that? If the root cert is real, how do you put
> in self-signed server certs?
I'm afraid I don't understand. I
Magnus Hagander [2009-04-10 19:14 +0200]:
> It's "secure by default". Without it, most people will *never* get
> protected by verifying the certificate because they will not manually
> copy root certificates there.
The problem and fallacy with security is that if you make it too
tight, people will
Peter Eisentraut [2009-04-10 14:56 +0300]:
> I assume the server has the snakeoil certificate installed? In that case, it
> is correct that the client refuses to proceed, although the exact manner of
> breaking could perhaps be improved.
Is it really refusing self-signed certificates? That woul
Martin Pitt writes:
> The reason why Debian/Ubuntu install a snakeoil SSL certificate and
> configure all packages to use it by default is not because we think
> that this default configuration is "secure" in any way. The reason is
> that configuring it that way is that it becomes darn easy to mak
Peter Eisentraut [2009-04-10 22:46 +0300]:
> This whole debate hinges on the argument that encryption without
> anti-spoofing
> is *not* useful.
I don't disagree, but it is not *worse* than having no encryption at
all.
The reason why Debian/Ubuntu install a snakeoil SSL certificate and
configur
Tom Lane escreveu:
Peter Eisentraut writes:
On Friday 10 April 2009 22:50:02 Tom Lane wrote:
I do not believe it --- there is a significant difference
in the difficulty of passive listening and active spoofing.
Sure, there is a difference. But what is it, and what percentage of users do
yo
[ sorry for double reply, but I missed answering this point ]
Peter Eisentraut writes:
> On Friday 10 April 2009 22:50:02 Tom Lane wrote:
>> If we believe that then we need to also change the server to require
>> a root.crt.
> That would make sense if the server required SSL in the first place.
Peter Eisentraut writes:
> On Friday 10 April 2009 22:50:02 Tom Lane wrote:
>> I do not believe it --- there is a significant difference
>> in the difficulty of passive listening and active spoofing.
> Sure, there is a difference. But what is it, and what percentage of users do
> you think are a
On Friday 10 April 2009 22:50:02 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
> >> I agree with this. Avoiding spoofing is good, but so is on the wire
> >> encryption even if you don't have anti-spoofing. This is a reasonable
> >> set-up an
On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> Uh, no, the right fix is to have a warning/prompt (as pretty much all
> web browsers today do) but then continue to connect.
On that matter, it is interesting to observe where web browsers are heading
today.
It used to be that web browsers
On Friday 10 April 2009 22:44:44 Bruce Momjian wrote:
> The problem is that libpq doesn't have any ability to warn/prompt like
> SSH and web browsers do, so I think Magnus patterned the libpq behavior
> around cases where warning/prompt failed in these environments.
>
> I am not saying the current
Peter Eisentraut writes:
> On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
>> I agree with this. Avoiding spoofing is good, but so is on the wire
>> encryption even if you don't have anti-spoofing. This is a reasonable
>> set-up and we shouldn't just fail on it.
> This whole debate hinges
On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> A properly configured server could cause a failure too unless the client
> is *also* properly configured. Sure, it's good for people to do. No, I
> don't think we should break things if people don't build out a whole PKI
> for PG and configu
On Friday 10 April 2009 21:27:54 Stephen Frost wrote:
> I agree with this. Avoiding spoofing is good, but so is on the wire
> encryption even if you don't have anti-spoofing. This is a reasonable
> set-up and we shouldn't just fail on it.
This whole debate hinges on the argument that encryption
Stephen Frost wrote:
-- Start of PGP signed section.
> * Peter Eisentraut (pete...@gmx.net) wrote:
> > This is not a question of new client with old server. The new version of
> > the
> > client has a more secure default that will possibly prevent it from
> > connecting
> > to *any* server tha
* Peter Eisentraut (pete...@gmx.net) wrote:
> This is not a question of new client with old server. The new version of the
> client has a more secure default that will possibly prevent it from
> connecting
> to *any* server that is not adequately configured.
A properly configured server could
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think I agree with Martin on this. The server doesn't fail if you
> don't provide it a root cert; it just doesn't try to trace client certs
> to the root. It is not apparent why the client should be stricter than
> that, and definitely not apparent why s
On Friday 10 April 2009 17:13:55 Martin Pitt wrote:
> However, we can't afford to break existing installations. If a user
> has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he
> could not connect to a remote SSL 8.3 cluster any more. So the check
> needs at least be turned into a w
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> In the first place, I have never seen such a prompt, despite the fact
>>> that I use ssh constantly to connect to machines that I know do not have
>>> properly signed certificates.
>
>> *really*? Here's what I get as an example (aft
Magnus Hagander writes:
> Tom Lane wrote:
>> In the first place, I have never seen such a prompt, despite the fact
>> that I use ssh constantly to connect to machines that I know do not have
>> properly signed certificates.
> *really*? Here's what I get as an example (after removing the trust):
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> In my experience ssh itself isn't this strict. Why should libpq be?
>
>> ssh prompts the user when this happens. We don't have a mechanism for
>> prompting the user.
>
> In the first place, I have never seen such a prompt, despite
Magnus Hagander writes:
> Tom Lane wrote:
>> In my experience ssh itself isn't this strict. Why should libpq be?
> ssh prompts the user when this happens. We don't have a mechanism for
> prompting the user.
In the first place, I have never seen such a prompt, despite the fact
that I use ssh con
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> It is not apparent why the client should be stricter than
>>> that, and definitely not apparent why such strictness should be the
>>> default behavior.
>
>> It's "secure by default".
>
> In my experience ssh itself isn't this stric
Magnus Hagander writes:
> Tom Lane wrote:
>> It is not apparent why the client should be stricter than
>> that, and definitely not apparent why such strictness should be the
>> default behavior.
> It's "secure by default".
In my experience ssh itself isn't this strict. Why should libpq be?
I th
Tom Lane wrote:
> Martin Pitt writes:
>> I do see the benefit of failing to connect to an SSL-enabled server
>> *if* I have a root.crt which doesn't match. But why fail if I don't
>> have one?
>
> I think I agree with Martin on this. The server doesn't fail if you
> don't provide it a root cert;
Martin Pitt writes:
> I do see the benefit of failing to connect to an SSL-enabled server
> *if* I have a root.crt which doesn't match. But why fail if I don't
> have one?
I think I agree with Martin on this. The server doesn't fail if you
don't provide it a root cert; it just doesn't try to tra
Peter Eisentraut [2009-04-10 14:56 +0300]:
> I assume the server has the snakeoil certificate installed?
It is a self-signed certificate indeed (Debian's ssl-cert package).
> In that case, it is correct that the client refuses to proceed,
> although the exact manner of breaking could perhaps be i
On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> Tom Lane [2009-04-10 1:15 -0400]:
> > Martin Pitt writesyuqhom#3:
> > > The test suite detected one regression in libpq, though: Setting
> > > $PGHOST now complains about a missing root.crt, although this is only
> > > relevant on the server s
Tom Lane [2009-04-10 1:15 -0400]:
> Martin Pitt writesyuqhom#3:
> > The test suite detected one regression in libpq, though: Setting
> > $PGHOST now complains about a missing root.crt, although this is only
> > relevant on the server side (or did I misunderstood this?)
>
> No, that's a progressi
Martin Pitt writes:
> The test suite detected one regression in libpq, though: Setting
> $PGHOST now complains about a missing root.crt, although this is only
> relevant on the server side (or did I misunderstood this?)
No, that's a progression: the client wants to validate the server's
cert, too
Hello all,
I have been packaging cvs snapshots, and now 8.4 beta 1 for Debian
recently, and hammered on postgresql-common enough to make it work
with 8.4 now (some changed semantics, migration of obsolete/renamed
postgresql.conf settings, etc.). Almost all of the tests pass now, so
it's generally
83 matches
Mail list logo
