</listitem>

</varlistentry>

<varlistentry id="libpq-scram-channel-binding" xreflabel="scram_channel_binding">

<term><literal>scram_channel_binding</literal></term>

<listitem>

<para>

Specifies the channel binding type to use with SCRAM

authentication. While <acronym>SCRAM</acronym> alone prevents

the replay of transmitted hashed passwords, channel binding also

prevents man-in-the-middle attacks.

</para>

<para>

The list of channel binding types supported by the server are

listed in <xref linkend="sasl-authentication"/>. An empty value

specifies that the client will not use channel binding. If this

parameter is not specified, <literal>tls-unique</literal> is used,

if supported by both server and client.

Channel binding is only supported on SSL connections. If the

connection is not using SSL, then this setting is ignored.

</para>

<para>

This parameter is mainly intended for protocol testing. In normal

use, there should not be a need to choose a channel binding type other

than the default one.

</para>

</listitem>

</varlistentry>

<varlistentry id="libpq-connect-replication" xreflabel="replication">

<term><literal>replication</literal></term>

<listitem>

<para>

<firstterm>Channel binding</firstterm> is supported in PostgreSQL builds with

SSL support. The SASL mechanism name for SCRAM with channel binding is

<literal>SCRAM-SHA-256-PLUS</literal>. Two channel binding types are

supported: <literal>tls-unique</literal> and

<literal>tls-server-end-point</literal>, both defined in RFC 5929. Clients

should use <literal>tls-unique</literal> if they can support it.

<literal>tls-server-end-point</literal> is intended for third-party clients

that cannot support <literal>tls-unique</literal> for some reason.

<literal>SCRAM-SHA-256-PLUS</literal>. The channel binding type used by

PostgreSQL is <literal>tls-server-end-point</literal>.

</para>

<para>

<para>

<acronym>SCRAM</acronym> with channel binding prevents such

man-in-the-middle attacks by mixing a value into the transmitted

password hash that cannot be retransmitted by a fake server.

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.

man-in-the-middle attacks by mixing the signature of the server's

certificate into the transmitted 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.

</para>

<procedure>

the feature currently does not prevent man-in-the-middle

attacks when using libpq and interfaces built using it. It is

expected that future versions of libpq and interfaces not built

using libpq, e.g. JDBC, will allow this capability. The libpq

options to control the optional channel binding type are <link

linkend="libpq-scram-channel-binding"><option>scram_channel_binding=tls-unique</option></link>

and <option>scram_channel_binding=tls-server-end-point</option>.

using libpq, e.g. JDBC, will allow this capability.

</para>

</listitem>