mirror of
https://github.com/postgres/postgres.git
synced 2025-09-02 04:21:28 +03:00
11a0a4db3c
libpq failed to ignore Windows-style newlines in connection service files. This normally wasn't a problem on Windows itself, because fgets() would convert \r\n to just \n. But if libpq were running inside a program that changes the default fopen mode to binary, it would see the \r's and think they were data. In any case, it's project policy to ignore \r in text files unconditionally, because people sometimes try to use files with DOS-style newlines on Unix machines, where the C library won't hide that from us. Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of the line. In HEAD, go a little further and make it ignore all trailing whitespace, to match what it's always done with leading whitespace. In HEAD, also run around and fix up everyplace where we have newline-chomping code to make all those places look consistent and uniformly drop \r. It is not clear whether any of those changes are fixing live bugs. Most of the non-cosmetic changes are in places that are reading popen output, and the jury is still out as to whether popen on Windows can return \r\n. (The Windows-specific code in pipe_read_line seems to think so, but our lack of support for this elsewhere suggests maybe it's not a problem in practice.) Hence, I desisted from applying those changes to back branches, except in run_ssl_passphrase_command() which is new enough and little-tested enough that we'd probably not have heard about any problems there. Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha. Back-patch the parseServiceFile() change to all supported branches, and the run_ssl_passphrase_command() change to v11 where that was added. Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org
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()).