8fea86830e
As of this commit, any database or user entry beginning with a slash (/) is considered as a regular expression. This is particularly useful for users, as now there is no clean way to match pattern on multiple HBA lines. For example, a user name mapping with a regular expression needs first to match with a HBA line, and we would skip the follow-up HBA entries if the ident regexp does *not* match with what has matched in the HBA line. pg_hba.conf is able to handle multiple databases and roles with a comma-separated list of these, hence individual regular expressions that include commas need to be double-quoted. At authentication time, user and database names are now checked in the following order: - Arbitrary keywords (like "all", the ones beginning by '+' for membership check), that we know will never have a regexp. A fancy case is for physical WAL senders, we *have* to only match "replication" for the database. - Regular expression matching. - Exact match. The previous logic did the same, but without the regexp step. We have discussed as well the possibility to support regexp pattern matching for host names, but these happen to lead to tricky issues based on what I understand, particularly with host entries that have CIDRs. This commit relies heavily on the refactoring done in |
||
|---|---|---|
| .. | ||
| Makefile | ||
| README.SSL | ||
| auth-sasl.c | ||
| auth-scram.c | ||
| auth.c | ||
| be-fsstubs.c | ||
| be-gssapi-common.c | ||
| be-secure-common.c | ||
| be-secure-gssapi.c | ||
| be-secure-openssl.c | ||
| be-secure.c | ||
| crypt.c | ||
| hba.c | ||
| ifaddr.c | ||
| meson.build | ||
| pg_hba.conf.sample | ||
| pg_ident.conf.sample | ||
| pqcomm.c | ||
| pqformat.c | ||
| pqmq.c | ||
| pqsignal.c | ||
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()).