IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Albrecht/Paterson/Watson's attack



[me]
>> http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf

[denis]
> Our implementation in Bitvise SSH Server (versions of the last
> several years that use our FlowSsh library) makes this class of
> attack difficult by: [turning corrupt packet lengths into random
> valid packet lengths]

I've now implemented this defense in moussh.  I don't quite do it as
described above, because, if done that simply, there is a (small)
chance the MAC will pass and feed corrupted data into the session.
When generating a random valid packet length, I also switch the
connection to using a dummy MAC algorithm which is basically just like
the "none" algorithm except that checks always fail (for "none" they
always succeed).  Thus, when/if the randomized packet length is
exhausted, it will exhibit the behaviour corresponding to a MAC failure
with probability 1, rather than 1-(2^-160) (or whatever, depending on
the MAC in use).

[me]
>> make it hard to identify packet boundaries by, whenever the
>> connection would otherwise go idle, generating an IGNORE packet and
>> sending only part of it, holding the rest until something more is
>> available to be sent on that connection.
> I think that's a good idea in general, also to make traffic analysis
> a bit more difficult.

moussh does not yet include this defense; I found it remarkably
difficult to do.  I will need to think about how to implement this.  It
may call for improving the APIs to my crypto libraries, since it's hard
to do this without either (a) generating a lot of unnecessary IGNOREs
or (b) having support for encrypting something and then rolling back, a
way to encrypt the IGNORE and then, if it turns out it doesn't get
written, reset the crypto's state to pretend it wasn't encrypted after
all.  (Doing it in another write() would be easy, but risks introducing
a TCP packet boundary at the BPP packet boundary whose concealment is
the whole point of this.  TCP doesn't promise that write() boundaries
will produce TCP segment boundaries, but it actually does so relatively
often anyway.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



Home | Main Index | Thread Index | Old Index