Horton

Re: SCRAM with channel binding downgrade attack

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Bruce Momjian <bruce@momjian.us>
Cc: Magnus Hagander <magnus@hagander.net>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Stephen Frost <sfrost@snowman.net>
Date: 2018-05-18T01:46:46Z
Lists: pgsql-hackers 
On Thu, May 17, 2018 at 10:05:25AM -0400, Bruce Momjian wrote:
> Agreed.  The problem was so glaring that I assumed I was not
> understanding it.  I have modified this email subject so users will
> hopefully read back in this thread to see the details.

Okay, let's use this new thread then for the follow-up discussion.  For
people wondering, this basically refers to the following message from
Bruce and Heikki:
https://www.postgresql.org/message-id/d01b31f5-0b3e-b69a-1504-a79649d81f46@iki.fi

There are actually two problems which have been touched in this
discussion:
1) A client using libpq may be forced by a rogue server to not use
channel binding even if it is willing to do so.  For example, a v11
libpq with a v10 server enters in this category.  An idea here would be
to provide an extra connection parameter which allows the client to
reject an access to a server if channel binding is not supported.  One
idea is something I mentioned here:
https://www.postgresql.org/message-id/20180516115923.GB14835%40paquier.xyz
So we could have channel_binding_mode, which has a 'prefer' mode, which
is the actual default we have in the tree, as well as a 'require' mode,
which allows the client to fail connection if a server does not publish
the SCRAM-PLUS mechanism after the initial authentication message
exchange.
2) Allow clients to connect to servers only if they use channel
binding.  This goes with a server-side hba configuration, like
scram-sha-256-plus to not allow access to clients in a SCRAM
authentication if they don't have channel binding support.

From a security point of view, 1) is important for libpq, but I am not
much enthusiast about 2) as a whole.  The backend has proper support for
channel binding, hence other drivers speaking the protocol could have
their own restriction mechanisms.

I actually touched a bit what's being discussed here as part of the
channel binding thread:
https://www.postgresql.org/message-id/CAB7nPqTRW9qbPSYpWtKJD9A%2BQBd6dS0ePkgrrjbkkG0C10zsBA%40mail.gmail.com
However per what I read this does not cover the need to allow the client
to allow that channel binding *has* to be used depending on its
requirements.

I'd like to mention as well that I touched the topic during the
unconference of PGConf Asia last December:
https://wiki.postgresql.org/wiki/PGConf.ASIA2017_Developer_Unconference#SCRAM_improvements

Any ideas raised there did not get much enthusiam from the
participants.  Magnus and Bruce have participated in the conference,
perhaps you were not at my unconf session..
--
Michael

Commits

  1. doc: update PG 11 release notes

  2. Fix misspelled pg_trgm contrib name in PostgreSQL 11 release notes

  3. Doc: clarify release note text about v11's new window function features.

  4. Improve wording of release notes item

  5. Fix typos in release notes

  6. Doc: preliminary list of PG11 major features.

  7. Make numeric power() handle NaNs according to the modern POSIX spec.

  8. Various improvements of skipping index scan during vacuum technics

  9. Revert back-branch changes in power()'s behavior for NaN inputs.

  10. Avoid wrong results for power() with NaN input on more platforms.

  11. Avoid wrong results for power() with NaN input on some platforms.

  12. Skip full index scan during cleanup of B-tree indexes when possible

  13. Rewrite the code that applies scan/join targets to paths.

  14. Postpone generate_gather_paths for topmost scan/join rel.

  15. Add casts from jsonb

  16. Make plpgsql use its DTYPE_REC code paths for composite-type variables.

  17. Don't allow VACUUM VERBOSE ANALYZE VERBOSE.

  18. Pass InitPlan values to workers via Gather (Merge).

  19. Account for the effect of lossy pages when costing bitmap scans.

  20. Allow no-op GiST support functions to be omitted.

  21. Rearm statement_timeout after each executed query.

  22. Push limit through subqueries to underlying sort, where possible.