Hi Mark,

> For a new protocol optional tunnelling of all traffic over ssl is a
> good idea.
>
> It's fairly easy to build both client and server components using
> openssl.
>
> But I'd stress that SSL should be *optional* since mostly you want a
> fast communication rather than needing a secure encrypted connection
> and the performance overhead of ssl for all traffic is not worth it.

Why cannot we support both SSL and "traditional" connection methods?
SSL usage should be more or less transparent to the network
components. When you connect to SSL port, first you have SSL
handshake, then normal data flow. When you connect to normal port,
everything remains as it is. The same way you can add compressed
channel (for example a GZip-based one). Look, we have already a
working examples like ZeBeeDee or simple SSH tunneling. And it works.

For now I'm sceptic that encrypting only payload for the messages
instead of complete traffic would bring us significant performance
improvement, especially if you consider that each packet is of ~1,5k big.

I see no point in having a secure setup for the LAN, because you can
solve this in the hardware much more easier compared to the encrypted
protocol (a separate physical link between two points is much more
secure then any software solution). And setup where the insecure link
is used between client and server (WAN) most likely will provide much
bigger delays compared to ones added by SSL layer. Solving the
performance issue requires redesign of the whole API - we have many
packets flying between server and client in the places where it can be
avoided.

So my suggestion would be to forget performance improvement for now
and concentrate on security. Jim's approach is nice, however requires
more coding compared to simply using SSL. For now I'm in favor of SSL,
but if somebody demonstrates me that SSL is much slower compared to
encrypting the single packets, I am ready to implement new scheme in
JayBird.

Roman