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
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
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
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,
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
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
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
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
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
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
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
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
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 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
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
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:
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
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
>
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
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.
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
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
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
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
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
>
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
28 matches
Mail list logo
