On Fri, Aug 31, 2018 at 12:18:52PM +0200, Peter Eisentraut wrote:
> I was updating the gnutls patch for the changed channel binding setup,
> and I noticed that the 002_scram.pl test now passes even though the
> gnutls patch currently does not support channel binding. So AFAICT,
> we're not testing
On 05/08/2018 14:45, Michael Paquier wrote:
> On Sun, Aug 05, 2018 at 03:30:43PM +0300, Heikki Linnakangas wrote:
>> That test just tested that the scram_channel_binding libpq option works, but
>> I removed the option. I know you wanted to keep it as a feature flag, but as
>> discussed earlier, I d
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/08/18 17:34, Stephen Frost wrote:
> >Now- if we thought that maybe there was some connection pooling solution
> >that could be made to work with SSL+SCRAM if channel binding is turned
> >off, then that's a use-case that maybe we shou
On 07/08/18 17:34, Stephen Frost wrote:
* Michael Paquier (mich...@paquier.xyz) wrote:
On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
Well, it'd be useless for users, there is no reason to switch off channel
binding if bo
On Tue, Aug 7, 2018 at 11:08:12PM +0300, Heikki Linnakangas wrote:
> >I know this is an academic question now, but I am not sure this is true.
> >A man-in-the-middle attacker could say they don't support channel
> >binding to the real client and real server and pretend to be the real
> >server. W
On 07/08/18 22:34, Bruce Momjian wrote:
On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
On 12/07/18 07:14, Michael Paquier wrote:
On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
I started digging into this more closely, and ran into a little problem. If
On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
> On 12/07/18 07:14, Michael Paquier wrote:
> >On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
> >>I started digging into this more closely, and ran into a little problem. If
> >>channel binding is not used, the
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
> > On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
> >> Well, it'd be useless for users, there is no reason to switch off channel
> >> binding if both the client and
On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
> On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
>> Well, it'd be useless for users, there is no reason to switch off channel
>> binding if both the client and server support it. It might not add any
>> security you care about
On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
> Well, it'd be useless for users, there is no reason to switch off channel
> binding if both the client and server support it. It might not add any
> security you care about, but it won't do any harm either. The
> non-channel-binding codep
On 5 August 2018 19:01:04 EEST, Tom Lane wrote:
>Heikki Linnakangas writes:
>> Sorry, I see now that there was indeed a test for
>> scram_channel_binding='', which meant "no channel binding". That was
>> confusing, I assumed '' was the default.
>
>Ugh, it isn't? There's a general principle in
Heikki Linnakangas writes:
> Sorry, I see now that there was indeed a test for
> scram_channel_binding='', which meant "no channel binding". That was
> confusing, I assumed '' was the default.
Ugh, it isn't? There's a general principle in libpq that setting a
parameter to an empty string is th
On 05/08/18 17:11, I wrote:
The only negative test there was, was to check for bogus
scram_channel_binding option, "scram_channel_binding=not-exists". Yeah,
it would be nice to have some, but this commit didn't really change that
situation.
Sorry, I see now that there was indeed a test for
scr
On 05/08/18 15:45, Michael Paquier wrote:
On Sun, Aug 05, 2018 at 03:30:43PM +0300, Heikki Linnakangas wrote:
That test just tested that the scram_channel_binding libpq option works, but
I removed the option. I know you wanted to keep it as a feature flag, but as
discussed earlier, I don't think
On Sun, Aug 05, 2018 at 03:30:43PM +0300, Heikki Linnakangas wrote:
> That test just tested that the scram_channel_binding libpq option works, but
> I removed the option. I know you wanted to keep it as a feature flag, but as
> discussed earlier, I don't think that'd be useful.
Sorry for the noise
On 05/08/18 15:08, Michael Paquier wrote:
On Sun, Aug 05, 2018 at 02:00:04PM +0300, Heikki Linnakangas wrote:
I did some further testing with this, compiling with and without
HAVE_BE_TLS_GET_CERTIFICATE_HASH and HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH,
and fixed a few combinations that did not work
On Sun, Aug 05, 2018 at 02:00:04PM +0300, Heikki Linnakangas wrote:
> I did some further testing with this, compiling with and without
> HAVE_BE_TLS_GET_CERTIFICATE_HASH and HAVE_PGTLS_GET_PEER_CERTIFICATE_HASH,
> and fixed a few combinations that did not work. And I fixed the other
> comment typos
Thanks for the review!
On 22/07/18 16:54, Michael Paquier wrote:
On Fri, Jul 20, 2018 at 08:05:04PM +0300, Heikki Linnakangas wrote:
This removes the scram_channel_binding libpq option altogether, since there
is now only one supported channel binding type.
This can also be used to switch off
On Fri, Jul 20, 2018 at 08:05:04PM +0300, Heikki Linnakangas wrote:
> In any case, I'm quite convinced now that we should just remove tls-unique,
> and stick to tls-server-end-point. Patch attached, please take a look.
You are making good points here.
> This removes the scram_channel_binding libp
On 12/07/18 16:08, Michael Paquier wrote:
On Thu, Jul 12, 2018 at 12:34:51PM +0300, Heikki Linnakangas wrote:
Hmm. That is actually in a section called "Default Channel Binding". And the
first paragraph says "A default channel binding type agreement process for
all SASL application protocols tha
On Wed, Jul 11, 2018 at 04:00:47PM +0300, Heikki Linnakangas wrote:
> Looking at the GnuTLS docs, I believe it has everything we need.
> gnutls_certificate_get_peers() and gnutls_certificate_get_ours() can be used
> to get the certificate, and gnutls_x509_crt_get_signature_algorithm() gets
> the si
On Thu, Jul 12, 2018 at 12:34:51PM +0300, Heikki Linnakangas wrote:
> Meh. We're not going implement tls-unique, anyway, in some of the upcoming
> non-OpenSSL TLS implementations that don't support it.
True enough. Only GnuTLS supports it:
https://www.gnutls.org/manual/html_node/Channel-Bindings.
On 12/07/18 12:06, Michael Paquier wrote:
On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
It seems that all implementations can support tls-server-end-point, after
all, so I'm not too worried about this anymore. The spec says that it's the
default, but I don't actually see an
On Thu, Jul 12, 2018 at 11:26:30AM +0300, Heikki Linnakangas wrote:
> It seems that all implementations can support tls-server-end-point, after
> all, so I'm not too worried about this anymore. The spec says that it's the
> default, but I don't actually see any advantage to using it over
> tls-serv
On 12/07/18 07:14, Michael Paquier wrote:
On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
I started digging into this more closely, and ran into a little problem. If
channel binding is not used, the client sends a flag to the server to
indicate if it's because the client does
On Wed, Jul 11, 2018 at 03:01:03PM +0300, Heikki Linnakangas wrote:
> That would be more complicated to parse. Yeah, we might need further options
> for some SASL mechanisms in the future, but we can cross that bridge when we
> get there. I don't see any need to complicate this case for that.
Okay
On Wed, Jul 11, 2018 at 04:00:47PM +0300, Heikki Linnakangas wrote:
> In a nutshell, to get the token for tls-server-end-point, you need to get
> the peer's certificate from the TLS library, in raw DER format, and
> calculate a hash over it. The hash algorithm depends on the
> signatureAlgorithm in
On 11/07/18 12:27, Heikki Linnakangas wrote:
Based on recent discussions, it looks like there's going to be
differences in this area [1]. OpenSSL can support both tls-unique and
tls-server-end-point. Java only supports tls-server-end-point, while
GnuTLS only supports tls-unique. And Mac OS Secure
On 11/07/18 14:37, Michael Paquier wrote:
On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
as the supported mechanisms, we change that into:
SCRAM-SHA-256-PLUS tls-unique
SCRAM-SHA-256-PLUS tls-server-end-point
SCRAM-SHA-256
Can we say for sure that there won't be other opt
On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
> as the supported mechanisms, we change that into:
>
> SCRAM-SHA-256-PLUS tls-unique
> SCRAM-SHA-256-PLUS tls-server-end-point
> SCRAM-SHA-256
Can we say for sure that there won't be other options associated to a
given SASL mech
On Wed, Jul 11, 2018 at 12:27:33PM +0300, Heikki Linnakangas wrote:
> Currently, there is no negotiation of the channel binding type between
> client and server. The server advertises that it supports channel binding,
> or not, and the client decides what channel binding to use. If the server
> doe
Currently, there is no negotiation of the channel binding type between
client and server. The server advertises that it supports channel
binding, or not, and the client decides what channel binding to use. If
the server doesn't support the binding type that the client chose,
authentication will
32 matches
Mail list logo
