Markus Friedl wrote:
On Mon, Jan 17, 2005 at 12:14:40AM +0000, Ben Harris wrote:In article <Pine.HPX.4.58.0501161506080.12089%edison.cisco.com@localhost> you write: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.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.please don't add this, random padding is wrong and 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