On Mon, Apr 10, 2017 at 6:39 PM, Álvaro Hernández Tortosa
wrote:
> - I think channel binding support should be added. SCRAM brings security
> improvements over md5 and other simpler digest algorithms. But where it
> really shines is together with channel binding. This is the only method to
> preve
On 04/10/2017 09:28 PM, Álvaro Hernández Tortosa wrote:
On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
* The nonce length is not specified by the RFC. I see typical
implementations use 24 chars for the client and 18 for the server.
Current c
On 14 April 2017 at 20:20, Peter Eisentraut
wrote:
>
> Yeah, I think if you're concerned about MITM then you would also be
> concerned about MITM siphoning off your data. So you should be using
> TLS and then you don't need channel binding.
No. You can use TLS for authentication (by verifying SS
On 4/11/17 09:03, Magnus Hagander wrote:
> I would expect most enterprise customers who care about MITM protection
> are already using either TLS or ipsec to cover that already. They have
> benefit from the other parts of SCRAM, but they've already solved those
> problems.
Yeah, I think if you're
On Thu, Apr 13, 2017 at 3:21 AM, Robert Haas wrote:
> On Wed, Apr 12, 2017 at 2:09 PM, Heikki Linnakangas wrote:
>> Yes, we need to nail down the protocol and \password before beta. I am
>> working on them now.
>
> Good to hear.
FWIW, there are patches for each issue.
--
Michael
--
Sent via
On Wed, Apr 12, 2017 at 2:09 PM, Heikki Linnakangas wrote:
> That is very much appreciated! You writing a second implementation of the
> client-side support (libpq being the first) is very, very helpful, to
> validate that the protocol is sane, unambiguous, and adequately documented.
+1.
> Yes,
On 04/12/2017 08:38 PM, Álvaro Hernández Tortosa wrote:
- Even though I don't really care about SCRAM, and without having any
prior knowledge about SCRAM, I volunteered some time ago to study SCRAM,
give a lightning talk about SCRAM and later write a client
implementation for the jdbc driver. And
On 12/04/17 18:38, Robert Haas wrote:
On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa
wrote:
LOL. Do you really want a half-baked Java programmer writing a patch in
C for PostgreSQL? I once tried that and Magnus said my code was Java code
that happened to compile with a C compi
On 12/04/17 18:09, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/12/2017 06:26 PM, Bruce Momjian wrote:
How does it do that?
Good question, crypto magic? I don't know the details, but the basic
idea is that you extract a blob of data that uniquely identifies the TLS
connection. Using som
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... which the user can't tell apart from having fat-fingered the password,
>> I suppose? Doesn't sound terribly friendly. A report of a certificate
>> mismatch is far more likely to lead people to realize there's a MITM.
> We mig
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... which the user can't tell apart from having fat-fingered the password,
> I suppose? Doesn't sound terribly friendly. A report of a certificate
> mismatch is far more likely to lead people to realize there's a MITM.
We might be able to impro
On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa
wrote:
> LOL. Do you really want a half-baked Java programmer writing a patch in
> C for PostgreSQL? I once tried that and Magnus said my code was Java code
> that happened to compile with a C compiler ^_^
>
> Having said that,
Heikki Linnakangas writes:
> On 04/12/2017 06:26 PM, Bruce Momjian wrote:
>> How does it do that?
> Good question, crypto magic? I don't know the details, but the basic
> idea is that you extract a blob of data that uniquely identifies the TLS
> connection. Using some OpenSSL functions, in this
On 04/12/2017 06:26 PM, Bruce Momjian wrote:
On Wed, Apr 12, 2017 at 12:13:03PM +0300, Heikki Linnakangas wrote:
That said, I stand by my comment that I don't think it's the enterprises
that need or want the channel binding. If they care about it, they have
already put certificate validation in
On Wed, Apr 12, 2017 at 12:13:03PM +0300, Heikki Linnakangas wrote:
> >That said, I stand by my comment that I don't think it's the enterprises
> >that need or want the channel binding. If they care about it, they have
> >already put certificate validation in place, and it won't buy them anything.
On 12 Apr. 2017 17:27, "Magnus Hagander" wrote:
On Wed, Apr 12, 2017 at 11:13 AM, Heikki Linnakangas
wrote:
> On 04/12/2017 11:22 AM, Magnus Hagander wrote:
>
>> On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian wrote:
>>
>> And which enterprises are using SSL without certificates? And I thoug
On Wed, Apr 12, 2017 at 11:13 AM, Heikki Linnakangas
wrote:
> On 04/12/2017 11:22 AM, Magnus Hagander wrote:
>
>> On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian wrote:
>>
>> And which enterprises are using SSL without certificates? And I thought
>>> channel binding required certificates anyway,
On 04/12/2017 11:22 AM, Magnus Hagander wrote:
On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian wrote:
And which enterprises are using SSL without certificates? And I thought
channel binding required certificates anyway, e.g.:
https://en.wikipedia.org/wiki/Salted_Challenge_Response_
Au
On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian wrote:
> On Tue, Apr 11, 2017 at 08:58:30PM -0400, Stephen Frost wrote:
> > > > But just a bit more is needed to make it really a big
> announcement and
> > > > provide real value to (I guess, mostly but very interesting)
> enterprise
> > > > cus
On Tue, Apr 11, 2017 at 08:58:30PM -0400, Stephen Frost wrote:
> > > But just a bit more is needed to make it really a big announcement and
> > > provide real value to (I guess, mostly but very interesting) enterprise
> > > customers, for which MITM and impersonating are big things. The good ne
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Apr 11, 2017 at 02:53:24PM +0200, Álvaro Hernández Tortosa wrote:
> > Let's put ourselves on the foot of potential users. Why would anyone
> > want to use SCRAM? What for? The hashing mechanism is better, no question.
> > And bring som
On Tue, Apr 11, 2017 at 02:53:24PM +0200, Álvaro Hernández Tortosa wrote:
> Let's put ourselves on the foot of potential users. Why would anyone
> want to use SCRAM? What for? The hashing mechanism is better, no question.
> And bring some added benefits, true. So its "better". But the real gain
On 11/04/17 15:18, Heikki Linnakangas wrote:
On 04/11/2017 04:09 PM, Álvaro Hernández Tortosa wrote:
But I will conserve my remaining courage (thanks Michael!) credits
for future threads ;) I have stated my opinion clearly, I will now go
back to the client library.
Once you're done with
On 04/11/2017 04:09 PM, Álvaro Hernández Tortosa wrote:
But I will conserve my remaining courage (thanks Michael!) credits
for future threads ;) I have stated my opinion clearly, I will now go
back to the client library.
Once you're done with the client library, feel free to post a patch t
On 11/04/17 15:03, Magnus Hagander wrote:
On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa
mailto:a...@8kdata.com>> wrote:
On 10/04/17 20:32, Andres Freund wrote:
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
On 10/04/17 13:02, Heikki Linn
On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa
wrote:
>
>
> On 10/04/17 20:32, Andres Freund wrote:
>
>> On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
>>
>>>
>>> On 10/04/17 13:02, Heikki Linnakangas wrote:
>>>
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote
On Tue, Apr 11, 2017 at 9:53 PM, Álvaro Hernández Tortosa
wrote:
> I know this is a lost battle. But please bear with me for a minute.
I admire your courage.
> But just a bit more is needed to make it really a big announcement and
> provide real value to (I guess, mostly but very interes
On 10/04/17 20:32, Andres Freund wrote:
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements ov
On Mon, Apr 10, 2017 at 2:32 PM, Andres Freund wrote:
> That can equally be said about about a lot of features. If we don't
> stop at some point... Also, we're not late in the CF cycle, the CF cycle
> for v10 is over. It's not like the non-existance of channel binding
> removes previously existi
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
>
>
> On 10/04/17 13:02, Heikki Linnakangas wrote:
> > On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
> > > - I think channel binding support should be added. SCRAM brings security
> > > improvements over md5 and other simpler
On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements over md5 and other simpler digest algorithms. But where it
really shines is together with channel binding.
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements over md5 and other simpler digest algorithms. But where it
really shines is together with channel binding. This is the only method
to prevent MITM attacks.
Hi!
There's some ongoing discussion about SCRAM (like this thread
https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74b23%40iki.fi)
but I wanted to open a new thread that covers these topics and other,
more general ones. Here are some thoughts based on my perspectiv
Hi!
There's some ongoing discussion about SCRAM (like this thread
https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74b23%40iki.fi)
but I wanted to open a new thread that covers these topics and other,
more general ones. Here are some thoughts based on my perspectiv
34 matches
Mail list logo