mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-27 08:39:28 +08:00
Remove large parts of the old SSL readme, that consisted of a couple
of copy/paste:d emails. Much of the contents had already been migrated into the main documentation, some was out of date and some just plain wrong. Keep the "protocol-flowchart" which can still be useful.
This commit is contained in:
Magnus Hagander
parent
501e58ba4e
commit
f5020684db
@ -1,4 +1,4 @@
|
||||
$PostgreSQL: pgsql/src/backend/libpq/README.SSL,v 1.6 2008/03/21 13:23:28 momjian Exp $
|
||||
$PostgreSQL: pgsql/src/backend/libpq/README.SSL,v 1.7 2008/10/24 11:48:29 mha Exp $
|
||||
|
||||
SSL
|
||||
===
|
||||
@ -58,431 +58,3 @@ SSL
|
||||
Fail with unknown
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
|
||||
COMMENTS FROM BEAR GILES
|
||||
|
||||
On a related note, I had mentioned this before but it's a subtle point
|
||||
and I'm sure that it's slipped everyone's mind...
|
||||
|
||||
- if you need to have confidence in the identity of the database
|
||||
server, e.g., you're storing sensitive information and you absolutely
|
||||
must prevent any "man in the middle" attacks, use the SSL code I
|
||||
provided with server-side certs. To many users, the key issue is not
|
||||
whether the data is encrypted, it's whether the other party can be
|
||||
trusted to be who they claim to be.
|
||||
|
||||
- if you just need confidentiality, but you don't need to verify the
|
||||
identity of the database server (e.g., because you trust the IP address,
|
||||
but worry about packet sniffers), SSH tunnels are much easier to set up
|
||||
and maintain than the embedded SSL code. You can set up the database
|
||||
server so it doesn't require a certificate (hell, you can hard code a
|
||||
fallback certificate into the server!), *but that violates the common
|
||||
practice of SSL-enabled servers.* I cannot overemphasize this - every
|
||||
other SSL-enabled server requires a certificate, and most provide
|
||||
installation scripts to create a "snake oil" temporary certificate. I
|
||||
can't think of any server (apache+mod_ssl, courier-imap, postfix(+tls),
|
||||
etc.) that uses anonymous servers.
|
||||
|
||||
- if you don't need confidentiality, e.g., you're on a trusted network
|
||||
segment, then use direct access to the server port.
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
EMAIL ABOUT DOCUMENTATION
|
||||
|
||||
From: Bear Giles <bgiles@coyotesong.com>
|
||||
Subject: [HACKERS] 2nd cut at SSL documentation
|
||||
To: pgsql-hackers@postgresql.org
|
||||
Date: Tue, 21 May 2002 14:27:00 -0600 (MDT)
|
||||
|
||||
A second cut at SSL documentation....
|
||||
|
||||
|
||||
|
||||
SSL Support in PostgreSQL
|
||||
=========================
|
||||
|
||||
Who needs it?
|
||||
=============
|
||||
|
||||
The sites that require SSL fall into one (or more) of several broad
|
||||
categories.
|
||||
|
||||
*) They have insecure networks.
|
||||
|
||||
Examples of insecure networks are anyone in a "corporate hotel,"
|
||||
any network with 802.11b wireless access points (WAP) (in 2002,
|
||||
this protocol has many well-known security weaknesses and even
|
||||
'gold' connections can be broken within 8 hours), or anyone
|
||||
accessing their database over the internet.
|
||||
|
||||
These sites need a Virtual Private Network (VPN), and either
|
||||
SSH tunnels or direct SSL connections can be used.
|
||||
|
||||
*) They are storing extremely sensitive information.
|
||||
|
||||
An example of extremely sensitive information is logs from
|
||||
network intrusion detection systems. This information *must*
|
||||
be fully encrypted between front- and back-end since an attacker
|
||||
is presumably sniffing all traffic within the VPN, and if they
|
||||
learn that you know what they are doing they may attempt to
|
||||
cover their tracks with a quick 'rm -rf /' and 'dropdb'
|
||||
|
||||
In the extreme case, the contents of the database itself may
|
||||
be encrypted with either the crypt package (which provides
|
||||
symmetrical encryption of the records) or the PKIX package
|
||||
(which provides public-key encryption of the records).
|
||||
|
||||
*) They are storing information which is considered confidential
|
||||
by custom, law or regulation.
|
||||
|
||||
This includes all records held by your doctor, lawyer, accountant,
|
||||
etc. In these cases, the motivation for using encryption is not
|
||||
a conscious evaulation of risk, but the fear of liability for
|
||||
'failure to perform due diligence' if encryption is available but
|
||||
unused and an attacker gains unauthorized access to the harm of
|
||||
others.
|
||||
|
||||
*) They have 'road warriors.'
|
||||
|
||||
This includes all sites where people need to have direct access
|
||||
to the database (not through a proxy such as a secure web page)
|
||||
from changing remote addresses. Client certificates provide a
|
||||
clean way to grant this access without opening up the database
|
||||
to the world.
|
||||
|
||||
Who does not need it?
|
||||
---------------------
|
||||
|
||||
It's at least as important to know who does not need SSL as it
|
||||
is to know who does. Sites that do not need SSL fall into several
|
||||
broad categories.
|
||||
|
||||
*) Access is limited to the Unix socket.
|
||||
|
||||
*) Access is limited to a physically secure network.
|
||||
|
||||
"Physically secure" networks are common in the clusters and
|
||||
colocation sites - all database traffic is restricted to dedicated
|
||||
NIC cards and hubs, and all servers and cabling are maintained in
|
||||
locked cabinets.
|
||||
|
||||
|
||||
Using SSH/OpenSSH as a Virtual Private Network (VPN)
|
||||
====================================================
|
||||
|
||||
SSH and OpenSSH can be used to construct a Virtual Private Network
|
||||
(VPN) to provide confidentiality of PostgreSQL communications.
|
||||
These tunnels are widely available and fairly well understood, but
|
||||
do not provide any application-level authentication information.
|
||||
|
||||
To set up a SSH/OpenSSH tunnel, a shell account for each
|
||||
user should be set up on the database server. It is acceptable
|
||||
for the shell program to be bogus (e.g., /bin/false), if the
|
||||
tunnel is set up in to avoid launching a remote shell.
|
||||
|
||||
On each client system the ~/.ssh/config file should contain
|
||||
an additional line similiar to
|
||||
|
||||
LocalForward 5555 psql.example.com:5432
|
||||
|
||||
(replacing psql.example.com with the name of your database server).
|
||||
By putting this line in the configuration file, instead of specifying
|
||||
it on the command line, the tunnel will be created whenever a
|
||||
connection is made to the remote system.
|
||||
|
||||
The psql(1) client (or any client) should be wrapped with a script
|
||||
that establishes an SSH tunnel when the program is launched:
|
||||
|
||||
#!/bin/sh
|
||||
HOST=psql.example.com
|
||||
IDENTITY=~/.ssh/identity.psql
|
||||
/usr/bin/ssh -1 -i $IDENTITY -n $HOST 'sleep 60' & \
|
||||
/usr/bin/psql -h $HOST -p 5555 $1
|
||||
|
||||
Alternatively, the system could run a daemon that establishes and maintains
|
||||
the tunnel. This is preferrable when multiple users need to establish
|
||||
similar tunnels to the same remote site.
|
||||
|
||||
Unfortunately, there are many potential drawbacks to SSL tunnels:
|
||||
|
||||
*) the SSH implementation or protocol may be flawed. Serious problems
|
||||
are discovered about once every 18- to 24- months.
|
||||
|
||||
*) the systems may be misconfigured by accident.
|
||||
|
||||
*) the database server must provide shell accounts for all users
|
||||
needing access. This can be a chore to maintain, esp. in if
|
||||
all other user access should be denied.
|
||||
|
||||
*) neither the front- or back-end can determine the level of
|
||||
encryption provided by the SSH tunnel - or even whether an
|
||||
SSH tunnel is in use. This prevents security-aware clients
|
||||
from refusing any connection with unacceptly weak encryption.
|
||||
|
||||
*) neither the front- or back-end can get any authentication
|
||||
information pertaining to the SSH tunnel.
|
||||
|
||||
Bottom line: if you just need a VPN, SSH tunnels are a good solution.
|
||||
But if you explicitly need a secure connection they're inadequate.
|
||||
|
||||
|
||||
Direct SSL Support
|
||||
==================
|
||||
|
||||
Insecure Channel: ANONYMOUS DH Server
|
||||
-------------------------------------
|
||||
|
||||
"ANONYMOUS DH" is the most basic SSL implementation. It does
|
||||
not require a server certificate, but it is vulnerable to
|
||||
"man-in-the-middle" attacks.
|
||||
|
||||
The PostgreSQL backend does not support ANONYMOUS DH sessions.
|
||||
|
||||
|
||||
Secure Channel: Server Authentication
|
||||
-------------------------------------
|
||||
|
||||
Server Authentication requires that the server authenticate itself
|
||||
to clients (via certificates), but clients can remain anonymous.
|
||||
This protects clients from "man-in-the-middle" attacks (where a
|
||||
bogus server either captures all data or provides bogus data),
|
||||
but does not protect the server from bad data injected by false
|
||||
clients.
|
||||
|
||||
The community has established a set of criteria for secure
|
||||
communications:
|
||||
|
||||
*) the server must provide a certificate identifying itself
|
||||
via its own fully qualified domain name (FDQN) in the
|
||||
certificate's Common Name (CN) field.
|
||||
|
||||
*) the FQDN in the server certificate must resolve to the
|
||||
IP address used in the connection.
|
||||
|
||||
*) the certificate must be valid. (The current date must be
|
||||
no earlier than the 'notBefore' date, and no later than the
|
||||
'notAfter' date.)
|
||||
|
||||
*) the server certificate must be signed by an issuer certificate
|
||||
known to the clients.
|
||||
|
||||
This issuer can be a known public CA (e.g., Verisign), a locally
|
||||
generated root cert installed with the database client, or the
|
||||
self-signed server cert installed with the database client.
|
||||
|
||||
Another approach (used by SSH and most web clients) is for the
|
||||
client to prompt the user whether to accept a new root cert when
|
||||
it is encountered for the first time. psql(1) does not currently
|
||||
support this mechanism.
|
||||
|
||||
*) the client *should* check the issuer's Certificate Revocation
|
||||
List (CRL) to verify that the server's certificate hasn't been
|
||||
revoked for some reason, but in practice this step is often
|
||||
skipped.
|
||||
|
||||
*) the server private key must be owned by the database process
|
||||
and not world-accessible. It is recommended that the server
|
||||
key be encrypted, but it is not required if necessary for the
|
||||
operation of the system. (Primarily to allow automatic restarts
|
||||
after the system is rebooted.)
|
||||
|
||||
The 'mkcert.sh' script can be used to generate and install
|
||||
suitable certificates
|
||||
|
||||
Finally, the client library can have one or more trusted root
|
||||
certificates compiled into it. This allows clients to verify
|
||||
certificates without the need for local copies. To do this,
|
||||
the source file src/interfaces/libpq/fe-ssl.c must be edited
|
||||
and the database recompiled.
|
||||
|
||||
Secure Channel: Mutual Authentication
|
||||
-------------------------------------
|
||||
|
||||
Mutual authentication requires that servers and clients each
|
||||
authenticate to the other. This protects the server from
|
||||
false clients in addition to protecting the clients from false
|
||||
servers.
|
||||
|
||||
The community has established a set of criteria for client
|
||||
authentication similar to the list above.
|
||||
|
||||
*) the client must provide a certificate identifying itself.
|
||||
The certificate's Common Name (CN) field should contain the
|
||||
client's usual name.
|
||||
|
||||
*) the client certificate must be signed by a certificate known
|
||||
to the server.
|
||||
|
||||
If a local root cert was used to sign the server's cert, the
|
||||
client certs can be signed by the issuer.
|
||||
|
||||
*) the certificate must be valid. (The current date must be
|
||||
no earlier than the 'notBefore' date, and no later than the
|
||||
'notAfter' date.)
|
||||
|
||||
*) the server *should* check the issuer's Certificate Revocation
|
||||
List (CRL) to verify that the clients's certificate hasn't been
|
||||
revoked for some reason, but in practice this step is often
|
||||
skipped.
|
||||
|
||||
*) the client's private key must be owned by the client process
|
||||
and not world-accessible. It is recommended that the client
|
||||
key be encrypted, but because of technical reasons in the
|
||||
architecture of the client library this is not yet supported.
|
||||
|
||||
PostgreSQL can generate client certificates via a four-step process.
|
||||
|
||||
1. The "client.conf" file must be copied from the server. Certificates
|
||||
can be highly localizable, and this file contains information that
|
||||
will be needed later.
|
||||
|
||||
The client.conf file is normally installed in /etc/postgresql/root.crt.
|
||||
The client should also copy the server's root.crt file to
|
||||
~/.postgresql/root.crt.
|
||||
|
||||
2. If the user has the OpenSSL applications installed, they can
|
||||
run pgkeygen.sh. (An equivalent compiled program will be available
|
||||
in the future.) They should provide a copy of the
|
||||
~/.postgresql/postgresql.pem file to their DBA.
|
||||
|
||||
3. The DBA should sign this file the OpenSSL applications:
|
||||
|
||||
$ openssl ca -config root.conf -ss_cert ....
|
||||
|
||||
and return the signed cert (postgresql.crt) to the user.
|
||||
|
||||
4. The user should install this file in ~/.postgresql/postgresql.crt.
|
||||
|
||||
The server will log every time a client certificate has been
|
||||
used, but there is not yet a mechanism provided for using client
|
||||
certificates as PostgreSQL authentication at the application level.
|
||||
|
||||
|
||||
---------------------------(end of broadcast)---------------------------
|
||||
TIP 5: Have you checked our extensive FAQ?
|
||||
|
||||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
|
||||
Date: Tue, 21 May 2002 19:50:38 -0400
|
||||
From: Neil Conway <nconway@klamath.dyndns.org>
|
||||
To: "Bear Giles" <bgiles@coyotesong.com>
|
||||
cc: pgsql-hackers@postgresql.org
|
||||
Subject: Re: [HACKERS] 2nd cut at SSL documentation
|
||||
|
||||
On Tue, 21 May 2002 14:27:00 -0600 (MDT)
|
||||
"Bear Giles" <bgiles@coyotesong.com> wrote:
|
||||
> A second cut at SSL documentation....
|
||||
|
||||
I've pointed out some minor things I noticed while reading through.
|
||||
Yeah, I was bored :-)
|
||||
|
||||
> The sites that require SSL fall into one (or more) of several broad
|
||||
> categories.
|
||||
>
|
||||
> *) They have insecure networks.
|
||||
>
|
||||
> Examples of insecure networks are anyone in a "corporate hotel,"
|
||||
|
||||
What's a corporate hotel?
|
||||
|
||||
> *) They have 'road warriors.'
|
||||
|
||||
This section title sounds confusingly similar to the 1st item.
|
||||
Perhaps "They need to authentication clients securely" or something
|
||||
similar? The need to use client certificates does not apply only to
|
||||
"road warriors" -- I've seen situations where client-certs are used for
|
||||
clients to connecting to a server over a LAN.
|
||||
|
||||
> *) Access is limited to the Unix socket.
|
||||
|
||||
"the" sounds wrong, there's more than just 1 :-)
|
||||
|
||||
> *) Access is limited to a physically secure network.
|
||||
>
|
||||
> "Physically secure" networks are common in the clusters and
|
||||
> colocation sites - all database traffic is restricted to dedicated
|
||||
> NIC cards and hubs, and all servers and cabling are maintained in
|
||||
> locked cabinets.
|
||||
|
||||
Perhaps add a note on the performance hit here?
|
||||
|
||||
> Using SSH/OpenSSH as a Virtual Private Network (VPN)
|
||||
|
||||
I'm unsure why you're bothering to differentiate between SSH
|
||||
and OpenSSH.
|
||||
|
||||
> SSH and OpenSSH can be used to construct a Virtual Private Network
|
||||
> (VPN)
|
||||
|
||||
No need to include the abbreviation for VPN here, you've explained
|
||||
the term before.
|
||||
|
||||
> to provide confidentiality of PostgreSQL communications.
|
||||
> These tunnels are widely available and fairly well understood, but
|
||||
> do not provide any application-level authentication information.
|
||||
|
||||
You might want to clarify what "application-level authentication
|
||||
information" means, or else leave out all discussion of drawbacks
|
||||
until later.
|
||||
|
||||
> To set up a SSH/OpenSSH tunnel, a shell account for each
|
||||
> user should be set up on the database server. It is acceptable
|
||||
> for the shell program to be bogus (e.g., /bin/false), if the
|
||||
> tunnel is set up in to avoid launching a remote shell.
|
||||
>
|
||||
> On each client system the ~/.ssh/config file should contain
|
||||
> an additional line similiar to
|
||||
>
|
||||
> LocalForward 5555 psql.example.com:5432
|
||||
|
||||
"pgsql.example.com" strikes me as a better example hostname (I always
|
||||
think that psql == DB client, postgres/postmaster/pgsql == DB server).
|
||||
|
||||
> Unfortunately, there are many potential drawbacks to SSL tunnels:
|
||||
|
||||
I think you mean SSH tunnels.
|
||||
|
||||
> *) the SSH implementation or protocol may be flawed. Serious problems
|
||||
> are discovered about once every 18- to 24- months.
|
||||
|
||||
I'd be skeptical whether this weakness if specific to SSH -- there
|
||||
can be security holes in OpenSSL, the SSL protocol, the SSL
|
||||
implementation in PostgreSQL, etc.
|
||||
|
||||
> *) the database server must provide shell accounts for all users
|
||||
> needing access. This can be a chore to maintain, esp. in if
|
||||
|
||||
Remove the "in".
|
||||
|
||||
> *) neither the front- or back-end can determine the level of
|
||||
> encryption provided by the SSH tunnel - or even whether an
|
||||
> SSH tunnel is in use. This prevents security-aware clients
|
||||
> from refusing any connection with unacceptly weak encryption.
|
||||
|
||||
Spelling error.
|
||||
|
||||
> Finally, the client library can have one or more trusted root
|
||||
> certificates compiled into it. This allows clients to verify
|
||||
> certificates without the need for local copies. To do this,
|
||||
> the source file src/interfaces/libpq/fe-ssl.c must be edited
|
||||
> and the database recompiled.
|
||||
|
||||
"PostgreSQL" recompiled -- database versus RDBMS can be ambiguous.
|
||||
|
||||
> Mutual authentication requires that servers and clients each
|
||||
> authenticate to the other. This protects the server from
|
||||
> false clients in addition to protecting the clients from false
|
||||
> servers.
|
||||
|
||||
"false" in this context?
|
||||
|
||||
Cheers,
|
||||
|
||||
Neil
|
||||
|
||||
--
|
||||
Neil Conway <neilconway@rogers.com>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user