Re: Traffic Analysis

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> writes:

> I was reminded a few weeks ago that traffic analysis has been a sore spot
> for SSH (both v1 and v2) in the past.

I think there are sufficient support in the ssh2 protocol to make
traffic analysis harder, but I think it's done very poorly in current
implementations. I don't even try.

My first suggestion to myself and others wanting to make ssh
connections harder to analyze, is as chop up the stream into TCP
segments at boundaries that are unrelated to the ssh message
boundaries.

To explain this idea by example, say you have some 17 bytes of data do
send, an SSH_MSG_CHANNEL_DATA or SSH_MSG_USERAUTH_REQUEST, and this
generates some 48 bytes of encrypted data using minimal padding. Say
you want to hide ssh message lengths by sending TCP segments of 100
bytes only. Then, generate a random SSH_MSG_IGNORE packets, so that
you get a total amount of encrypted data of 112 bytes, say. Send a 100
bytes TCP segment, and leave the remaining 12 bytes, corresponding to
a part of the SSH_MSG_IGNORE packet, wait in the output buffer until
you have any new data you want to send.

This is just a simple example, one can impose more sophisticated
requirements on the size and timing of transmitted segments.

If this is done carefully, I think the only information you will give
the adversary is

  1. The TCP/IP end points.

  2. A coarse measure on the activity over time.

For 2, say you make the implementation send one 100 byte segment every
100ms or so (depending on how mush network resources your willing to
spend on an essentially idle connection). Then if the user starts to
transfer a large file over the session, then you'll want to increase
the packet size or decrease the inter-packet spacing in order to get
the job done in a reasonable time, and the attacker can observe this.
It seems hard to avoid leaking information about (2) this problem
without sacrificing a lot of either usability or network efficiency.

Maybe all of this is obvious to everybody, but I appreciate comments.
If/when I add resistance to traffic analysis to my implementation, I
plan to use soem variant of the above scheme.

> 9.2.9  Traffic Analysis
> 
>    Passive monitoring of any protocol may give an attacker some
>    information about the session, the user, or protocol specific
>    information that they would otherwise not be able to garner.  For
>    example, it has been shown that traffic analysis of an SSH session
>    can yield information about the length of the password.  [Openwall]
>    Implementors should use the SSH_MSG_IGNORE packet as described in
>    [SSH-TRANS] along with any other methods they may find to prevent
>    traffic analysis.

The phrase "as described in [SSH-TRANS]" makes me think that the
referenced document describes in detail what one should do. But the
document (naturally) describes only the message format.

Besides this minor detail, the text looks ok to me.

Regards,
/Niels