On 28 Oct 2000, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> Ssh is open software. If there is a bug, it can be fixed by writing to
> the authors. If you mean Windows, use Putty. If you mean solaris,
> ask the people who run the free solaris software sites to add a
> correctly compiled ssh package.
>
> And anyway, you will have the same OS bugs to contend with as anyone
> else, but much less experience than the present teams.
I suspect it will be less likely to provoke the bugs than
rsync-over-ssh. To the OS, it will look just like rsync-daemon, and
there have been many fewer bugs reported there.
> > > There's very little percentage in this. while an xor costs nothing
> > > to implement, you have to change the key every few bytes to stop it
> > > being subject to differential analysis. That implies frequent key
> > > exchanges using a tougher key.
> >
> > You seem to think I was talking about using xor with a constant key,
>
> Not really, as you can see.
Then I don't understand how a chosen-plaintext attack could give away
the encryption key.
> > in which case that would be true. I'm not quite that stupid. I was
> > planning to use arcfour, which should make even chosen-plaintext
> > attacks hard. (I should have said so explicitly.) The weakness is
>
> It should. But writing crypto software is horribly hard - you have to
> guarrantee (a) that it's bugfree, and (b) that it's got no
> backdoors.
I agree. For this reason the scope is intentionally very small, and
the claims of security very modest.
> And I speak as the person who wrote the rsa software used by the
> Iberian penisular banks for all their interbank transactions.
Thank you for taking the time to send comments.
> > I agree that a little knowledge about crypto is a dangerous thing.
> > But what would you rather: that nobody should write network
> > applications at all?
>
> I don't see what's wrong with using ssh, or not using it. Why is
> using rsync with embedded crypto supposed to be easier that
> rsync --rsh=ssh? Or if not easier, then "better"? You can change
> to another transport if you don't like ssh. That's the idea of the
> layered design.
Built in arcfour is less secure but I hope will be more reliable.
The layered design with two processes talking to a single SSH is prone
to locking up because of bugs that are apparently in some cases in
rsync, but in others in ssh or the kernel. It seems that the problems
come from the very fact of using an external process as a transport.
One approach is to try and work around those bugs, but that's not yet
been completely successful. I'd like to try an alternative.
> > Even if we decide not to implement it please just consider this thread
> > just me trying to learn a little more about the right way to do it.
>
> It's a pretty big learn! You have to implement a transport protocol
> over tcp in order to leave teh rest of rsync alone. Sliding the code in
> won't work .. the sizes of every packet change .. you have to pack
> one protocol within another in a protocol stack.
No, I don't think we need another layer, though I might be wrong. If
we did, then this would no longer be a simple change and it wouldn't
be worthwhile.
The algorithm is basically: if the --weak-privacy option is specified,
then create an arcfour cypher at each end using MD4(password,
challenge, ...) as the key. The two sides both have that information,
but the password has not been sent clear over the wire. Therefore no
key exchange is required, and the key will be different on every
transfer.
Once the options have been agreed by the two sides, both of them turn
on encryption. Everything sent over the wire from this point on is
XORd with a byte from the arcfour generator. There *are* no packets
to change; the rest of rsync on each end just sees a bidirectional
stream as before.
> > Andrew's already established that the bugs are in the tcp stack, not
> > in ssh or rsync. On anything non-free it's not in my power to fix it.
>
> This is not absolutely so. There is room for variation in the specs,
> and it seemed to me that the linux behaviour was within spec. It just
> happened to mess up an out-of-spec behaviour from a solaris machine
> seeing if it could cut corners, as I understood it. But I agree, it's
> a transport question. If you want to avoid the problem, implement your
> own udp protocol.
I'm trying to avoid the whole question of transports by making rsync
--daemon more generally useful.
> > That's a good point. In the end, perhaps offering weak security as an
> > alternative is a bad idea, as people may be tempted to use it rather
> > than doing a little more work to install ssh. On the other hand,
> > sometimes something is better than nothing.
>
> Installing ssh is a zero-brainer.
but making it work properly on all platforms is proving to be a bit
harder.
> > warn the user but allow them to proceed.
> >
> > Indeed, arguably rsync should never support SSL, because unlike SSH
> > it's easy to use it in an insecure manner.
>
> ?? Don't you have these mixed up! It's ssl that's secure against
> first-time impersonation, not ssh.
Yes, but only if people either pay for certificates from a commercial
CA, or set up and run their own CA. I don't think most sysadmins will
do it properly. In the situations in which rsync is often used I
think people are more likely not to establish trusted certifiers on
every client, and so it doesn't even have the protection of retaining
previously seen certificates.
SSH is simple to use and more likely to come up secure by default.
SSL is much more complicated (from the outside) and in practice likely
not to be used safely by many people.
> > Do you think it would be reasonable to make arcfour encryption a
> > non-default compile-time option, turned on with --with-weak-privacy?
>
> I honestly don't think it's worth it. Anyone who can compile can
> compile (and install) ssh.
Possibly it is not worthwhile after all -- I always knew it would be
worse than SSL but the idea of completely cutting out the transport
problems was tempting.
If it turns out that there are OS bugs and they can't be fixed on some
platforms, then rsync should probably try to work around them. As I
mentioned before, perhaps turning off pipelining would help.
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
