Alex,

> On 11/09/10 21:50, Jim Starkey wrote:
>> The line protocol is a different matter entirely. The packets are more
>> deterministic and have less infrastructure than data pages, aren't
>> compressed (last time I looked, at least). Carefully analyzed, it is
>> distinctly possible that useful information might leak. Here, CBC is
>> important. But is the initialization vector significant? If there were
>> any chance that two sessions would play out identically, perhaps. But
>> the nature of the protocol makes this virtually impossible.
>
> This is very important. Certainly, we may add compression before crypt.
> But this does not solve a problem with a lot of small packets (like
> op_response) that have very deterministic nature.
>
> But first of all I need to know - do you suggest to start CBC for each
> package or treat the flow of packages as a single object to crypt? The
> second approach is definitely more secure, but in case of lost single
> package we are in trouble.

Why not barely establish a standard TLS session, then run the current line protocol (or however it will have evolved for version 3) through that tunnel. You'll get nothing (security wise at least) by having Firebird implement a home-made line-encryption scheme. I'm not saying to use an external tool, but to add a TLS compliant server shell in the remote listener and have the client valve engage the TLS session with the serve before letting the first byte of the actual Firebird line-protocol flow.

This won't remove the need to think about and manage certificates at the server (and eventually at the client), but the secured tunnel will be setup on standard established schemes. There are a number of libraries offering that kind of facilities, the name most often used being OpenSSL, but there are a good number of others.

—
Olivier Mascia