I would like to revisit the question of including encryption in the core
Interbase product.

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. However, there are some practical problems which
would be easily solved if this could be included.

Take the case of the application seller who uses an "embedded database"
within a software product where the deployment is into varied and
widespread situations. 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".

Another example: As consultants we connect to our central office database
from our own offices. We also connect from temporary locations, such as
hotels, etc. where we have no control over the layering of stuff between
our client and our server (but do not expect anything nasty to interfere).
We also connect from client locations where we also have no control over
intervening layers but can expect various firewall and VPN layers to be in
use which might be incompatible with our chosen security solution.

Now the first situation we have some control over. However, even in this
case a secure solution which meets all needs is very difficult to achieve.
We have remote offices with proxy servers in place, some with dial-up
connections only, some with NAT routers, and some with ISDN routers. The
hassles we are facing for achieving a uniform level of TCP/IP security, via
a software-based VPN solution are formidable. This extends both in
understanding what is available, understanding exactly what we need, and
discovering what products are available to match our needs. So is the cost.

In the cases of the temporary connections and the connections from client
locations, we might typically have to turn off any VPN stuff in order to
connect back to our central office.

Now if we could activate an internal Interbase level of encryption, which
is applied by the Interbase client and server only for communication
between each other, it would simplify things enormously. We could at least
be sure that those connections were protected at some level. All that would
be left would be to ensure that the port in use was allowed to be used.

With the previous discussion on this list of having plug-in libraries for
authentication and authorization functions, it seems to me a natural
extension to allow for an encryption plug-in. Having this API available,
even if the default configuration does not employ it, would not muck up the
core product much. It would allow for an easy solution to the problem in
some cases.