1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-21 00:42:43 +03:00
Files
postgres/src/backend/libpq
Nathan Bossart db6a4a985b Deprecate MD5 passwords.
MD5 has been considered to be unsuitable for use as a cryptographic
hash algorithm for some time.  Furthermore, MD5 password hashes in
PostgreSQL are vulnerable to pass-the-hash attacks, i.e., knowing
the username and hashed password is sufficient to authenticate.
The SCRAM-SHA-256 method added in v10 is not subject to these
problems and is considered to be superior to MD5.

This commit marks MD5 password support in PostgreSQL as deprecated
and to be removed in a future release.  The documentation now
contains several deprecation notices, and CREATE ROLE and ALTER
ROLE now emit deprecation warnings when setting MD5 passwords.  The
warnings can be disabled by setting the md5_password_warnings
parameter to "off".

Reviewed-by: Greg Sabino Mullane, Jim Nasby
Discussion: https://postgr.es/m/ZwbfpJJol7lDWajL%40nathan
2024-12-02 13:30:07 -06:00
..
2024-09-02 09:04:30 +02:00
2024-01-03 20:49:05 -05:00
2024-12-02 13:30:07 -06:00
2024-11-28 08:27:20 +01:00
2024-01-03 20:49:05 -05:00
2024-01-03 20:49:05 -05:00
2024-01-03 20:49:05 -05:00
2018-01-23 07:11:38 -05:00

src/backend/libpq/README.SSL

SSL
===

>From the servers perspective:


  Receives StartupPacket
           |
           |
 (Is SSL_NEGOTIATE_CODE?) -----------  Normal startup
           |                  No
           |
           | Yes
           |
           |
 (Server compiled with USE_SSL?) ------- Send 'N'
           |                       No        |
           |                                 |
           | Yes                         Normal startup
           |
           |
        Send 'S'
           |
           |
      Establish SSL
           |
           |
      Normal startup





>From the clients perspective (v6.6 client _with_ SSL):


      Connect
         |
         |
  Send packet with SSL_NEGOTIATE_CODE
         |
         |
  Receive single char  ------- 'S' -------- Establish SSL
         |                                       |
         | '<else>'                              |
         |                                  Normal startup
         |
         |
   Is it 'E' for error  ------------------- Retry connection
         |                  Yes             without SSL
         | No
         |
   Is it 'N' for normal ------------------- Normal startup
         |                  Yes
         |
   Fail with unknown

---------------------------------------------------------------------------

Ephemeral DH
============

Since the server static private key ($DataDir/server.key) will
normally be stored unencrypted so that the database backend can
restart automatically, it is important that we select an algorithm
that continues to provide confidentiality even if the attacker has the
server's private key.  Ephemeral DH (EDH) keys provide this and more
(Perfect Forward Secrecy aka PFS).

N.B., the static private key should still be protected to the largest
extent possible, to minimize the risk of impersonations.

Another benefit of EDH is that it allows the backend and clients to
use DSA keys.  DSA keys can only provide digital signatures, not
encryption, and are often acceptable in jurisdictions where RSA keys
are unacceptable.

The downside to EDH is that it makes it impossible to use ssldump(1)
if there's a problem establishing an SSL session.  In this case you'll
need to temporarily disable EDH (see initialize_dh()).