Re: Some thoughts about SCRAM implementation

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some thoughts about SCRAM implementation
Date: 2017-05-23 01:47:18
Message-ID: CAB7nPqTX+EkDjW=PrTNXTCysdCG1x9m8waQQm9-gk2fxM6V=Wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 10, 2017 at 6:39 PM, Álvaro Hernández Tortosa
<aht(at)8kdata(dot)com> wrote:
> - I think channel binding support should be added. SCRAM brings security
> improvements over md5 and other simpler digest algorithms. But where it
> really shines is together with channel binding. This is the only method to
> prevent MITM attacks. Implementing it should not very difficult. There are
> several possible channel binding mechanisms, but the mandatory and probably
> more typical one is 'tls-unique' which basically means getting the byte
> array from the TLSfinish() message and comparing it with the same data sent
> by the client. That's more or less all it takes to implement it. So I would
> go for it.

I was just looking at that during a long flight, and OpenSSL offers
SSL_get_finished() and SSL_get_peer_finished() to get the Finished
message data. So that's a matter of saving it in the client, encode it
in base64 (the spec is clear about that) and send the data as part of
the first challenge response to the server that just compares both
contents. Of course the protocol list and the first client message
need to be extended as well, but most of the facility is already
there. The spec is also clear about the lines to follow should the
client and/or server be built without OpenSSL (aka no channel binding
support).
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vaishnavi Prabakaran 2017-05-23 02:11:23 Re: Error-like LOG when connecting with SSL for password authentication
Previous Message Alvaro Herrera 2017-05-23 00:55:16 Re: Improve logical decoding error message (was wal_level > WAL_LEVEL_LOGICAL)