Subject: [Masque] MASQUE detection through tracking trackers

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 5 Nov 2019 19:50:08 +0300

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.

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.

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.

--
Töma

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Nov 2019 09:15:27 -0800

Hi Töma,

A couple of questions in-line.

On Tue, Nov 5, 2019 at 8:50 AM Töma Gavrichenkov <[email-masked]> wrote:

> 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.
>

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?

> 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.

> present in the test data set.  I haven't seen the box myself..
>
>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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 5 Nov 2019 20:31:33 +0300

Peace,

On Tue, Nov 5, 2019, 8:15 PM Ted Hardie <[email-masked]> wrote:

> page

No, obviously, this is a captive portal story.  Every page would just
display a TLS error, so the user would have to click through it at some
point to regain access.

> unrelated resources.

I can't say I'm following your point.

Anyhow, the customer base is mostly out of the EU I believe.  Why?

 I'm hardly a GDPR expert

Me too, but I don't see any issues with GDPR.  The vendor does not own a
Web tracker, they only track existing ones.

> From section 7.1:

Yup, have read it.  PADDING frames won't help here.  A tracker may even not
be running over QUIC.  I, for one, have no idea when e.g. NewRelic is going
to adopt it.

--
Töma

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Nov 2019 10:13:11 -0800

Hi Töma,

Replies in-line.
On Tue, Nov 5, 2019 at 9:31 AM Töma Gavrichenkov <[email-masked]> wrote:

> Okay, so any system not configured to allow that just hard fails.
Understood.

>
>
>>> 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.
>>
>
> Again, I am not expert here, so my presumption may well be wrong.  But if
I understand the system correctly, a client which does not consent to using
the trackers (like the NoScript user) is prevented from accessing
anything.  The network deploying the device thus seems to be requiring
disclosure of information to use its service, even though what it is
collecting is signal from the data rather than the data itself.

The regulations require that when "data is collected, data subjects must be
clearly informed <https://en.wikipedia.org/wiki/Privacy_policy> about the
extent of data collection, the legal basis for processing of personal data,
how long data is retained, if data is being transferred to a third-party
and/or outside the EU, and any automated decision-making that is made on a
solely algorithmic <https://en.wikipedia.org/wiki/Algorithm> basis." (from
Wikipedia's summary)  This would seem to run into those requirements (data
collection, 3rd party, algorithmic basis), hence the question about whether
it was sold in Europe.

Interesting that it is mostly EU customers.

>
>
>> From section 7.1:
>>
>
> Yup, have read it.  PADDING frames won't help here.  A tracker may even
> not be running over QUIC.  I, for one, have no idea when e.g. NewRelic is
> going to adopt it.
>

Agreed; I cited it only to point out that it is currently out of scope.
Traffic analysis that includes non-QUIC traffic would be particularly hard
to address in the document anyway.

Thanks again for sending the information,

Ted

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 5 Nov 2019 21:34:40 +0300

Peace,

> Okay, so any system not configured to allow that just hard fails.

Yup.  A typical phone or a laptop isn't.  IDK how the IoT is being
processed, but I assume that's a pretty simple heuristics.

> The regulations require that when "data is collected, data subjects must
> be clearly informed <https://en.wikipedia.org/wiki/Privacy_policy> about
> the extent of data collection, the legal basis for processing of personal
> data, how long data is retained, if data is being transferred to a
> third-party and/or outside the EU, and any automated decision-making that
> is made on a solely algorithmic <https://en.wikipedia.org/wiki/Algorithm>
> basis." (from Wikipedia's summary)
>

IANAL, but the entity doesn't collect the data itself, so might be outta
scope of GDPR.

BTW, GDPR doesn't only work in EU, it works in every place on Earth where
an EU citizen could land.

> Interesting that it is mostly EU customers.

Argh!  My bad, that was an occasional ambiguity due to phone keyboard
suggestions.  No, the customers are outSIDE of EU.  Most of them, I assume.

> to address in the document anyway.

Too bad.  A dumb traffic analysis might be out of scope, but a complex
traffic analysis might render VPN research senseless.  Who needs a
perfectly secure communication protocol which could be easily detected and
blocked.

--
Töma

---

From: Nick Harper <[email-masked]>
Date: Tue, 5 Nov 2019 11:32:02 -0800

On Tue, Nov 5, 2019 at 10:35 Töma Gavrichenkov <[email-masked]> wrote:

>> Okay, so any system not configured to allow that just hard fails..
>> Understood.
>>
>
> Yup.  A typical phone or a laptop isn't..  IDK how the IoT is being

Depending on the domain, a typical laptop or phone is configured to hard
fail: TLS errors on domains that use HSTS (whether preloaded or sent via an
HTTP header) are non bypassable.

> blocked..

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 5 Nov 2019 23:22:34 +0300

Peace,

> HTTP header) are non bypassable.

In theory, there is no difference between theory and practice.  In practice
there is.  People know captive portals are invasive, but they accept the
risk.

Anyhow, this is not really relevant to the topic.  The access is blocked
anyway, you can just recall some Web site w/o HSTS to click through the
warning to figure out what is it that the network wants from you.  Maybe in
future versions they will implement RFC 7710.  I'm surprised, kind of, that
this is apparently the most interesting part of the message.

--
Töma

---

From: David Schinazi <[email-masked]>
Date: Tue, 5 Nov 2019 12:49:02 -0800

Hi Töma,

Thanks for bringing this to the list! I really feel like this kind of
traffic analysis is going to be hard to work around.
I'm setting the tracking/GDPR and TLS conversations aside because I don't
think they're integral to the attack here.
The fundamental issue is that in today's Web, if I browse a random website,
my browser will not only connect to the
hostname in the URL bar, but it'll also make many other connections - those
could be trackers but also CDN-hosted
images, JavaScript libraries, etc. So a connection to a random website that
is not accompanied by these sidecar
requests is going to stick out. I think we may want to discuss this in the
MASQUE draft, and mention that clients
should attempt to get a list of these common sidecars, and make decoy
sidecar requests when bringing up the
MASQUE tunnel. At the end of the day, traffic analysis evasion is an arms
race, and there's no way around that.
The MASQUE document should discuss these attacks and perhaps give guidance,
but I think ultimately we'll
need MASQUE implementors to keep innovating in these counter-measures, just
like middleboxes are innovating
in their traffic analysis techniques.

Thanks,
David

On Tue, Nov 5, 2019 at 12:22 PM Töma Gavrichenkov <[email-masked]> wrote:

> In theory, there is no difference between theory and practice.  In
> practice there is.  People know captive portals are invasive, but they
> accept the risk.
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 5 Nov 2019 16:08:08 -0500

I think this topic is fascinating and important, but I support keeping it
out of scope for MASQUE.  The countermeasures you've mentioned are, I
think, largely separable from the MASQUE protocol, and MASQUE is a
challenging enough problem already.

If we want to consider the metadata revealed by the client's pattern of
connections, I think that should go in a different draft, and perhaps a
different working group.  It should also be informed by empirical and
theoretical research that we haven't done.

I do think this is a good reminder that we should keep MASQUE flexible
enough to enable research and experimentation.  For example, it might be
worth reviewing how well MASQUE supports connection migration and load
spreading, to reduce the emphasis on a single proxy IP.

On Tue, Nov 5, 2019 at 3:49 PM David Schinazi <[email-masked]>
wrote:

> The fundamental issue is that in today's Web, if I browse a random
> website, my browser will not only connect to the
> hostname in the URL bar, but it'll also make many other connections -
> those could be trackers but also CDN-hosted
> images, JavaScript libraries, etc. So a connection to a random website
> that is not accompanied by these sidecar
> The MASQUE document should discuss these attacks and perhaps give
> guidance, but I think ultimately we'll
> need MASQUE implementors to keep innovating in these counter-measures,
> just like middleboxes are innovating

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 6 Nov 2019 00:19:33 +0300

Peace,

> traffic analysis is going to be hard to work around.

Sure.  I volunteer to work on this if I won't be the only one to.

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 6 Nov 2019 00:22:39 +0300

Peace,

> challenging enough problem already.

I strongly believe personally that MASQUE has to seriously consider this at
least in the security considerations section in order to succeed.

But, you're right, that might be a broader scope overall.  Secdispatch,
maybe, or even IRTF, though that might take so long that the solution will
finally be irrelevant.

--
Töma

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 5 Nov 2019 21:28:47 +0000

This is indeed quite interesting, thanks for sharing. Initially I was in
the camp of Ted, David and Ben but then I asked myself the question in a
different way. If the prevalent use-case for MASQUE is to be
indistinguishable from HTTPS (to an unauthed observer) then your traffic
patterns have to match common HTTPS flows. Consider web browsing, video
streaming and APIs.

Arguably the only one of those three that has long-lived high-traffic
traffic patterns in a single connection (like you might see in a VPN-like
connection) is video and sadly the number of legitimate video streaming
services is easy to enumerate*.

The mention of padding to mitigate timing analysis feeds into the above
behavior, rather than resembling bursty web-like traffic.

Trying to solve such problems is probably out of scope I agree. But the
question I ask is, is MAQUE's premise trivial defeated in deployment
reality?

Lucas

* be also aware that legitimate streaming services have also value in being
enumerated

On Tue, 5 Nov 2019, 21:08 Ben Schwartz, <bemasc=[email-masked]>
wrote:

>> requests is going to stick out. I think we may want to discuss this in
>> the MASQUE draft, and mention that clients
>>>> Depending on the domain, a typical laptop or phone is configured to
>>>> hard fail: TLS errors on domains that use HSTS (whether preloaded or sent
>>>> via an HTTP header) are non bypassable.
>>>>
>>>

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 6 Nov 2019 00:32:23 +0300

Peace,

On Tue, Nov 5, 2019, 8:15 PM Ted Hardie <[email-masked]> wrote:

> the business perspective, it's likely a subscription service
>

I skipped that before, yet I think I have to say this: in the today's
world, every DPI middlebox (worth ordering by whoever willing to make any
profit on top of that) has this subscription service.  As has been rightly
pointed out in this thread before, this is now an arms race, and we should
expect the device to be updated on a weekly basis at least, and every maybe
other hour at worst, or even worse.

--
Töma

---

From: Töma Gavrichenkov <[email-masked]>
Date: Wed, 6 Nov 2019 01:08:06 +0300

Peace,

> services is easy to enumerate*.

Also gaming.  Your concern still applies though, and even more: gaming
protocols usually don't give a flying flamingo about the issues of privacy
and detectability.

Quite the opposite actually: those are *usually* designed to be very easy
to track, b/c their authors want the protocol to be easily RSVP'd through
Mikrotiks et cetera.  The same might be true for some video streaming.

--
Töma

---

From: Christian Huitema <[email-masked]>
Date: Tue, 5 Nov 2019 15:55:40 -0800

On 11/5/2019 1:32 PM, Töma Gavrichenkov wrote:

>
> On Tue, Nov 5, 2019, 8:15 PM Ted Hardie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The box you've described is fundamentally a traffic analysis
>     tool.  From the business perspective, it's likely a subscription
>     service
>
>
> world, every DPI middlebox (worth ordering by whoever willing to make
> any profit on top of that) has this subscription service.  As has been
> rightly pointed out in this thread before, this is now an arms race,
> and we should expect the device to be updated on a weekly basis at
> least, and every maybe other hour at worst, or even worse.

It is an interesting topic, quickly delving into "spy vs spy" territory.
The general idea of the "stealth VPN" is to mimic the traffic of some
applications that are known to pass through the firewalls. The general
idea of the "network censor" is to find ways to distinguish the traffic
they want to allow from the traffic they want to block without
generating too many false positive. That game can go on for a long time,
with progress in detection matched over time by progress in stealth, and
vice-versa. This is similar to what happens with viruses that are being
tested against anti-virus software, and then anti-virus software that
are updated to catch the latest viruses, a "game" that has been going on
for at least two decades.

I don't think that the IETF can play that game, not when it takes more
than 3 years to produce a standard. The IRTF can play a role, and PEARG
would be a good place to publicize knowledge about censorship
techniques. But even the IRTF is probably too slow for the tit-for-tat
game. What the IETF might do, on the other hand, is to take requirements
from stealth designers on desired features of protocols. Not so much
actual stealth features, although it is clearly desirable to avoid
making Masque to easy to recognize. I am more thinking of features like
a padding API or cover traffic API that might then be used by the
stealth designers.

-- Christian Huitema

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Nov 2019 12:44:15 +0000

On Tue, Nov 5, 2019 at 11:56 PM Christian Huitema <[email-masked]>
wrote:

> I am more thinking of features like a padding API or cover traffic API
> that might then be used by the stealth designers.
>

+1

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Nov 2019 13:44:01 +0000

Hiya,

> Sure.  I volunteer to work on this if I won't be the only one to.

Me too, (though perhaps feebly;-)

In terms of venue, I agree with Christian that pearg seems
like it'd be a good home for related work at least up to
the point where someone had a proposal for an IETF WG or
some such. (Which I can't see happening that soon.)

As to the meat of the topic, in addition to what's already
been said, we could also try to influence the baseline set
of traffic patterns, e.g. by encouraging browser makers to
embed and enable-by-default behaviours that result in
traffic patterns closer to those currently seen for happy
NoScript users (like me:-). To some extent, that's slowly
starting to happen already, but I could imagine something
like a BCP asserting that IETF protocol development ought
try minimise the extent to which use of our protocols
enables traffic analysis based attacks or profiling. (I
suspect we could write that text now but that we need more
research done before it'd be more than a "best aspirational
practice";-)

Cheers,
S.

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 7 Nov 2019 22:18:15 +0000

> starting to happen already, but I could imagine something

I no longer use NoScript, having since switched to uMatrix
and hence apart from generally running sans js, also w/o
referencing most external "resources".

As to defaults, I noticed when setting up an iPhone that Safari
defaulted to having javascript disabled, and have had no
need to alter that.  Given that the option is/was under an
"advanced" area, I wonder how many normal users leave it
disabled?

DF