rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: clarify SCRAM channel binding 

Discussion: https://postgr.es/m/20180514231020.GB1600@paquier.xyz

Reviewed-by: Michael Paquier
This commit is contained in:
Bruce Momjian 2018-05-14 20:45:35 -04:00
parent cf9c75ccea
commit 185f4f84d5
2 changed files with 36 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/src/sgml/libpq.sgml
View File

@ -1242,14 +1242,18 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
<term><literal>scram_channel_binding</literal></term>
<listitem>
<para>
Specifies the channel binding type to use with SCRAM authentication.
The list of channel binding types supported by server are listed in
<xref linkend="sasl-authentication"/>. An empty value specifies that
the client will not use channel binding. The default value is
<literal>tls-unique</literal>.
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>

27
doc/src/sgml/protocol.sgml
View File

@ -1584,6 +1584,33 @@ should use <literal>tls-unique</literal> if they can support it.
that cannot support <literal>tls-unique</literal> for some reason.
</para>
<para>
In <acronym>SCRAM</acronym> without channel binding, the server chooses
a random number that is transmitted to the client to be mixed with the
user-supplied password in the transmitted password hash. While this
prevents the password hash from being successfully retransmitted in
a later session, it does not prevent a fake server between the real
server and client from passing through the server's random value
and successfully authenticating.
</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.
</para>
<procedure>
<title>Example</title>
<step id="scram-begin">