e6bdfd9700
Similarly to the cryptohash implementations, this refactors the existing
HMAC code into a single set of APIs that can be plugged with any crypto
libraries PostgreSQL is built with (only OpenSSL currently). If there
is no such libraries, a fallback implementation is available. Those new
APIs are designed similarly to the existing cryptohash layer, so there
is no real new design here, with the same logic around buffer bound
checks and memory handling.
HMAC has a dependency on cryptohashes, so all the cryptohash types
supported by cryptohash{_openssl}.c can be used with HMAC. This
refactoring is an advantage mainly for SCRAM, that included its own
implementation of HMAC with SHA256 without relying on the existing
crypto libraries even if PostgreSQL was built with their support.
This code has been tested on Windows and Linux, with and without
OpenSSL, across all the versions supported on HEAD from 1.1.1 down to
1.0.1. I have also checked that the implementations are working fine
using some sample results, a custom extension of my own, and doing
cross-checks across different major versions with SCRAM with the client
and the backend.
Author: Michael Paquier
Reviewed-by: Bruce Momjian
Discussion: https://postgr.es/m/X9m0nkEJEzIPXjeZ@paquier.xyz
|
||
|---|---|---|
| .. | ||
| Makefile | ||
| README.SSL | ||
| 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 | ||
| 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()).