Re: [Masque] MASQUE detection through tracking trackers

Ted Hardie <ted.ietf@gmail.com> Tue, 05 November 2019 17:15 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3691200FE for <masque@ietfa.amsl.com>; Tue, 5 Nov 2019 09:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rLV71cZNXKaQ for <masque@ietfa.amsl.com>; Tue, 5 Nov 2019 09:15:54 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760AF12010E for <masque@ietf.org>; Tue, 5 Nov 2019 09:15:54 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id q83so2266000iod.1 for <masque@ietf.org>; Tue, 05 Nov 2019 09:15:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hYWcRb5v8fQ9dl40aHlgxfVdQjCqcgh/5G82dj9XeIQ=; b=WipGS9AcePulbTSe6jwsyGnhmMuvjGR9385vJEzm0I1Vy9/EYwVdtYasuIEONxaWlY zQMFau73DmxPk+3P/F0GBYkge8ZIwBHqwPtRv7ubTUe9No+ekto+9rbZELrL+52tk+c5 hZAWDcijWqjR9DfPJO+qprx8dJ3XZQj6ssibTEweLKY5mQkxE8BDxsjmbY7LYnek98eS k6rrFM5w/RYoLL5ANvy/5SDO7tTJds99udOFCJrvuU41xRlDW2aT0gtt2/nSSuhN58hq vmaCSuLZaZMVBRVvhURzZ/Opc/U41287SvNh/upaf8p+B+kC8kzt2H7u34swgTVpn7QT SCLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hYWcRb5v8fQ9dl40aHlgxfVdQjCqcgh/5G82dj9XeIQ=; b=LwF9t1PXxe4e3aGCJ/U0UPECxXU5X5/Az/iyWws00aiW6LP2ukjuxOxa6PmJSA3hDo TZbUzJugfY2fciNCFjE74yShcHZbjHRGHKGDIKmlE8xCco5CL3D1uH86QMO/zx3orpZp i4RxC/L7Oi2hKv5TB965ZYhYcgGr+uNH9K45CH86amHvpl4SUtcovtjnpX/pGxkbmvg3 gRRv2BMQ/FEhfv83Oy1KO6ajVIzyMjseJ68O5F7kpZrvVo7jpeTeBbx8zze5NckBbCIF riq50wdq/WcnCArJ2/Iay2HDfD/ogAR0wAuV+DK1zztZqghAHaK2GYV5J1Y9XssB2eCq ts1A==
X-Gm-Message-State: APjAAAUrcr7LfH4NDrHX9Y9ijPZBK+AKpgG27rXv6WxOOx5CH3DIe+MN gKPEQp1ohNIZYLY/Ea5JYxDWR7YcfPDPJ5pbJng=
X-Google-Smtp-Source: APXvYqy3ToYCBg76DlKO/iJ7gGMnimSRbz1lK0HjLmQ5p4nsbzmHFFGqzgMdI2NuFCbUrToFuENWE6Gh//MDjiaoN00=
X-Received: by 2002:a05:6638:28d:: with SMTP id c13mr8156169jaq.11.1572974153324; Tue, 05 Nov 2019 09:15:53 -0800 (PST)
MIME-Version: 1.0
References: <CALZ3u+Yd3wu3G2o-AJErNw6SSgU97F-osJfJhYaiuu5Sb9sF6g@mail.gmail.com>
In-Reply-To: <CALZ3u+Yd3wu3G2o-AJErNw6SSgU97F-osJfJhYaiuu5Sb9sF6g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 05 Nov 2019 09:15:27 -0800
Message-ID: <CA+9kkMAbwCTfMb8Z-meqjuuqSGqR+E9OOe8EF1QpeTwAQj4ktA@mail.gmail.com>
To: Töma Gavrichenkov <ximaera@gmail.com>
Cc: masque@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a65da405969c95ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/ZaNXbq4anEFjyvVsCdzcNFbLC6Y>
Subject: Re: [Masque] MASQUE detection through tracking trackers
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 17:15:57 -0000

Hi Töma,

A couple of questions in-line.

On Tue, Nov 5, 2019 at 8:50 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:

> Peace,
>
> A good friend of mine has been talking recently to a DPI vendor sales
> folk.  Their appliance earned some good results in a testbed environment
> involving weekly packet captures from an actual Internet access provider.
> The particular brand is not important.
>
> Basically their product works as follows.  First, it has a collection of
> IP addresses and some behavioral patterns of an order of hundreds to
> thousands of typical external resources Web sites use: CDNs, trackers
> (Google Analytics, Newrelic, JQuery, Recaptcha, to name a few, but there
> are more), etc.  The list is meant to be being updated once in a few days
> if not hours.
>
> Then, if a client establishes a number of active bandwidth-heavy
> connections to remote servers but doesn't connect to a statistically
> significant number of those trackers within some timeframe (the thresholds
> are also being regularly updated I think), then it assumed to be using a
> VPN.  All the established sessions (no matter if it's TCP or UDP) are
> dropped and the former endpoints (except some) are greylisted and reported,
> and the subsequent HTTP[S] connection establishment attempts get a redirect
> to a Web page which tells the user to switch off the VPN connection.
>

You included HTTP(S) in the "redirect to a web page" here, but it's not
clear why the client connection would continue far enough to display a web
page, given the usual protections associated with TLS.  Is the device
deployed in contexts where the clients have something like an enterprise
root certificate?


>
> The story: test runs have shown that false positives account for much less
> than 1% of the users, those mostly being the ones using self-hosted NASes
> and/or NoScript-enabled browsers.  Evidently, NoScript is not only
> unpopular but most of said browsers are run by people who connect through
> VPNs anyway, therefore further limiting potential false positives.
>
> Any idea if this is being sold/deployed in Europe?  Because it looks like
it amounts to "you must disclose your data to 3rd party trackers" to access
unrelated resources.   I'm hardly a GDPR expert, but it seems surprising to
me that they could require that particular signal be present to permit
connections.


>
The vendor claims they don't look into DNS payload and analyse TLS
> parameters only marginally, and solution is therefore fully DoH and ESNI
> ready.  As far as I know, DoH- and ESNI-secured conversations were not
> present in the test data set.  I haven't seen the box myself..
>
> I wonder now how such a scenario would be considered in MASQUE and if
> there's a way to work around this issue within the MASQUE deployment
> guidelines.
>
>
>From section 7.1:

   While MASQUE ensures that proxied traffic appears similar to regular
   HTTP traffic, it doesn't inherently defeat traffic analysis.
   However, the fact that MASQUE leverages QUIC allows it to segment
   STREAM frames over multiple packets and add PADDING frames to change
   the observable characteristics of its encrypted traffic.  The exact
   details of how to change traffic patterns to defeat traffic analysis
   is considered an open research question and is out of scope for this
   document.


The box you've described is fundamentally a traffic analysis tool.  From
the business perspective, it's likely a subscription service (since you
have to have fresh data models to compare new traffic against), but as a
tool it's not very different from a bunch of other traffic inspection tools
already out there.

(Not speaking for anyone here).

Ted

--
> Töma
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>