On Wed, May 16, 2018 at 01:22:45PM +0900, Michael Paquier wrote: > On Mon, May 14, 2018 at 08:45:44PM -0400, Bruce Momjian wrote: > > What TLS does is to mix the offered ciphers into the negotiation hash so > > a man-in-the-middle can't pretend it doesn't support something. Could > > we do something like that here? > > I have to admit that I don't quite follow here, the shape of channel > binding data is decided by RFC 5929, so we need to stick with it.
OK, let me explain. First, there are two man-in-the-middle types of attacks. The first one allows the two legitimate ends of the TLS connection to negotiate the shared secret between themselves, but injects or changes some of the packets before the shared secret is agreed upon, perhaps to downgrade the strength of the protocol options. TLS prevents this type of man-in-the-middle attack by hashing the shared secret with a hash of all of the TLS negotiation messages previously sent. Each side who knows the shared secret can verify that no messages were changed; see: https://security.stackexchange.com/questions/115284/how-can-an-attacker-downgrade-modify-the-cipher-suites-when-they-are-maced-fre The second type of man-in-the-middle attack is where the man-in-the-middle is negotiating the shared secret separately with the two end points. There is no way to detect this without having some shared secret between the two valid end points. One shared secret is the password hashed with the shared secret, which is what tls-unique uses. The second uses the server certificate hashed with the shared secret. This is now documented in Postgres: In <acronym>SCRAM</acronym> with <literal>tls-unique</literal> channel binding, the shared secret negotiated during the SSL session is mixed into the user-supplied password hash. The shared secret is partly chosen by the server, but not directly transmitted, making it impossible for a fake server to create an SSL connection with the client that has the same shared secret it has with the real server. <acronym>SCRAM</acronym> with <literal>tls-server-end-point</literal> mixes a hash of the server's certificate into the user-supplied password hash. While a fake server can retransmit the real server's certificate, it doesn't have access to the private key matching that certificate, and therefore cannot prove it is the owner, causing SSL connection failure. TLS prevents a man-in-the-middle from injecting invalid packets. However, it does not prevent a man-in-the-middle attack with separeate shared secret negotiation unless certificates are used. The current problem under discussion is the same as that of the man-in-the-middle packet change/injection attack in that the man-in-the-middle can change the options reported as supported by the Postgres server, before the password is sent. The most efficient fix for this would be for the all Postgres protocol messages up to the point where the authentication was chosen to be hashed with the password and sent to the server. In that way, if a man-in-the-middle changed the server-reported supported authentication, the server would identify this and refuse the connection. The problem is that current and past-version PG authentication methods don't have any protocol downgrade protection, and it is hard to add it unless you just remove support for old protocols. I think the only reasonable solution is to allow the client and/or server to force channel binding. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
