Doug Chamberlin wrote:

>
> I have long been in the camp that says that encryption of
> client-server communications belongs outside the sphere and
> responsibility of the database server vendor.

Me too. My reasons are:

o The state of the art of encryption moves too quickly for
InterBase to keep up.

o Once InterBase claims to support encryption, the vendor accepts
a level of liability for security that too high.

o An InterBase-only encryption mechanism is useless.
Any security package that an IT shop chooses must account for
any type of traffic, which is typically email, file access,
http, and perhaps telnet.

> However, there are some practical problems which
> would be easily solved if this could be included.

The problems are typically not technical, but bureaucratic in nature.

> If a buyer asks about the security of the
> client-server communications, this vendor currently says, "That's up
> to your overall network communication security." But when client-server
> communications cannot be controlled as to when and from where they
> occur, this answer is tantamount to saying, "You have no predictable security
> at all".

A security-conscious site *wants* application-independent control over
their network encryption and security.

For example, this week, I was working with a web-hosting company who
insists that we access their machines using a VPN mechanism, connecting
using IPSec. Additionally, they insisted that if I telnet into the
machine, that I use ssh, not plain telnet protocol. It seems kind of
redundant to encrypt by session when I'm already using an encrypted IP
stack, but that's what they wanted.

If I needed to do a client/server connection, and I said, "My RDBMS has
built-in encryption on the wire!" I predict that they would say, "Good
for you. You can connect using your software, _on top of_ our VPN's
IPSec connection."

Most shops won't trust encryption that is bundled with an application.
They've done their independent research and settled on their network
security implementation, and they have a policy that anything -- even
encrypted traffic -- has to use their secure connection.

> The hassles we are facing for achieving a uniform level of TCP/IP
> security, via a software-based VPN solution are formidable.

My point is that these hassles won't be reduced, whether InterBase
includes encryption or not. The people running the VPN won't allow
*anything* to come into their network that isn't using *their* security
mechanism.

> All that would be left would be to ensure that the port in use was allowed
> to be used.

This is another problem. Secure networks typically are not eager to
open up more ports than they have to. They prefer that if you need to
use a port, you use a "tunnel" on their preferred security
implementation. They are *not* going to open up port 3050, even if
InterBase includes encryption technology.

Bill Karwin