[Tapioca-devel] Ideas on the plumbing protocol

[Eric L. G. <er...@ba...>]

1. The actual low level network communication widget just
 sends stdin/stdout across the network, encrypting it via a stream cipher
(I suggest RC4, since OpenSSL does RC4 just fine).

2. At each end, there is a multiplexor for the multiple inputs
(stdout, stderr, various named pipes), and a de-multiplexor that
takes a stream coming from the other end and turns it back into the
multiple streams, sending those streams wherever.

The next question is whether to make the low level network communications
an SSL socket, or not. My own thought is "or not". The problem is key
management. Specifically, the only way to do one-time keys (needed to send
data from a remote system directly to a remote drive without causing a
security hole) is for the server to provide the one-time key to both
parties under its own key. After the key is used to authenticate the
single transaction allowed by it, it goes away.

By the time I have all the key management issues wrapped up in a way that
is suitable for backups (rather than for web servers), I've already
implemented far more code than a simple loop that does a recv() on a
socket, calls the stream decrypter on the buffer to decrypt it, then
writes the buffer to its stdout. I can't see of any easy way to
use SSL certificate management to handle this problem, and am of the
opinion it's probably better just to write it from scratch.

I will spec this out further tonight, and probably start laying down
some code. I looked at OpenSSH. It is a mess. Not because the programmers
are incompetent, but because of all the backward compatibility stuff.
So modifying OpenSSH for what we want to do would probably take more time
than writing from scratch. Sigh. Oh well, time to crack the Stroustrup.

-- 
Eric Lee Green                             mailto:er...@ba...
               BadTux: http://www.badtux.org