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't
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
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
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
* 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 big
* 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
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|
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 have the
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
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
Magnus Hagander wrote:
On 14 apr 2009, at 04.33, Bruce Momjian br...@momjian.us 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
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
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 in the
Your name : Dwight Wilcox
Your email address : dwight.wil...@navy.mil
System Configuration
- -
Architecture : Intel Pentium
Operating System : Windows XP
PostgreSQL version : postgresql-8.3.7-1-windows.exe
Compiler used : not applicable
Please enter a FULL
14 matches
Mail list logo
