Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 |
Дата | |
Msg-id | 76303036-b0cb-dbda-077f-3e759e6fe920@8kdata.com обсуждение исходный текст |
Ответ на | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-jdbc |
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 <sfrost@snowman.net> 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 they can tell) implementation actually works. >> You're of course free to believe what you wish, but that sounds >> short-sighted to me. If we implement channel binding and it turns out >> not to be interoperable with other SSL implementations, then what? We >> can't change it later without breaking compatibility with our own >> prior implementation. Note that Álvaro Hernández Tortosa said about >> two hours before you sent this email that it doesn't seem possible to >> implement something comparable in Java's standard SSL stack. If >> that's the case, adopting this implementation is dooming everyone who >> connects to the database server using JDBC to be unable to use channel >> binding. And that's a large percentage of our user base. > Just to step back, exactly how does channel binding work? Is each side > of the SSL connection hashing the password hash with the shared SSL > session secret in some way that each side knows the other end knows > the password hash, but not disclosing the secret or password hash? Is > there some other way JDBC can get that information? > In short, channel binding augments SCRAM (could be also other authentication methods, I guess) by adding to the mix of data to be exchanged, data that comes off-band. Normal SCRAM exchange involves user, a unique token, a salt and some other information. If you add into the mix off-band information, that is uniquely known by only client and server, you can avoid MITM attacks. It's not as simple as "hashing" the password, though. SCRAM involves 4 steps (2 messages each way) with somehow complex hashing of data in the last 2 steps. There are basically 2 channel binding options, that is, 2 possible data pieces that could be taken off-band of the SCRAM authentication and throw them into this mix: - tls-unique. It's like a unique identifier for each client-server SSL connection. It should be get from the SSL channel and there doesn't seem to be a super consistent way of getting it from the channel (in OpenSSL is an undocumented API, it's not available in normal Java stack, etc). - tls-server-end-point. Channel binding data is just a hash of a SSL certificate, as is. As such, seems to be easier to be supported across multiple OSs/SSL stacks. However, SCRAM RFC states that if channel binding is implemented, at least tls-unique must be implemented, with others being optional (there is as of today a third one, but only applies to telnet). So in my opinion, I'd implement both of the above, for maximum flexibility, and add a field to the required scram authentication febe message with a list (aka CSV) of the channel binding mechanisms supported by this server. In this way, I believe covers support for several channel binding mechanisms and could be extended in the future should other mechanisms appear. Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Robert HaasДата:
Сообщение: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Следующее
От: Álvaro Hernández TortosaДата:
Сообщение: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256