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