Re: [HACKERS] 2nd cut at SSL documentation

On Tue, 21 May 2002 14:27:00 -0600 (MDT)
"Bear Giles" <bgiles(at)coyotesong(dot)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 $HOME/.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(at)rogers(dot)com>
PGP Key ID: DB3C29FC

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--ELM1032744392-11773-0_--