Subject: Traffic Analysis

From: Chris Lonvick <[email-masked]>
Date: Sun, 16 Jan 2005 15:14:10 -0800 (PST)

Hi,

I was reminded a few weeks ago that traffic analysis has been a sore spot
for SSH (both v1 and v2) in the past.  SSH_MSG_IGNORE is actually called
out to thwart "advanced traffic analysis" in [TRANS].  However, there is
no reference to it in the Security Considerations section in [ARCH].  To
rectify that, I've added the following text and reference to [ARCH].

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.

   [Openwall]
              Solar Designer and D. Song, "SSH Traffic Analysis
              Attacks", Presentation given at HAL2001 and NordU2002
              Conferences, Sept 2001.

Please let me know if this is acceptable.  Does anyone have any better
reference?

Thanks,
Chris

---

From: Ben Harris <[email-masked]>
Date: Mon, 17 Jan 2005 00:14:40 +0000

>   [SSH-TRANS] along with any other methods they may find to prevent

It might also be worth mentioning that the "random padding" field can be
used to obscure the length of packets.  I'd suggest, after "SSH_MSG_IGNORE
packet" adding ", and variable-length random padding,", though that wording
could doubtless be improved.

-- 
Ben Harris

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 17 Jan 2005 23:02:26 +1300

Chris Lonvick <[email-masked]> writes:

Very minor nitpick, the sentence break attaches the "Openwall" to the
following sentence, so it appears to be reading:

   can yield information about the length of the password.  
   
   [Openwall] Implementors should use the SSH_MSG_IGNORE packet as described

Peter.

---

From: Markus Friedl <[email-masked]>
Date: Mon, 17 Jan 2005 09:09:18 +0100

> could doubtless be improved.

please don't add this, random padding is wrong and
does not really help, as it can be filtered out.

---

From: Ben Harris <[email-masked]>
Date: Mon, 17 Jan 2005 12:05:13 +0000

>does not really help, as it can be filtered out.

How so?  The padding, and its length, are encrypted, so I can't see how an
attacker is likely to be able to filter out the padding unless they've
already broken the cipher, in which case their knowing the length of the
packet is the least of our problems.

If there's something I've overlooked, then an explanation of it probably
needs to be added to the Security Considerations so that others don't
overlook it too.

-- 
Ben Harris

---

From: [email-masked] (Niels Möller)
Date: 17 Jan 2005 15:01:57 +0100

Chris Lonvick <[email-masked]> writes:

> 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.

>    [SSH-TRANS] along with any other methods they may find to prevent

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

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 18 Jan 2005 03:16:23 +1300

Chris Lonvick <[email-masked]> writes:

>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

Nor do I (well, except in the handshake phase where I pad a few packets that
matter to a constant length).  It'd be kind of a fun thing to play with/hack
around on (there's a million parameters you can tune, cover traffic
generation, padding to fixed boundaries, TCP segment slicing as you say, etc
etc), but so far I've had zero user demand for this so I'm not in any hurry to
implement it.  Has anyone seen any significant demand for this from other than
tinfoil-hat types?

Peter.

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 17 Jan 2005 10:33:48 -0700

> does not really help, as it can be filtered out.

I'm not sure I understand this?  How can it be filtered out?
I thought this attack was based on the fact that in most
implementations, for certain key packets, the TCP segment
length (which is observable) often corresponds to the the
SSH packet length (which is not observable), and therefor
allows certain deductions about the length of sensitive
fields with-in the packet?

If that is the case, then it seems to me that perturbing the
pad to change the length of the the packet (and therefore
the length of the TCP segment) would remove the attackers
ability to make such deductions about the length of fields
in the packet?

It also seems that it is more likely that a packet with extra
pad will be sent as one TCP segment than that a
SSH_MSG_USERAUTH_REQUEST and a SSH_MSG_IGNORE will be sent
in a single TCP segment (and probably easier to implement.)

In fact, I believe the wording above needs some adjustment
to note that for SSH_MSG_IGNORE to be effectively used
to thwart this kind of attack, it MUST be sent in the same
TCP segment as the SSH packet it is protecting.

Thanks,

Joseph