On Sat, 06 May 2000, Benjamin Adida wrote:
> While SSL could probably be an option for people dealing with tremendously
> sensitive data that shouldn't go in the clear over their internal network
> (we're not talking about passwords here, just the SQL queries and
> responses), I think it's overkill to impose SSL for everything.
>
> The key exchange and constant encryption overhead would significantly affect
> performance, so this doesn't seem like something to impose on everyone.
>
> -Ben
I agree that it should not be active all the time. Just active for databases
that have been setup to require it if the dba sets the option for it. My idea
is that it would work like this:
1. Client connects to server. The initial connection is automatically SSL.
2. The user is authenticated.
3. The client and server renegotiate the connection to drop out of SSL and to a
normal unencrpyted connection by default. However, if the database has been set
to require a secure connection by the database owner, then the SSL connection
will remain. This adds some overhead to connecting to the server, but when
people need performance, they use persistent connections.
The dba would have to set the database to require the SSL connection to remain
by running commands something like:
CREATE DATABASE mydb SECURE; -- creates it initially secure.
ALTER DATABASE mydb ADD|DROP SECURE; -- alters the secure option.
(some proposed Postgres extensions:)
OpenSSL is under the BSD license (www.openssl.org). Its source code can be
integrated into the PostgreSQL source code so that users need know nothing
about it. It would just get used internal to Postgres and the client
libraries.
OpenSSL also contains an MD5 routine that can be used on the passwords.
So far, no one is excited about this so I will not push it anymore.
--
Robert B. Easter
reaster@comptechnews.com
