On Thu, Nov 13, 2008 at 01:05, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> It means I will go ahead and apply it once I have looked it over once more.
>
> Thanks for review+testing!
>
> You may now move on to the next ssl patch if you're interested ;)
Sure thing probably wont get to it till tomor
It means I will go ahead and apply it once I have looked it over once
more.
Thanks for review+testing!
You may now move on to the next ssl patch if you're interested ;)
/Magnus
On 12 nov 2008, at 17.05, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
OK now that im using the right env var eve
OK now that im using the right env var everything seems to work as
described. FYI I also tried to exercise the various new error paths
and everything seems good so as far as i'm concerned this looks good
to me. Ill go mark it as "ready for commiter" on the wiki. (whatever
that means you being a
On 12 nov 2008, at 05.28, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander <[EMAIL PROTECTED]>
wrote:
Alex Hunsaker wrote:
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander
<[EMAIL PROTECTED]> wrote:
$ SSLVERIFY=cn ./psql junk -h 192.168.0.2
psql: se
On Tue, Nov 11, 2008 at 06:16, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
>> On Mon, Oct 20, 2008 at 05:50, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
>> $ SSLVERIFY=cn ./psql junk -h 192.168.0.2
>> psql: server common name 'bahdushka' does not match hostname
>> '192.168.0.
Alex Hunsaker wrote:
> On Mon, Oct 20, 2008 at 05:50, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> $ SSLVERIFY=cn ./psql junk -h 192.168.0.2
> psql: server common name 'bahdushka' does not match hostname
> '192.168.0.2'FATAL: no pg_hba.conf entry for host "192.168.0.2", user
> "alex", database "j
On Mon, Oct 20, 2008 at 05:50, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> 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 certifi
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> 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:
>
> Because SSL offers both encryption and authentication, I wonder if we
>
Magnus Hagander wrote:
> 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:
Because SSL offers both encryption and authentication, I wonder if we
should call this "sslauthentica
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Looking over it again, that's pretty much the only one I find. I checked
> against sslmode. Did you spot something else?
No, I just thought that it looked like too small a patch for adding
a new conn option, and complained as soon as I found something
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> 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
On Tuesday 21 October 2008 15:47:35 Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> 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 connectio
On Tue, Oct 21, 2008 at 02:41:11PM +0300, Peter Eisentraut wrote:
> >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
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, t
Gregory Stark <[EMAIL PROTECTED]> 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 try
Martijn van Oosterhout <[EMAIL PROTECTED]> 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. S
On 21 okt 2008, at 13.41, Peter Eisentraut <[EMAIL PROTECTED]> 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 t
On 21 okt 2008, at 13.41, Peter Eisentraut <[EMAIL PROTECTED]> 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 t
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 th
On 21 okt 2008, at 13.12, Martijn van Oosterhout <[EMAIL PROTECTED]>
wrote:
On Tue, Oct 21, 2008 at 11:55:32AM +0100, Gregory Stark wrote:
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
You seem to be making the assertion that making an encrypted
connection
to an untrusted server is wo
On Tue, Oct 21, 2008 at 11:55:32AM +0100, Gregory Stark wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> 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
Martijn van Oosterhout <[EMAIL PROTECTED]> 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 y
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 whe
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 k
On 21 okt 2008, at 10.04, Peter Eisentraut <[EMAIL PROTECTED]> 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
r
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
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
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 wo
>> 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 conf
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> 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 ch
Magnus Hagander <[EMAIL PROTECTED]> 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
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 hos
32 matches
Mail list logo
