RE: Binary packet protocol rethink

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 02 December 2015 02:44 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94DE1B3186 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Tue, 1 Dec 2015 18:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9InJsbXCokY for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Tue, 1 Dec 2015 18:44:35 -0800 (PST)
Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962941B3185 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Tue, 1 Dec 2015 18:44:35 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id A010685E5F; Wed, 2 Dec 2015 02:44:33 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 3928885E5B for <ietf-ssh@netbsd.org>; Wed, 2 Dec 2015 02:44:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id yEUQuNnJ2CXe for <ietf-ssh@netbsd.org>; Wed, 2 Dec 2015 02:44:29 +0000 (UTC)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A7F1985E3F for <ietf-ssh@netbsd.org>; Wed, 2 Dec 2015 02:44:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1449024268; x=1480560268; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b/BEJqpJaaRhz4/JKCVoufTaEfIUc16h4R1zCGkOnFg=; b=WkJ7JDz+tMEC0A9GAeUsJ1red6QH/653ZByJf1KAHh2SjVE8RU8JNYew c8fWCvjgA9Xsl+ZCXrN6fNpG74XPsN9HCdF3pTfZ6AZ8mR5p7xJTQHyG6 Ri5ZoQofy6f9r/ctBybbup3ehW37fIBJRR+O5VBeAhr6dRxV0FHhwlvuK WGV93vahzdAkB+cCTiUlbYRrNLfmcyYUfji1KG3bqngk9/lRwna6Jht7j IbxObvbLVtV28HNMKfVqqTkcCIfyUyhRvt778swZeOHZrWK8Aq7BsePCo 8z3JS6rjGe+lBh/wAoMYVJyvwsnCOWvDzzGASK3HxiNw8IyQdeWf7rKS4 A==;
X-IronPort-AV: E=Sophos;i="5.20,371,1444647600"; d="scan'208";a="57156016"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Dec 2015 14:09:35 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Wed, 2 Dec 2015 14:09:34 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Niels Möller <nisse@lysator.liu.se>
CC: Damien Miller <djm@mindrot.org>, Simon Tatham <anakin@pobox.com>, Simon Josefsson <simon@josefsson.org>, "ietf-ssh@netbsd.org" <ietf-ssh@netbsd.org>
Subject: RE: Binary packet protocol rethink
Thread-Topic: Binary packet protocol rethink
Thread-Index: AQHRK2HLMJRbFzQ1ukq+Xs4ulafSe5625PVi
Date: Wed, 02 Dec 2015 01:09:33 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B95D3F@uxcn10-5.UoA.auckland.ac.nz>
References: <87egfdxebo.fsf@latte.josefsson.org> <87egfdxebo.fsf@latte.josefsson.org> <nny4dksr3i.fsf@armitage.lysator.liu.se> <1448554180-sup-7145@atreus.tartarus.org> <9A043F3CF02CD34C8E74AC1594475C73F4B857C7@uxcn10-5.UoA.auckland.ac.nz> <alpine.BSO.2.20.1511292228450.12629@natsu.mindrot.org> <9A043F3CF02CD34C8E74AC1594475C73F4B92EF0@uxcn10-5.UoA.auckland.ac.nz> <nn37vnsyoi.fsf@armitage.lysator.liu.se> <9A043F3CF02CD34C8E74AC1594475C73F4B9321A@uxcn10-5.UoA.auckland.ac.nz>, <nntwo3raow.fsf@armitage.lysator.liu.se>
In-Reply-To: <nntwo3raow.fsf@armitage.lysator.liu.se>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

Niels Möller <nisse@lysator.liu.se> writes:

>The ssh transport machinery can encrypt these, then split them into fixed
>size blocks and send off with pre-determined intervals, and whatever else you
>think is a useful counter measure to traffic analysis. When an input message
>or message fragment is too short, insert ignore messages (preferable in
>*front* of the real data, for the byte-by-byte dribble attack).

The important point there is that it *can*, not that it actually *does*.  I've
heard that there was an OpenSSH patch some years ago that did something like
this, but in about 15 years of interop-testing my code I've never seen any
evidence that the other side is applying any traffic-analysis countermeasures.
A quick Google turns up this blog post from a few months ago:

http://malwaremusings.com/2015/07/13/traffic-analysis-openssh-with-an-interactive-shell/

which indicates that OpenSSH doesn't implement traffic-analysis protection
(not trying to single out OpenSSH here, but that seems to have the most bells
and whistles added to it so if it was implemented I'd sort of expect to see it
there first), and that some random guy with a copy of Wireshark (not an
intelligence agency, if that's what the perceived threat is) doesn't have much
problem in doing traffic analysis on it.

So there appears to be either zero or close to zero support out there for
anti-traffic-analysis.  Even if, say, OpenSSH were to add support, that would
only affect two similar OpenSSH implementations talking to each other.  As
soon as you get a single other SSH implementation involved (and there are a
lot of them out there), you lose the anti-traffic analysis.

>I'm happy to discuss the tradeoffs here, but it seems that you keep repeating
>that the attacker gets as much useful info from observing tcp segment
>boundaries as from observing ssh message boundaries.

At the moment it seems they do.  Unless actual, real countermeasures to
traffic analysis are actively applied by as many SSH implementations as
possible, encrypting the headers does nothing more than inconvenience
implementers.

So, let's turn this around: Show me evidence of assorted SSH implementations
performing anti-traffic-analysis measures, and then we can debate whether
encrypting the length hinders those countermeasures.

Peter.