mirror of
https://github.com/postgres/postgres.git
synced 2026-04-25 16:18:21 -04:00
3a465cc678
The new connection parameter require_auth allows a libpq client to define a list of comma-separated acceptable authentication types for use with the server. There is no negotiation: if the server does not present one of the allowed authentication requests, the connection attempt done by the client fails. The following keywords can be defined in the list: - password, for AUTH_REQ_PASSWORD. - md5, for AUTH_REQ_MD5. - gss, for AUTH_REQ_GSS[_CONT]. - sspi, for AUTH_REQ_SSPI and AUTH_REQ_GSS_CONT. - scram-sha-256, for AUTH_REQ_SASL[_CONT|_FIN]. - creds, for AUTH_REQ_SCM_CREDS (perhaps this should be removed entirely now). - none, to control unauthenticated connections. All the methods that can be defined in the list can be negated, like "!password", in which case the server must NOT use the listed authentication type. The special method "none" allows/disallows the use of unauthenticated connections (but it does not govern transport-level authentication via TLS or GSSAPI). Internally, the patch logic is tied to check_expected_areq(), that was used for channel_binding, ensuring that an incoming request is compatible with conn->require_auth. It also introduces a new flag, conn->client_finished_auth, which is set by various authentication routines when the client side of the handshake is finished. This signals to check_expected_areq() that an AUTH_REQ_OK from the server is expected, and allows the client to complain if the server bypasses authentication entirely, with for example the reception of a too-early AUTH_REQ_OK message. Regression tests are added in authentication TAP tests for all the keywords supported (except "creds", because it is around only for compatibility reasons). A new TAP script has been added for SSPI, as there was no script dedicated to it yet. It relies on SSPI being the default authentication method on Windows, as set by pg_regress. Author: Jacob Champion Reviewed-by: Peter Eisentraut, David G. Johnston, Michael Paquier Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com |
||
|---|---|---|
| .. | ||
| conf | ||
| ssl | ||
| t | ||
| .gitignore | ||
| Makefile | ||
| meson.build | ||
| README | ||
| sslfiles.mk | ||
src/test/ssl/README
SSL regression tests
====================
This directory contains a test suite for SSL support. It tests both
client-side functionality, i.e. verifying server certificates, and
server-side functionality, i.e. certificate authorization.
CAUTION: The test server run by this test is configured to listen for
TCP connections on localhost. Any user on the same host is able to
log in to the test server while the tests are running. Do not run this
suite on a multi-user system where you don't trust all local users!
Running the tests
=================
NOTE: You must have given the --enable-tap-tests argument to configure.
Also, to use "make installcheck", you must have built and installed
contrib/sslinfo in addition to the core code.
Run
make check PG_TEST_EXTRA=ssl
or
make installcheck PG_TEST_EXTRA=ssl
You can use "make installcheck" if you previously did "make install".
In that case, the code in the installation tree is tested. With
"make check", a temporary installation tree is built from the current
sources and then tested.
Either way, this test initializes, starts, and stops a test Postgres
cluster that is accessible to other local users!
See src/test/perl/README for more info about running these tests.
Certificates
============
The test suite needs a set of public/private key pairs and certificates to
run:
root_ca
root CA, use to sign the server and client CA certificates.
server_ca
CA used to sign server certificates.
client_ca
CA used to sign client certificates.
server-cn-only
server-cn-and-alt-names
server-single-alt-name
server-multiple-alt-names
server-no-names
server certificates, with small variations in the hostnames present
in the certificate. Signed by server_ca.
server-password
same as server-cn-only, but password-protected.
client
a client certificate, for user "ssltestuser". Signed by client_ca.
client-revoked
like "client", but marked as revoked in the client CA's CRL.
In addition, there are a few files that combine various certificates together
in the same file:
both-cas-1
Contains root_ca.crt, client_ca.crt and server_ca.crt, in that order.
both-cas-2
Contains root_ca.crt, server_ca.crt and client_ca.crt, in that order.
root+server_ca
Contains root_crt and server_ca.crt. For use as client's "sslrootcert"
option.
root+client_ca
Contains root_crt and client_ca.crt. For use as server's "ssl_ca_file".
client+client_ca
Contains client.crt and client_ca.crt in that order. For use as client's
certificate chain.
There are also CRLs for each of the CAs: root.crl, server.crl and client.crl.
For convenience, all of these keypairs and certificates are included in the
ssl/ subdirectory. The Makefile also contains a rule, "make sslfiles", to
recreate them if you need to make changes. "make sslfiles-clean" is required
in order to recreate the full set of keypairs and certificates. To rebuild
separate files, touch (or remove) the files in question and run "make sslfiles".
This step requires at least OpenSSL 1.1.1.
Note
====
These certificates are also used in other tests, e.g. the LDAP tests.
TODO
====
* Allow the client-side of the tests to be run on different host easily.
Currently, you have to manually set up the certificates for the right
hostname, and modify the test file to skip setting up the server. And you
have to modify the server to accept connections from the client host.
* Test having multiple server certificates, so that the private key chooses
the certificate to present to clients. (And the same in the client-side.)