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 <sfr...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
