postgresql/src/backend/libpq
Peter Eisentraut f14413b684 Sort out getpeereid() and peer auth handling on Windows
The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS,
so they didn't ever care about Windows support.  But in anticipation
of Unix-domain socket support on Windows, that needs to be handled
differently.

Windows doesn't support getpeereid() at this time, so we use the
existing not-supported code path.  We let configure do its usual thing
of picking up the replacement from libpgport, instead of the custom
overrides that it was doing before.

But then Windows doesn't have struct passwd, so this patch sprinkles
some additional #ifdef WIN32 around to make it work.  This is similar
to existing code that deals with this issue.

Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com
2019-12-16 09:36:08 +01:00
..
Makefile Split all OBJS style lines in makefiles into one-line-per-entry style. 2019-11-05 14:41:07 -08:00
README.SSL Move EDH support to common files 2018-01-23 07:11:38 -05:00
auth-scram.c Fix use of term "verifier" 2019-10-12 21:41:59 +02:00
auth.c Sort out getpeereid() and peer auth handling on Windows 2019-12-16 09:36:08 +01:00
be-fsstubs.c PG_FINALLY 2019-11-01 11:18:03 +01:00
be-gssapi-common.c Move be-gssapi-common.h into src/include/libpq/ 2019-06-08 09:59:02 +09:00
be-secure-common.c Use explicit_bzero 2019-09-05 08:30:42 +02:00
be-secure-gssapi.c GSSAPI error message improvements 2019-09-19 15:09:49 +02:00
be-secure-openssl.c Fix memory leak when initializing DH parameters in backend 2019-12-14 18:17:31 +09:00
be-secure.c Make the order of the header file includes consistent in backend modules. 2019-11-12 08:30:16 +05:30
crypt.c Fix use of term "verifier" 2019-10-12 21:41:59 +02:00
hba.c Remove useless "return;" lines 2019-11-28 16:48:37 -03:00
ifaddr.c Phase 2 pgindent run for v12. 2019-05-22 13:04:48 -04:00
pg_hba.conf.sample Rename "scram" to "scram-sha-256" in pg_hba.conf and password_encryption. 2017-04-18 14:50:50 +03:00
pg_ident.conf.sample Reformat the comments in pg_hba.conf and pg_ident.conf 2010-01-26 06:58:39 +00:00
pqcomm.c Fix inconsistencies and typos in the tree, take 10 2019-08-13 13:53:41 +09:00
pqformat.c Fix more typos and inconsistencies in the tree 2019-06-17 16:13:16 +09:00
pqmq.c Update copyright for 2019 2019-01-02 12:44:25 -05:00
pqsignal.c In the postmaster, rely on the signal infrastructure to block signals. 2019-10-13 15:48:26 -04:00

README.SSL

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()).