On Fri, Sep 13, 2013 at 5:31 PM, Robert Haas wrote:
> On Thu, Sep 12, 2013 at 11:33 AM, Magnus Hagander wrote:
>> Well, undocumented and OpenSSL tend to go hand in hand a lot. Or,
>> well, it might be documented, but not in a useful way. I wouldn't
>> count on it.
>
> The OpenSSL code is some of
On Thu, Sep 12, 2013 at 11:33 AM, Magnus Hagander wrote:
> Well, undocumented and OpenSSL tend to go hand in hand a lot. Or,
> well, it might be documented, but not in a useful way. I wouldn't
> count on it.
The OpenSSL code is some of the worst-formatted spaghetti code I've
ever seen, and the re
On Thu, Sep 12, 2013 at 4:41 PM, Heikki Linnakangas
wrote:
> On 12.09.2013 17:30, Andrew Dunstan wrote:
>>
>>
>> On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
>>>
>>>
>>> I just found out that OpenSSL has added support for SRP in version
>>> 1.0.1. We're already using OpenSSL, so all we need t
* Andrew Dunstan (and...@dunslane.net) wrote:
> You forgot to mention that we'd actually like to get away from being
> tied closely to OpenSSL because it has caused license grief in the
> past (not to mention that it's fairly dirty to manage).
While I agree with this sentiment (and have complained
On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
Now, to a completely different approach:
I just found out that OpenSSL has added support for SRP in version
1.0.1. We're already using OpenSSL, so all we need to do is to provide
a couple of callbacks to OpenSSL, and store SRP verifiers in p
On 12.09.2013 17:30, Andrew Dunstan wrote:
On 09/12/2013 09:10 AM, Heikki Linnakangas wrote:
I just found out that OpenSSL has added support for SRP in version
1.0.1. We're already using OpenSSL, so all we need to do is to provide
a couple of callbacks to OpenSSL, and store SRP verifiers in pg
(reviving an old thread)
On 23.10.2012 19:53, Peter Eisentraut wrote:
On 10/22/12 1:25 PM, Stephen Frost wrote:
* Peter Eisentraut (pete...@gmx.net) wrote:
On 10/12/12 3:44 PM, Stephen Frost wrote:
In general, I think it's good to build on existing implementations where
possible. Perhaps we
On 10/22/12 1:25 PM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 10/12/12 3:44 PM, Stephen Frost wrote:
>>> In general, I think it's good to build on existing implementations where
>>> possible. Perhaps we could even consider using something which already
>>> exists fo
On Mon, Oct 22, 2012 at 6:54 PM, Greg Stark wrote:
> I think we can provide a much better warning however. I think we want
> something like 'WARNING: Server identity signed by unknown and
> untrusted authority "Snakeoil CA"'
>
> We could go even further:
> INFO: Server identity "ACME Debian Machin
On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark wrote:
> We could go even further:
> INFO: Server identity "ACME Debian Machine" certified by "Snakeoil CA"
> WARNING: Server identity signed by unknown and untrusted authority "Snakeoil
> CA"
> HINT: Add either the server certificate or the CA certific
On Sun, Oct 21, 2012 at 5:49 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> I don't see a problem at all with providing the snakeoil cert. In
>> fact, it's quite useful.
>
>> I see a problem with enabling it by default. Because it makes people
>> think they are more secure than they are.
>
> I
On Wed, Oct 10, 2012 at 4:24 PM, Marko Kreen wrote:
> The SCRAM looks good from the quick glance.
SCRAM does have weakness - the info necessary to log in
as client (ClientKey) is exposed during authentication
process.
IOW, the stored auth info can be used to log in as client,
if the attacker can
On Fri, Oct 12, 2012 at 10:47 PM, Stephen Frost wrote:
> * Marko Kreen (mark...@gmail.com) wrote:
>> As it works only on connect
>> time, it can actually be secure, unlike user switching
>> with SET ROLE.
>
> I'm guessing your issue with SET ROLE is that a RESET ROLE can be issued
> later..? If s
On Mon, Oct 22, 2012 at 10:57 AM, Andrew Dunstan wrote:
> On 10/22/2012 10:18 AM, Robert Haas wrote:
>> On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
>> wrote:
>>>
>>> It bugs me every time you have to jump through hoops and get red
>>> warnings for an unknown CA, whereas no encryption
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/12/12 3:44 PM, Stephen Frost wrote:
> > In general, I think it's good to build on existing implementations where
> > possible. Perhaps we could even consider using something which already
> > exists for this?
>
> Sounds like SASL to me.
aiui, t
On 10/12/12 3:44 PM, Stephen Frost wrote:
> wrt future-proofing, I don't like the "#-of-iterations" approach. There
> are a number of examples of how to deal with multiple encryption types
> being supported by a protocol, I'd expect hash'ing could be done in the
> same way. For example, Negotiate
On 10/22/2012 10:18 AM, Robert Haas wrote:
On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
wrote:
It bugs me every time you have to jump through hoops and get red
warnings for an unknown CA, whereas no encryption whatsoever is treated
as fine while being actually even worse.
+1. Ame
On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
wrote:
> It bugs me every time you have to jump through hoops and get red
> warnings for an unknown CA, whereas no encryption whatsoever is treated
> as fine while being actually even worse.
+1. Amen, brother.
--
Robert Haas
EnterpriseDB
Magnus Hagander writes:
> I don't see a problem at all with providing the snakeoil cert. In
> fact, it's quite useful.
> I see a problem with enabling it by default. Because it makes people
> think they are more secure than they are.
I am far from an SSL expert, but I had the idea that the only
On Sun, Oct 21, 2012 at 09:55:50AM +0200, Magnus Hagander wrote:
> I don't see a problem at all with providing the snakeoil cert. In
> fact, it's quite useful.
>
> I see a problem with enabling it by default. Because it makes people
> think they are more secure than they are.
So, what you're sugg
On Mon, Oct 15, 2012 at 1:21 PM, Will Crawford
wrote:
> On 14 October 2012 22:17, Daniel Farina wrote:
>
>> The problem there is that it's a pain to get signed certs in, say, a
>> test environment, so "don't check certs" will make its way into the
>> default configuration, and now you have all p
On 14 October 2012 22:17, Daniel Farina wrote:
> The problem there is that it's a pain to get signed certs in, say, a
> test environment, so "don't check certs" will make its way into the
> default configuration, and now you have all pain and no gain.
This is precisely the issue that Debian dea
On Sun, Oct 14, 2012 at 2:04 AM, Magnus Hagander wrote:
> There's a lot of shades of gray to that one. Way too many to say
> they're right *or* wrong, IMHO.
We can agree it is 'sub-ideal', but there is not one doubt in my mind
that it is not 'right' given the scope of Debian's task, which does
*
On Sun, Oct 14, 2012 at 5:59 AM, Daniel Farina wrote:
> On Sat, Oct 13, 2012 at 7:00 AM, Andrew Dunstan wrote:
>> Does Debian they create a self-signed certificate? If so, count me as
>> unimpressed. I'd argue that's worse than doing nothing. Here's what the docs
>> say (rightly) about such certi
On Sat, Oct 13, 2012 at 7:00 AM, Andrew Dunstan wrote:
> Does Debian they create a self-signed certificate? If so, count me as
> unimpressed. I'd argue that's worse than doing nothing. Here's what the docs
> say (rightly) about such certificates:
Debian will give you a self signed certificate by
On Wed, Oct 10, 2012 at 11:41 AM, Heikki Linnakangas
wrote:
> 1. Salt length. Greg Stark calculated the odds of salt collisions here:
> http://archives.postgresql.org/pgsql-hackers/2004-08/msg01540.php. It's not
> too bad as it is, and as Greg pointed out, if you can eavesdrop it's likely
> you ca
* Andrew Dunstan (and...@dunslane.net) wrote:
> Does Debian they create a self-signed certificate? If so, count me
> as unimpressed. I'd argue that's worse than doing nothing. Here's
> what the docs say (rightly) about such certificates:
Self-signed certificates do provide for in-transit encryptio
On 10/13/2012 01:55 AM, Darren Duncan wrote:
John R Pierce wrote:
On 10/12/12 9:00 PM, Darren Duncan wrote:
And now we're migrating to Red Hat for the production launch, using
the http://www.postgresql.org/download/linux/redhat/ packages for
Postgres 9.1, and these do *not* include the SSL.
John R Pierce wrote:
On 10/12/12 9:00 PM, Darren Duncan wrote:
And now we're migrating to Red Hat for the production launch, using
the http://www.postgresql.org/download/linux/redhat/ packages for
Postgres 9.1, and these do *not* include the SSL.
hmm? I'm using the 9.1 for CentOS 6(RHEL 6)
On 10/12/12 9:00 PM, Darren Duncan wrote:
And now we're migrating to Red Hat for the production launch, using
the http://www.postgresql.org/download/linux/redhat/ packages for
Postgres 9.1, and these do *not* include the SSL.
hmm? I'm using the 9.1 for CentOS 6(RHEL 6) and libpq.so certainly
Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
Problem is, the fact that setting up SSL correctly is hard is outside of
our control.
Agreed, though the packagers do make it easier..
Unless we can give people a "run these three commands on each server and
you're now SSL authent
On 10/12/12 4:25 PM, Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
>Unless we can give people a "run these three commands on each server and
>you're now SSL authenticating" script, we can continue to expect the
>majority of users not to use SSL. And I don't think that level of
>
* Josh Berkus (j...@agliodbs.com) wrote:
> Problem is, the fact that setting up SSL correctly is hard is outside of
> our control.
Agreed, though the packagers do make it easier..
> Unless we can give people a "run these three commands on each server and
> you're now SSL authenticating" script, w
On 10/12/12 12:44 PM, Stephen Frost wrote:
> Don't get me wrong- I really dislike that
> we don't have something better today for people who insist on password
> based auth, but perhaps we should be pushing harder for people to use
> SSL instead?
Problem is, the fact that setting up SSL correctly
* Marko Kreen (mark...@gmail.com) wrote:
> As it works only on connect
> time, it can actually be secure, unlike user switching
> with SET ROLE.
I'm guessing your issue with SET ROLE is that a RESET ROLE can be issued
later..? If so, I'd suggest that we look at fixing that, but realize it
could b
Heikki,
Like these proposals in general.
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> For future-proofing, it would be good to send the
> number of iterations the hash is applied as part of the protocol, so
> that it can be configured in the server or we can just raise the
> default/ha
On Wed, Oct 10, 2012 at 3:36 PM, Simon Riggs wrote:
> On 10 October 2012 11:41, Heikki Linnakangas wrote:
>> Thoughts on that?
>
> I think there has been enough discussion of md5 problems elsewhere
> that we should provide an alternative.
>
> If we can agree on that bit first, we can move onto ex
On 10 October 2012 11:41, Heikki Linnakangas wrote:
> Thoughts on that?
I think there has been enough discussion of md5 problems elsewhere
that we should provide an alternative.
If we can agree on that bit first, we can move onto exactly what else
should be available.
--
Simon Riggs
38 matches
Mail list logo
