Re: [HACKERS] 2nd cut at SSL documentation
I have added this to backend/libpq/README.SSL to be integrated into our main docs later. --- Bear Giles wrote: 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 $HOME/.ssh/config file should contain an additional line similiar to LocalForward 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=$HOME/.ssh/identity.psql /usr/bin/ssh -1 -i $IDENTITY -n $HOST 'sleep 60' \ /usr/bin/psql -h $HOST -p $1 Alternately, 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
Re: [HACKERS] 2nd cut at SSL documentation
On Tue, 21 May 2002 14:27:00 -0600 (MDT) Bear Giles [EMAIL PROTECTED] wrote: A second cut at SSL documentation [snip] 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 $HOME/.ssh/config file should contain an additional line similiar to LocalForward psql.example.com:5432 I'm coming to this party a bit late in that this is the first I've read the documentation. I'm also a bit of a newbie when it comes to SSH and I've not investigated ssh3 at all yet. However, isn't this assuming ssh1 only? I know ssh2 will fallback to ssh1 compatibility but should there be something about configuring for the later versions? -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 2nd cut at SSL documentation
On Tue, 21 May 2002 14:27:00 -0600 (MDT) Bear Giles [EMAIL PROTECTED] 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 $HOME/.ssh/config file should contain an additional line similiar to LocalForward 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 [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
