Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Sep 26, 2017 at 11:09 AM, Michael Paquier wrote: > On Mon, Sep 25, 2017 at 11:22 PM, Peter Eisentraut > wrote: >> I think the channel-binding negotiation on the client side is wrong. >> The logic in the patch is >> >> +#ifdef

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Oct 3, 2017 at 1:30 AM, Robert Haas wrote: > On Fri, Sep 15, 2017 at 6:29 PM, Michael Paquier > wrote: >> I would like to point out that per the RFC, if the client attempts a >> SSL connection with SCRAM and that the server supports

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Fri, Sep 15, 2017 at 6:29 PM, Michael Paquier wrote: > I would like to point out that per the RFC, if the client attempts a > SSL connection with SCRAM and that the server supports channel > binding, then it has to publish the SASL mechanism for channel > binding,

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Mon, Sep 25, 2017 at 11:22 PM, Peter Eisentraut wrote: > Here is a review of the meat of the code, leaving aside the discussion > of the libpq connection parameters. > > Overall, the structure of the code makes sense and it fits in well with > the existing

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 9/10/17 22:37, Michael Paquier wrote: >>> With the tests directly in the patch, things are easy to run. WIth >>> PG10 stabilization work, of course I don't expect much feedback :) >>> But this set of patches looks like the direction we want to go so as >>> JDBC and libpq users can take

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Sat, Sep 16, 2017 at 12:42 AM, Robert Haas wrote: > On Thu, Sep 14, 2017 at 12:58 PM, Peter Eisentraut > wrote: >> Second thoughts, to make things simpler. All we need for channel >> binding is a connection flag that says "I require

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Thu, Sep 14, 2017 at 12:58 PM, Peter Eisentraut wrote: > Second thoughts, to make things simpler. All we need for channel > binding is a connection flag that says "I require channel binding". It > could be modeled after the sslmode parameter, e.g.,

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Fri, Sep 15, 2017 at 1:58 AM, Peter Eisentraut wrote: > Second thoughts, to make things simpler. All we need for channel > binding is a connection flag that says "I require channel binding". It > could be modeled after the sslmode parameter, e.g.,

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 9/12/17 19:03, Michael Paquier wrote: > Once channel binding is involved though.. This needs to be extended > and this needs careful thoughts: > * "scram-sha-256" means that the version without channel binding is > accepted. "!scram-sha-256" means that scram without channel binding is >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Sep 12, 2017 at 11:38 PM, Peter Eisentraut wrote: > It seems we should start by sorting out the mechanism by which the > client can control what authentication mechanisms it accepts. In your > patch set you introduce a connection parameter saslname. I

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 9/10/17 22:37, Michael Paquier wrote: > On Mon, Aug 21, 2017 at 9:51 PM, Michael Paquier > wrote: >> On Tue, Jun 20, 2017 at 1:11 PM, Michael Paquier >> wrote: >>> With the tests directly in the patch, things are easy to run. WIth >>> PG10

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Mon, Aug 21, 2017 at 9:51 PM, Michael Paquier wrote: > On Tue, Jun 20, 2017 at 1:11 PM, Michael Paquier > wrote: >> With the tests directly in the patch, things are easy to run. WIth >> PG10 stabilization work, of course I don't expect

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Jun 20, 2017 at 1:11 PM, Michael Paquier wrote: > With the tests directly in the patch, things are easy to run. WIth > PG10 stabilization work, of course I don't expect much feedback :) > But this set of patches looks like the direction we want to go so as >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Wed, Jun 21, 2017 at 4:04 AM, Álvaro Hernández Tortosa wrote: > In the coming weeks, and once my PR for pgjdbc has been added, I will > work towards another patch to implement channel binding. Should be > reasonably easy now, thanks to this. So you basically have an

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 20/06/17 06:11, Michael Paquier wrote: On Tue, Jun 6, 2017 at 3:40 PM, Michael Paquier wrote: As far as I can see, there are a couple of things that I still need to work on to make people happy: - Rework the generic APIs for TLS finish and endpoint so as any

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Jun 6, 2017 at 3:40 PM, Michael Paquier wrote: > As far as I can see, there are a couple of things that I still need to > work on to make people happy: > - Rework the generic APIs for TLS finish and endpoint so as any > implementation can use channel binding

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert Haas writes: > I don't think it's true that we force the latest TLS version to be > used. The comment says: > /* > * We use SSLv23_method() because it can negotiate use of the highest > * mutually supported protocol version, while

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Jun 6, 2017 at 2:32 AM, Michael Paquier wrote: >>> At the end, >>> everything has been rejected as Postgres enforces the use of the >>> newest one when doing the SSL handshake. >> >> TLS implementations, or TLS versions? What does the TLS version have >> to do

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Jun 2, 2017 at 10:25 AM, Robert Haas wrote: > > On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier > > wrote: > >> It seems to me that any testing in this area won't fly high

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost wrote: > I don't have any issue with asking that Michael, or someone, to go look > at other OpenSSL-using implementations which support channel binding. I don't see the implementation of other TLS/SSL as a requirement for channel

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Fri, Jun 2, 2017 at 10:25 AM, Robert Haas wrote: > On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier > wrote: >> It seems to me that any testing in this area won't fly high as long as >> there is no way to enforce the list of TLS implementations

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Thu, Jun 1, 2017 at 9:13 PM, Michael Paquier wrote: > On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost wrote: >> What I find somewhat objectionable is the notion that if we don't have 5 >> different TLS/SSL implementations supported in PG and that

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Fri, Jun 2, 2017 at 10:08 AM, Stephen Frost wrote: > What I find somewhat objectionable is the notion that if we don't have 5 > different TLS/SSL implementations supported in PG and that we've tested > that channel binding works correctly among all combinations of all of >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Jun 1, 2017 at 11:50 AM, Stephen Frost wrote: > > I certainly wouldn't object to someone working on this, but I feel like > > it's a good deal more work than perhaps you're realizing (and I tend to > > think

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 01/06/17 17:50, Stephen Frost wrote: Robert, * Robert Haas (robertmh...@gmail.com) wrote: On Wed, May 31, 2017 at 7:59 PM, Stephen Frost wrote: If your comments regarding the requirement that we have interoperability testing of this feature before accepting it were

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 01/06/17 18:11, Bruce Momjian wrote: On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote: On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote: ... and I don't believe that we should be asking the implementors of channel binding to also implement support for

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Thu, Jun 1, 2017 at 11:50 AM, Stephen Frost wrote: > I certainly wouldn't object to someone working on this, but I feel like > it's a good deal more work than perhaps you're realizing (and I tend to > think trying to use the Windows SSL implementation would increase the >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Wed, May 31, 2017 at 09:37:02AM -0400, Robert Haas wrote: > On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote: > > ... and I don't believe that we should be asking the > > implementors of channel binding to also implement support for multiple > > TLS libraries in

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, May 31, 2017 at 7:59 PM, Stephen Frost wrote: > > If your comments regarding the requirement that we have interoperability > > testing of this feature before accepting it were intended to mean that > > we need to

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Wed, May 31, 2017 at 7:59 PM, Stephen Frost wrote: > If your comments regarding the requirement that we have interoperability > testing of this feature before accepting it were intended to mean that > we need to make sure that the JDBC driver is able to work with the >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote: > > ... and I don't believe that we should be asking the > > implementors of channel binding to also implement support for multiple > > TLS libraries in PostgreSQL in

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, May 30, 2017 at 6:50 PM, Álvaro Hernández Tortosa wrote: > Actually this Python patch seems to ultimately rely on the same OpenSSL > functions as your implementation. Yup. My point is that even if those APIs are undocumented, I think that they are not going to

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote: > ... and I don't believe that we should be asking the > implementors of channel binding to also implement support for multiple > TLS libraries in PostgreSQL in order to test that their RFC-following > (at least, as far as

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > but without actual interoperability testing it sounds pretty > speculative to me. I'm all for interoperability testing. When we have multiple implementations of TLS using different libraries with various versions of PostgreSQL and libpq and

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On 31/05/17 03:39, Michael Paquier wrote: On Tue, May 30, 2017 at 5:59 PM, Robert Haas wrote: That sounds like undue optimism to me. Unless somebody's tested that Michael's proposed implementation, which uses undocumented OpenSSL APIs, actually interoperates properly

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, May 30, 2017 at 5:59 PM, Robert Haas wrote: > That sounds like undue optimism to me. Unless somebody's tested that > Michael's proposed implementation, which uses undocumented OpenSSL > APIs, actually interoperates properly with a SCRAM + channel binding >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, May 30, 2017 at 1:00 PM, Stephen Frost wrote: > All-in-all, this sounds like it's heading in the right direction, at > least at a high level. Glad to see that there's been consideration of > other TLS implementations, and as such I don't think we need to be > overly

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

> On 30 May 2017, at 16:50, Tom Lane wrote: > > Robert Haas writes: >> On Sat, May 27, 2017 at 5:59 PM, Álvaro Hernández Tortosa >> wrote: >>> - tls-unique, as you mentioned, uses two undocumented APIs. This raises a >>> small flag

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

> On 30 May 2017, at 18:25, Michael Paquier wrote: > > On macos though it is another story, I am not seeing anything: > https://developer.apple.com/reference/security/secure_transport#symbols The Secure Transport documentation unfortunately excel at being incomplete

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, May 30, 2017 at 8:14 AM, Stephen Frost wrote: > > The specific APIs are, certainly, going to be different between > > different TLS implementations and I don't believe we need to be > > particularly

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, May 30, 2017 at 8:14 AM, Stephen Frost wrote: > Work has been done in that area already, as well as for LibNSS support. > > I've not had a chance to closely look over the proposed approach here, > but generally speaking, we need to be looking for a standard way to >

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > On Sat, May 27, 2017 at 5:59 PM, Álvaro Hernández Tortosa > > wrote: > >> - tls-unique, as you mentioned, uses two undocumented APIs. This raises a > >> small flag about the

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

Robert Haas writes: > On Sat, May 27, 2017 at 5:59 PM, Álvaro Hernández Tortosa > wrote: >> - tls-unique, as you mentioned, uses two undocumented APIs. This raises a >> small flag about the stability and future of those APIs. > It seems to me that the

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Sat, May 27, 2017 at 5:59 PM, Álvaro Hernández Tortosa wrote: > On 25/05/17 17:17, Michael Paquier wrote: >> Please find attached a patch to add support for channel binding for >> SCRAM, to mitigate MITM attacks using this protocol. Per RFC5802 >>