mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-02-11 19:20:40 +08:00
doc: clarify SCRAM channel binding
Discussion: https://postgr.es/m/20180514231020.GB1600@paquier.xyz Reviewed-by: Michael Paquier
This commit is contained in:
parent
cf9c75ccea
commit
185f4f84d5
@ -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>
|
||||
|
@ -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">
|
||||
|
Loading…
Reference in New Issue
Block a user