Re: [Masque] MASQUE detection through tracking trackers

[Ted Hardie <[e-mail]>]

Hi Töma,

A couple of questions in-line.

On Tue, Nov 5, 2019 at 8:50 AM Töma Gavrichenkov <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>