Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks

Brian Trammell <> Fri, 29 July 2016 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BADAE12D80B for <>; Fri, 29 Jul 2016 09:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VUbkG8DlXh-9 for <>; Fri, 29 Jul 2016 09:29:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F5FF12B00B for <>; Fri, 29 Jul 2016 09:29:33 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 034071A0C60; Fri, 29 Jul 2016 18:29:32 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9C22C695-778A-433A-A961-A7266521ACBA"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <>
In-Reply-To: <>
Date: Fri, 29 Jul 2016 18:29:32 +0200
Message-Id: <>
References: <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:, spud <>
Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2016 16:29:36 -0000

Hi, Tom,

> On 29 Jul 2016, at 17:49, Tom Herbert <> wrote:
> On Fri, Jul 29, 2016 at 5:33 AM, Brian Trammell <> wrote:
>> Greetings, all,
>> During the PLUS BoF last week, concern was expressed that a generic signaling mechanism such as proposed opened two new attack surfaces:
>> (1) A method for endpoints to allow path elements to add non-integrity protected signals presents a surface for metadata injection attacks, where an entity who can place devices on a user's access network and has information about the user's identity could exfiltrate that information to third parties. For purposes of giving it a name, let's call this a hypercookie injection attack ("hyper" since it exists in a space completely inaccessible to the application).
>> (2) Even if path elements are not allowed to say anything, a mechanism to allow endpoints to add integrity-protected signals to their traffic presents a surface for coercion attacks. An access provider can force a user to tag traffic with their user ID or some other token (a signed assertion that an advertisement has been viewed to the end, or maybe even just straight-up bitcoins) in order to get "better" connectivity, or even any connectivity at all. A more classically Orwellian dystopian variant of this attack has a government requiring citizens to tag all their outgoing traffic with some government-issued identifier. Let's call this a hypercookie coercion attack.
>> I am less concerned about the surface PLUS presents to these attacks than those who have raised the concerns in the BoF and on the mailing list, because the current Internet architecture is already quite vulnerable to them. As I said during my presentation last Thursday, Ted Hardie and I sat down to think about this at lunch a couple of months ago, and found six ways one could execute hypercookie injection or coercion today before our pizza showed up.
> Brian,
> I think there is a significant practical difference between the
> vulnerability of hypercookie injection in TCP/IP and what would be
> present in PLUS. In order to enforce a hypercookie injection in TCP
> one would need to change the TCP stack which typically necessitates a
> kernel change.

Nope. I don't need to touch the endpoints at all for an injection attack. I just need one middlebox near the source to rewrite packets, and (possibly) another one downstream to pick up the signals. (Okay, I might need to hack the kernel on my middleboxes. But I get to do that. They're mine. :) )

Some of these techniques work without kernel changes for coercion attacks, too ("Use this DHCPv6 server to access the network while in the territory of Oceania"). Others (ISN side channels) would require kernel changes. (Exercise for exceptionally paranoid readers: demonstrate that no shipping closed-source consumer stack uses initial sequence numbers and legacy IP fragment identifiers as a side channel to expose metadata to the path.)

The whole point of the attacks as outlined is that the side channel is either undetected by the destination, or that the malformed packets are passed by the path and dropped by the destination.



> In the PLUS world one would only need changes in the
> particular applications of interest, this is is a much easier task for
> the attacker.  Now instead of having to deal with large OS vendors
> that vigorously defend privacy (e.g. Apple vs. FBI), authorities can
> go after much smaller players forcing them to either comply or cease
> operations. Putting control of information solely in the users hands
> is not necessarily a good thing.
> Tom