mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-27 08:39:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

Remove notes from the frontend SSL source that are incorrect or

Browse Source 
end-user documentation that lives in the actual documentation.
This commit is contained in:
Magnus Hagander 2008-10-24 12:29:11 +00:00
parent 81f3e109b7
commit bb8c822dbf
1 changed files with 1 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
src/interfaces/libpq/fe-secure.c
View File

@ -11,64 +11,9 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/interfaces/libpq/fe-secure.c,v 1.105 2008/05/16 18:30:53 mha Exp $
* $PostgreSQL: pgsql/src/interfaces/libpq/fe-secure.c,v 1.106 2008/10/24 12:29:11 mha Exp $
*
* NOTES
* [ Most of these notes are wrong/obsolete, but perhaps not all ]
*
* The client *requires* a valid server certificate. Since
* SSH tunnels provide anonymous confidentiality, the presumption
* is that sites that want endpoint authentication will use the
* direct SSL support, while sites that are comfortable with
* anonymous connections will use SSH tunnels.
*
* This code verifies the server certificate, to detect simple
* "man-in-the-middle" and "impersonation" attacks. The
* server certificate, or better yet the CA certificate used
* to sign the server certificate, should be present in the
* "~/.postgresql/root.crt" file. If this file isn't
* readable, or the server certificate can't be validated,
* pqsecure_open_client() will return an error code.
*
* Additionally, the server certificate's "common name" must
* resolve to the other end of the socket. This makes it
* substantially harder to pull off a "man-in-the-middle" or
* "impersonation" attack even if the server's private key
* has been stolen. This check limits acceptable network
* layers to Unix sockets (weird, but legal), TCPv4 and TCPv6.
*
* Unfortunately neither the current front- or back-end handle
* failure gracefully, resulting in the backend hiccupping.
* This points out problems in each (the frontend shouldn't even
* try to do SSL if pqsecure_initialize() fails, and the backend
* shouldn't crash/recover if an SSH negotiation fails. The
* backend definitely needs to be fixed, to prevent a "denial
* of service" attack, but I don't know enough about how the
* backend works (especially that pre-SSL negotiation) to identify
* a fix.
*
* ...
*
* Unlike the server's static private key, the client's
* static private key (~/.postgresql/postgresql.key)
* should normally be stored encrypted. However we still
* support EPH since it's useful for other reasons.
*
* ...
*
* Client certificates are supported, if the server requests
* or requires them. Client certificates can be used for
* authentication, to prevent sessions from being hijacked,
* or to allow "road warriors" to access the database while
* keeping it closed to everyone else.
*
* The user's certificate and private key are located in
* ~/.postgresql/postgresql.crt
* and
* ~/.postgresql/postgresql.key
* respectively.
*
* ...
*
* We don't provide informational callbacks here (like
* info_cb() in be-secure.c), since there's mechanism to