Adding upstream version 14.5.upstream/14.5upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 82 insertions, 0 deletions

diff --git a/src/backend/libpq/README.SSL b/src/backend/libpq/README.SSL
new file mode 100644
index 0000000..d84a434
--- /dev/null
+++ b/src/backend/libpq/README.SSL
@@ -0,0 +1,82 @@
+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()).