Subject: Re: [TLS] Possible blocking of Encrypted SNI extension in China

From: David Fifield <[email-masked]>
Date: Fri, 7 Aug 2020 17:56:30 -0600

On Thu, Jul 30, 2020 at 03:45:48PM +0000, onoketa wrote:
> The Great Firewall of China may have identified and blocked
> Cloudflare's ESNI implementation.
> 
> I have found that when using a TLS client hello with ESNI extension to
> connect to servers behind Cloudflare's CDN, the connection will be cut
> off after the whole TLS handshake is done. And then that IP address
> will be blocked at the TCP level for several minutes.

There is now a detailed written report on the new phenomenon of ESNI
blocking in China. It was produced by a collaboration of researchers
from Geneva (https://censorship.ai/), GFW Report (https://gfw.report/),
and iYouPort (https://www.iyouport.org/).

https://geneva.cs.umd.edu/posts/china-censors-esni/esni/    (English)
https://geneva.cs.umd.edu/zh/posts/china-censors-esni/esni/ (Chinese)

Here are some of the points most likely to be of interest to this group:
 * The detector is not merely matching on the lack of plaintext SNI; it
   is specifically looking for the ESNI extension 0xffce.
 * The ESNI detector only matches the ESNI encrypted_server_name
   extension 0xffce (draft-ietf-tls-esni-00 through -06), not the ECH
   extensions encrypted_client_hello 0xff02, ech_nonce 0xff03,
   outer_extension 0xff04 (draft-ietf-tls-esni-07).
 * The encrypted_server_name extension has to be syntactically correct;
   the detector is not just looking for the byte patter ff cc.
 * Once an ESNI-containing ClientHello is detected, the firewall drops
   packets in the client→server direction for 120 or 180 seconds.
 * The detector runs on all TCP ports, not just 443.

This short payload is sufficient to trigger blocking:
	160303003b0100003703035b72616e646f6d72616e646f6d72616e646f6d7261
	6e646f6d72616e646f6d5d0000000100000effce000a53754772000000000000
Python code to generate this payload is appended to this message.

Most of the functions of the Great Firewall work bidirectionally, and
the ESNI detection and blocking are no exception. Sending an
ESNI-containing ClientHello from *outside* of China to a server
*inside* results in temporary blocking, just the same as sending one
from the inside to the outside. This makes it easy to experiment with,
even if you don't control a host in China.

To experience ESNI blocking for yourself, choose a responsive TCP port
in China (doesn't have to be port 443), for example
www.tsinghua.edu.cn:80. Begin a TCP ping to the port, for example using
one of these commands:
	hping3 -S www.tsinghua.edu.cn -p 80
	nping -4 -c 0 --tcp-connect www.tsinghua.edu.cn -p 80
Then send the trigger payload:
	printf '\x16\x03\x03\x00\x3b\x01\x00\x00\x37\x03\x03[randomrandomrandomrandomrandom]\x00\x00\x00\x01\x00\x00\x0e\xff\xce\x00\nSuGr\x00\x00\x00\x00\x00\x00' | nc -4 -v www.tsinghua.edu.cn 80
The TCP pings will stop receiving replies for 120 or 180 seconds, then
will start back up again.

----

#!/usr/bin/env python3

# Generates a small TLS ClientHello that trigger's the GFW's ESNI detector.
# Writes output to the file minimal.bin.

import struct

from scapy.all import *
load_layer("tls")
from scapy.layers.tls.all import *

# https://tools.ietf.org/html/rfc8446#section-3.4
def var(ceiling, data):
    if ceiling < 256:
        fmt = ">B"
    elif ceiling < 65536:
        fmt = ">H"
    else:
        raise ValueError(ceiling)
    return struct.pack(fmt, len(data)) + data

# https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-01#section-5
def encrypted_server_name(suite, group, key_exchange, record_digest, encrypted_sni):
    return struct.pack(">HH", suite, group) \
        + var(65535, key_exchange) \
        + var(65535, record_digest) \
        + var(65535, encrypted_sni)

clienthello = TLS(
    msg = TLSClientHello(
        gmt_unix_time = 0x5b72616e, # "[ran"
        random_bytes = b"domrandomrandomrandomrandom]",
        ciphers = [],
        ext = [
            # The GFW detector requires a syntactically valid
            # server_name_extension, but the actual values it contains may be
            # nonsense. Here we use a CipherSuite of 0x5375 ("Su"), a NamedGroup
            # of 0x4772 ("Gr"), and zero-length key_exchange, record_digest, and
            # encrypted_sni.
            TLS_Ext_Unknown(type=0xffce, val=encrypted_server_name(0x5375, 0x4772, b"", b"", b"")),
        ],
    )
)

TLS(bytes(clienthello)).show()
print(bytes(clienthello))

FILENAME = "minimal.bin"
open(FILENAME, "wb").write(bytes(clienthello))
print("output written to {}".format(FILENAME))

---

From: David Fifield <[email-masked]>
Date: Sun, 9 Aug 2020 09:35:26 -0600

On Thu, Jul 30, 2020 at 11:16:50AM -0700, Christian Huitema wrote:
> Thanks for the report. I think this relates to our ambivalence about the
> requirement for ESNI to not "stick out". That requirement is hard to
> meet, and designs have drifted towards an acceptation that it is OK to
> stick out as long as a sufficiently large share of the traffic does it.
> If that share is large, goes the reasoning, it would be too costly for
> censors to just "drop everything that looks like ESNI". Well, given
> actors like the Great Firewall, one wonders.

There's nothing wrong with that reasoning, in my opinion. To blend in
with a crowd, you can change yourself to match the crowd; or you can
change the crowd to match yourself. My feeling is that ESNI is currently
easy to block (or to put it in terms I like, *inexpensive* to block)
because very few TLS connections use it--nothing valuable depends on it
yet. Whereas if encrypted SNI were somehow deployed suddenly and
massively such that it became a normal feature of TLS connections both
essential and inessential, it would be more difficult (read: expensive)
to block.

After all, even the GFW is not all-powerful. Surely it would prefer to
abolish TLS altogether, but it's too late for that. At this point,
blocking TLS would cost too much--not in terms of implementing firewall
rules, but in how much essential communication it would damage. Put
another way, the GFW itself, and the people who operate/manage it, would
feel some of the pain of blocking.

I don't mean to imply that coordinated deployment is the only path to
success, just saying that if SNI encryption were already widespread,
even an obvious tag like 0xffce would not be a useful distinguisher. And
though I find it useful to think of these things in terms of the costs
of overblocking, it's not an infallible guide. A large organization like
the GFW is made up of many conflicting motivations, and it is as prone
as any other to making bad decisions and enacting policies that are
evidently against its own interests. For that reason I believe it's
possible to reduce the risk surrounding the deployment of encrypted SNI,
but not eliminate it completely.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 9 Aug 2020 17:09:49 +0000

I’m pretty sure your reasoning is wrong. In the ideal world, if *everybody* enabled ESNI - then *maybe* the GFW would relent. 

The way things are - is not smart pretending reality is not what it is. 

Using your terminology - better blend with the crowd, because you aren’t likely to live long enough to see the crowd change to match you. 

There are a lot of technical details why the whole crowd won’t change regardless of your wishes - e.g., who controls TLS implementations in various devices - but I won’t go there. 

Regards,
Uri

> On Aug 9, 2020, at 11:36, David Fifield <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Dmitry Belyavsky <[email-masked]>
Date: Sun, 9 Aug 2020 23:00:27 +0300

I just want to remind you about my FakeSNI draft

https://tools.ietf.org/html/draft-belyavskiy-fakesni-02

The idea behind it was cheating the solutions less sophisticated than GFW.
Yes, in real life it will require deep cooperation between DNS and hosting
and yes, the resource still can be blocked by IP (with all collateral
damage).

On Sun, Aug 9, 2020 at 8:15 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> I’m pretty sure your reasoning is wrong. In the ideal world, if
> *everybody* enabled ESNI - then *maybe* the GFW would relent.
>
> Using your terminology - better blend with the crowd, because you aren’t
> likely to live long enough to see the crowd change to match you.
>
> There are a lot of technical details why the whole crowd won’t change
> regardless of your wishes - e.g., who controls TLS implementations in
> various devices - but I won’t go there.
>
> Regards,
> Uri
>

-- 
SY, Dmitry Belyavsky

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 10 Aug 2020 03:31:45 +0000

>From the writeups I've seen, what they're blocking is TLS 1.3, not ESNI.
Since ESNI can be de-anonymised with a high degree of success (see various
conference papers on this) and in any case doesn't matter for the most
frequently-blocked sites like Facebook, Instagram, Twitter, etc, it may not
even be on the GFW's radar.  My guess is that the GFW doesn't have a fast-path
mechanism for TLS 1.3 so as 1.3 use grows it's being overwhelmed, therefore
they're blocking it until they can upgrade their hardware.  The fact that ESNI
is also affected is just a coincidence of the blocking of 1.3.

Peter.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 9 Aug 2020 23:15:25 -0700

> is also affected is just a coincidence of the blocking of 1.3.

Please check David Fitfield's message above in the thread. The research
that he quoted is quite specific, "The ESNI detector only matches the
ESNI encrypted_server_name extension 0xffce (draft-ietf-tls-esni-00
through -06), not the ECH extensions encrypted_client_hello 0xff02,
ech_nonce 0xff03, outer_extension 0xff04 (draft-ietf-tls-esni-07)."

-- Christian Huitema

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 10 Aug 2020 07:45:25 -0700

On Sun, Aug 9, 2020, at 8:31 PM, Peter Gutmann wrote:
> conference papers on this) 

For the benefit of the list, would you mind sharing these references?

Thanks,
Chris

> and in any case doesn't matter for the most

---

From: David Fifield <[email-masked]>
Date: Mon, 10 Aug 2020 10:19:32 -0600

> ech_nonce 0xff03, outer_extension 0xff04 (draft-ietf-tls-esni-07)."

That's right. The block is specifically against ESNI, not all TLS 1.3.
There is still a minor open question on the issue of ECH extensions
specifically (0xff02, 0xff03, 0xff04). When we tested ECH, we did not
try syntactically well-formed extension values, which proved to be
necessary in the case of ESNI, since the GFW's detector has at least a
rudimentary TLS parser. This leaves open the possibility that a
ClientHello with well-formed ECH extensions would also trigger a block:
https://github.com/net4people/bbs/issues/43#issuecomment-670794117

TLS 1.3 without SNI, ESNI, ECH	not blocked
TLS 1.3 with SNI only		not blocked
TLS 1.3 with ESNI only		blocked
TLS 1.3 with ECH only		still uncertain

The vast majority, I'm sure, of today's TLS 1.3 connections are
unaffected by the GFW's new block, because they do not use ESNI.
(Personally, I argue that it is *because* ESNI is not yet widely used
that it can be effectively blocked now.)

The bidirectional nature of the GFW makes it easy to test blocking
hypotheses, following the instructions at
https://mailarchive.ietf.org/arch/msg/tls/Dae-cukKMqfzmTT4Ksh1Bzlx7ws/.
One can try the 64-byte payload given there, or modify it to remove the
0xffce marker. To capture your own genuine ESNI ClientHello, use
Firefox 68 or later and change these settings in about:config:
	network.security.esni.enabled=true
	network.trr.mode=3
	network.trr.uri=https://mozilla.cloudflare-dns.com/dns-query
	network.trr.bootstrapAddress=104.16.249.249
Then visit an ESNI-capable web site. A convenient choice is
https://www.cloudflare.com/cdn-cgi/trace because it has a
"sni=encrypted" or "sni=plaintext" diagnostic.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 10 Aug 2020 16:25:42 +0000

David, thanks for the detailed note.

I just want to confirm that we haven't seen plain TLS 1.3 blocked either.  We use it for our server-server traffic.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Aug 2020 04:26:16 +0000

>For the benefit of the list, would you mind sharing these references?

I handwaved this one because I don't catalogue these things and didn't want to
try and re-locate every preprint, paper, and report that's drifted across my
desk in the last 6-12 months to try and find the relevant stuff... a recent
one that I remember because it was published just a few days ago at Usenix
Security after existing as an arXiv preprint for over a year, that's not ESNI
but eDNS so almost the same thing, was "Padding Ain't Enough: Assessing the
Privacy Guarantees of Encrypted DNS" which reports, and references other
papers which report, an 80-90% success rate in de-anonymising encrypted DNS.
The ESNI de-anonymisation is the standard web-site fingerprinting that's been
used in the past to e.g. find people's incomes based on their encrypted
traffic to tax filing sites.  In other words it doesn't care whether ESNI is
used or not since it doesn't use it.

Peter.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Aug 2020 21:51:56 -0700

> used or not since it doesn't use it.

Fingerprinting is a real issue but from the reports, this is not what is
happening here. The researcher's experiments isolate a simple pattern
matching technique applied to the first client flight.

-- Christian Huitema

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Aug 2020 05:32:46 +0000

Christian Huitema <[email-masked]> writes:

>happening here.

Sure, I was just pointing out that they're using the brute-force approach now
but presumably at some point will stop blocking when they've implemented a way
to bypass it.  My guess is that since the GFW uses blocklisting (of known
sites/pages) all they'll need to do is fingerprint the sites they want to
block and take it from there.  Stuff like the ConceptDoppler work
("ConceptDoppler: A Weather Tracker for Internet Censorship" out of UC Davis -
that was one paper I do remember :-) showed that they don't try and block
everything but just enough to let you know it's happening and they're watching
you, which the fingerprinting approach is fine for.

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 10 Aug 2020 22:41:50 -0700

On Mon, Aug 10, 2020 at 10:33 PM Peter Gutmann <[email-masked]>
wrote:

> block and take it from there.
>

Do you think this fingerprinting will work with the newer ECH design, if
the client can add arbitrary content to the encrypted payload?

Another technique to use here: deploy servers that refuse unencrypted
ClientHello messages.

thanks,
Rob

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Aug 2020 05:58:04 +0000

Rob Sayre <[email-masked]> writes:

>Do you think this fingerprinting will work with the newer ECH design, if the
>client can add arbitrary content to the encrypted payload?

ECH doesn't have any effect on web site fingerprinting so unless I've
misunderstood your question the answer would be "N/A".

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 10 Aug 2020 23:14:02 -0700

On Mon, Aug 10, 2020 at 10:58 PM Peter Gutmann <[email-masked]>
wrote:

> the

Assuming the definition here:
https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00

it does seem like ECH would make this more difficult, at least for pages in
a large anonymity set. (agree that it won't matter much for Twitter,
Google, et al)

thanks,
Rob

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Aug 2020 23:49:23 -0700

On 8/10/2020 11:14 PM, Rob Sayre wrote:
> On Mon, Aug 10, 2020 at 10:58 PM Peter Gutmann
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Rob Sayre <[email-masked] <mailto:[email-masked]>> writes:
>
> it does seem like ECH would make this more difficult, at least for
> pages in a large anonymity set. (agree that it won't matter much for
> Twitter, Google, et al)

Defeating fingerprinting is really hard. It has been tried in the past,
as in "make me look like Skype" or "make me look like wikipedia". The
idea is to build a target model, then inject enough noise and padding in
your traffic to match the target model. But that way easier to say than
to do!

-- Christian Huitema

---

From: Rob Sayre <[email-masked]>
Date: Tue, 11 Aug 2020 00:06:54 -0700

On Mon, Aug 10, 2020 at 11:49 PM Christian Huitema <[email-masked]>
wrote:

> Defeating fingerprinting is really hard. It has been tried in the past, as
> in "make me look like Skype" or "make me look like wikipedia". The idea is
> to build a target model, then inject enough noise and padding in your
> traffic to match the target model. But that way easier to say than to do!
>
Some of the techniques do attempt something like that. For example:

"Wright et al. [wright2009traffic] developed traffic morphing, which pads
packets in such a way so as to make the sequence from one page have
characteristics of another (non-monitored or benign) page. This technique
requires application-specific knowledge about benign pages and is therefore
best implemented outside of the transport layer."

What I couldn't figure out is how much the cited training mechanisms rely
on the ClientHello message. I haven't found a source that mentioned this
outside of "packet size and timing", but I haven't read them all.

thanks,
Rob

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Aug 2020 00:08:11 -0700

On 8/10/2020 11:49 PM, Christian Huitema wrote:

> Defeating fingerprinting is really hard. It has been tried in the
> past, as in "make me look like Skype" or "make me look like
> wikipedia". The idea is to build a target model, then inject enough
> noise and padding in your traffic to match the target model. But that
> way easier to say than to do!
>

There is also the question of what the anonymity set is. I just did a
little experiment of resolving 25000 domain names and looking at how
many resolved to the same IP address
(https://huitema.wordpress.com/2020/08/09/can-internet-services-hide-in-crowds/).
And then I redid the stats with 50000 domain names. Did not find a lot
of crowds. 75% of domain names in my sample resolve to their very own
address, not shared with anybody. Only 8% resolved by addresses shared
by 10 sites or more, and 1.3% resolved to addresses shared by 100 sites
or more.  Of course, 1% of the Internet is already something big. But
still, not quite the whole world...

-- Christian Huitema

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Aug 2020 07:14:41 +0000

Christian Huitema <[email-masked]> writes:
 
>Defeating fingerprinting is really hard. It has been tried in the past, as in
>"make me look like Skype" or "make me look like wikipedia". The idea is to
>build a target model, then inject enough noise and padding in your traffic to
>match the target model. But that way easier to say than to do!

As Yuri Totrov, a.k.a the shadow director of personnel at the CIA, showed:

https://mindmatters.ai/2018/11/how-the-kgb-found-cia-agents/

the only way to hide A as B is if you become B.  Which means you can't be A
any more.  There was a paper that looked a traffic morphing published a year
or two ago that came to the same conclusion, to look like you're Skype or a
SIP VoIP call you need to actually be Skype or a SIP VoIP call.

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 11 Aug 2020 01:38:50 -0700

On Tue, Aug 11, 2020 at 12:14 AM Peter Gutmann <[email-masked]>
wrote:

> any more.

I'm confused. That seems to be a bunch of boilerplate surrounding a Salon
article from 2015:

https://www.salon.com/2015/09/26/how_to_explain_the_kgbs_amazing_success_identifying_cia_agents_in_the_field/

It also contains references to supplementary material, like whether
Intelligent Design can be linked to information theory:

https://mindmatters.ai/2018/10/does-information-theory-support-design-in-nature/

I am not sure this issue is on topic for this list.

> There was a paper that looked a traffic morphing published a year

You could link it, perhaps.

thanks,
Rob

---

From: David Fifield <[email-masked]>
Date: Tue, 11 Aug 2020 15:31:26 -0600

On Tue, Aug 11, 2020 at 12:08:11AM -0700, Christian Huitema wrote:
> There is also the question of what the anonymity set is. I just did a little
> experiment of resolving 25000 domain names and looking at how many resolved to
> the same IP address (https://huitema.wordpress.com/2020/08/09/
> can-internet-services-hide-in-crowds/). And then I redid the stats with 50000
> domain names. Did not find a lot of crowds. 75% of domain names in my sample
> resolve to their very own address, not shared with anybody. Only 8% resolved by
> addresses shared by 10 sites or more, and 1.3% resolved to addresses shared by
> 100 sites or more.  Of course, 1% of the Internet is already something big. But

Here is a related experiment done last year.

"On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention"
https://censorbib.nymity.ch/#Chai2019a
https://www.usenix.org/conference/foci19/presentation/chai
My capsule summary: https://github.com/net4people/bbs/issues/10

The authors tested an Alexa top 1 million list for blocking from China,
under three different modalities: DNS poisoning, SNI filtering, and IP
address blocking. (The GFW blocked different web sites in different
ways; ESNI is effective against DNS poisoning and SNI filtering but not
IP address blocking.) Of 24,210 domains blocked by either DNS poisoning
or SNI filtering, 16,928 (70%) were additionally blocked by IP address,
so ESNI would not help to unblock them if they remained at their current
hosting. The other 30% of domains would have been unblocked by ESNI.
This analysis, of course, assumes a static situation; if ESNI were
deployed and found to be effective, then blocked sites might choose to
move to shared co-hosting, or the GFW might increase the scope of its IP
address blocking to include addresses with small anonymity sets.

I'll add that it's not just the size of the anonymity set that matters.
The domains that make up the anonymity set, and the cost of blocking
them, matters as well. An anonymity set of 100,000 could still be
blockable if none of the 100,000 is disruptive or costly to block.
(Measure cost however you like: effect on the local economy, for
example.) An anonymity set of size 10 might be hard to block, if just
one of those 10 is one that the would-be blocker greatly cares to
preserve.

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 11 Aug 2020 15:40:21 -0700

It's important to note that the Firefox Nightly client does not implement
GREASE of any form, so only the connections to sites that are known to
support the ESNI could be blocked by this method. These connections
stick out like a sore thumb among connections from this browser since ESNI
is supported by a minority of sites.

If ECH is deployed in a client with GREASE enabled, then every client hello
from the supporting client will contain the ECH extension whether the site
supports ECH or not. The traffic from the supporting user agent would stick
out, but simple filters that check for the presence of specific extensions,
would not be able to differentiate between connections to sites with ECH
enabled and to those without ECH.

On Thu, Jul 30, 2020 at 11:18 AM Christian Huitema <[email-masked]>
wrote:

>
> On 7/30/2020 8:45 AM, onoketa wrote:
> > Hi,
> >

---

From: David Fifield <[email-masked]>
Date: Tue, 11 Aug 2020 16:42:03 -0600

> You could link it, perhaps.

Peter is surely referring to the influential "The Parrot is Dead" paper
from 2013, which found discrepancies in so-called "parrot" systems that
superficially imitate some other cover protocol. The authors recommend
not mere imitation, but tunnelling through a real implementation of the
cover protocol (Section XI).
	"The Parrot is Dead: Observing Unobservable Network Communications"
	https://censorbib.nymity.ch/#Houmansadr2013b
A point of clarification: "The Parrot is Dead" is not about "traffic
morphing" in the restricted sense of Wright et al.
(https://www.freehaven.net/anonbib/#morphing09), which is solely about
shaping packets' sizes, not their contents nor the interpacket timing.

"The Parrot is Dead" is rightly well-regarded, but one should not cite
it without also mentioning some follow-on work, like "Seeing through
Network-Protocol Obfuscation," which found many of the dead-parrot
attacks impractical due to high false-positive rates or easy
remediation. The authors proposed new detection attacks, optimizing for
low false-positive rates and low cost of deployment, in terms of state
and computation.
	"Seeing through Network-Protocol Obfuscation"
	https://censorbib.nymity.ch/#Wang2015a

It is worth noting that, despite these papers' claims of easy detection
of covert protocols, classification attacks of the type they propose are
not really observed in practice. Available evidence indicates that
network intermediaries, when they block, prefer to block using methods
that are simpler and more robust, generally preferring a large number of
false negatives to a small number of false positives. The following
paper takes a contrarian view and proposes more realistic threat models
based on the observed behavior of blockers: see the three "disconnects"
between research and practice in Section I.
	"Towards Grounding Censorship Circumvention in Empiricism"
	https://censorbib.nymity.ch/#Tschantz2016a
As an example, "Seeing through Network-Protocol Obfuscation" was
published in 2015, but none of its proposed attacks (Figure 1) have come
to pass, despite their ≈1.0 true-positive rates and ≈0.0 false-positive
rates. obfs3 was defeated by active probing
(https://censorbib.nymity.ch/#Ensafi2015b); even in China obfs4 is
attacked by enumeration at the proxy distributor, not passive detection;
and meek kept working until it was shut down by the CDNs, not the
network blockers it was intended against. (FTE did not have enough users
to make any strong statements about, I think.)

Attempts to infer information about the contents of an encrypted network
stream based on packet size and timing are usually filed under the term
"website fingerprinting." You'll find many papers with that term in the
title at https://www.freehaven.net/anonbib/. I am not as familiar with
that field, but I understand that a common criticism of website
fingerprinting research is that it may use unrealistic data or
assumptions, such that it's not clear that the results generalize or can
be effectively deployed. (There are echoes of this in Table 8 of "Seeing
through Network-Protocol Obfuscation," which reports a large loss in
accuracy when training and testing across corpora.) For a critical look
at research earlier than 2014, see:
	"A Critical Evaluation of Website Fingerprinting Attacks"
	https://www.freehaven.net/anonbib/#ccs2014-critical

With that said about website fingerprinting, on the topic of inference
using packet sizes, timing, and other metadata, I have been impressed
with this series of articles on inference against TLS and HTTPS, which I
think avoid common missteps:
	"Enhanced telemetry for encrypted threat analytics"
	http://gen.lib.rus.ec/scimag/?q=10.1109%2FICNP.2016.7785325

	"Deciphering Malware's use of TLS (without Decryption)"
	https://arxiv.org/abs/1607.01639

	"Identifying Encrypted Malware Traffic with Contextual Flow Data"
	http://gen.lib.rus.ec/scimag/?q=10.1145%2F2996758.2996768

	"Limitless HTTP in an HTTPS World: Inferring the Semantics of
	the HTTPS Protocol without Decryption"
	http://gen.lib.rus.ec/scimag/?q=10.1145%2F3292006.3300025
	https://www.youtube.com/watch?v=pBVu9GEfE1I&t=80

---

From: Rob Sayre <[email-masked]>
Date: Tue, 11 Aug 2020 16:24:15 -0700

>         http://gen.lib.rus.ec/scimag/?q=10.1109%2FICNP.2016.7785325

Thanks for the links.

This 2016 paper is interesting. Understandably, it doesn't mention a bunch
of newer developments.

Its conclusion ends with:

"We identified features of a flow that can be easily collected, analyzed,
and stored such as
the sequence of packet lengths and times, the byte distribution, and the
TLS handshake
metadata. We showed how these data features can be combined with intuitive
machine
learning models to accurately classify malicious, encrypted network flows."

It seems to me that a lot of these papers studied more predictable packet
sizes than they might get under ECH, and would have less cleartext metadata
available under ECH. Additionally, many of these papers probably used TLS
1.2 or earlier.

thanks,
Rob

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 12 Aug 2020 06:09:48 +0000

>I'm confused. That seems to be a bunch of boilerplate surrounding a Salon

I just took the first Google result that seems to cover the material...

>I am not sure this issue is on topic for this list.

And Salon, which you linked to, has published articles on how vaccines cause
autism.  I'm sure readers will be able to tell the difference between a
discussion of KGB decloaking of CIA assets and anti-vaxxer stories.

>You could link it, perhaps.

See my comments in an earlier post, I don't catalogue every paper and preprint
and draft that comes across my desk...

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 11 Aug 2020 23:48:54 -0700

> I just took the first Google result that seems to cover the material...

OK.

> autism.

You linked to it. As I wrote, the Salon article constitutes the substance
of whatever that other site's article is. There is a large blockquote in
the middle.

> I'm sure readers will be able to tell the difference between a

I am not sure why you linked to this article. Maybe it is a strained
metaphor?

> and draft that comes across my desk...

I don't either... but I try to remember them if I can, and also try to
avoid making vague references.

I've read many of your messages before (I particularly liked "A mighty
fortress is our PKI"), but this traffic does not seem helpful.

thanks,
Rob

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 12 Aug 2020 06:51:48 +0000

David Fifield <[email-masked]> writes:

>Peter is surely referring to the influential "The Parrot is Dead" paper from
>2013

Yep, that was it, thanks (at least one person catalogues their reading by the
looks of it :-).  Thanks for the ref to the followup, can't remember seeing
that, but doesn't that just reinforce the Parrot paper?

The "Grounding Censorship Circumvention in Empiricism" paper is an important
one too, you need to look at what the attackers are doing otherwise you'll end
up throwing a ton of crypto at something that makes no difference.  In
particular in reference to a question someone else asked about ECH and TLS
1.3, since it's not defending against anything the censors are doing I can't
see what its presence or absence would do.  Something like ECH seems like
classic inside-out design, "here is our cool piece of crypto trickery, and
whatever it happens to defend against is the threat".

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 12 Aug 2020 00:03:41 -0700

On Tue, Aug 11, 2020 at 11:52 PM Peter Gutmann <[email-masked]>
wrote:

> ... in reference to a question someone else asked about ECH and TLS

Censors do use the unencrypted SNI. See:
https://tools.ietf.org/id/draft-irtf-pearg-censorship-03.html#sni

That doesn't mean an encrypted ClientHello will solve all of the problems
we've discussed, of course.

That said, most of the linked papers I've read could be possibly-overfit ML
models that study older TLS versions without ECH.

Their underlying point could be correct, but the data is old, and usually
not public or reproducible.

thanks,
Rob

---

From: David Fifield <[email-masked]>
Date: Wed, 12 Aug 2020 10:11:35 -0600

> that, but doesn't that just reinforce the Parrot paper?

Both papers are about detection, but I would not call one a
reinforcement of the other. Section 4 of "Seeing through
Network-Protocol Obfuscation", "Semantics-based attacks," finds problems
in the attacks proposed by "The Parrot is Dead". The authors design new
styles of attack (Section 5, "Entropy-based attacks", and Section 6,
"ML-based attacks") and apply them to deployed covert communications
systems. But of these systems, only one (FTE) is a "parrot" or mimicry
system (see the trichotomy of categories under "Network protocol
obfuscation" in Section 2). obfs3 and obfs4 are randomizing protocols,
not designed to resemble any particular cover protocol, and meek uses
exactly the tunnelling approach advocated in "The Parrot is Dead,"
sending its requests via a headless Firefox for the sake of a proper TLS
fingerprint (Section 5.1 of https://censorbib.nymity.ch/#Fifield2015a).
The results do not really support the thesis that tunnelling is
essential or necessarily more resistant to blocking, though it remains a
good rule of thumb. Both tunnelling-based and non-tunnelling-based
systems are widely used today, with success in practice.

> whatever it happens to defend against is the threat".

Rob is correct. Blocking on the basis of plaintext SNI is common and
extensively empirically documented. It would be unusual, these days, for
a firewall to support DNS, IP address, and HTTP keyword blocking,
without also supporting SNI blocking. A few examples:
https://ooni.org/post/2020-tls-blocking-india/
	We recorded SNI-based blocking on both Bharti Airtel and
	Reliance Jio.
https://ooni.org/post/2020-iran-sni-blocking/
	To evaluate this methodology, we ran experiments in Iran because
	we know that Iran implements SNI based blocking.
https://censorbib.nymity.ch/#Chai2019a Section 4.2
	We detect that 21,446 sites are under SNI filtering in China.
	One interesting observation is that only 70 websites are
	exclusively censored by SNI filtering. In other words, SNI
	filtering is almost always used in a combination with other
	censorship techniques.
https://ooni.org/post/2019-egypt-blocks-bbc-and-alhurra/
	This is quite a strong indication of the presence of some form
	of Deep Packet Inspection (DPI) technology that is aware of TLS
	and which is most likely fingerprinting the SNI field of the TLS
	handshake.
https://censorbib.nymity.ch/#VanderSloot2018a Section 6.4
	Unfortunately, SNI places the domain name in clear-text in the
	first message sent by the client to the server, making it easy
	to detect when a client is connecting to a particular site from
	only the first message in a TLS handshake. We find that networks
	do interfere based on this first message alone.

But you don't have to take anyone's word for it, at least in the case of
the Great Firewall; this is another aspect that's easy to test from
outside. Start a packet capture on port 443 and send a ClientHello,
containing an SNI field known to be blocked, to a responsive HTTPS host
in China. You will immediately receive three RST packets, which are not
sent by the remote server but are injected by the firewall.

$ openssl s_client -connect www.tsinghua.edu.cn:443 -servername www.facebook.com

10:03:30.857872 IP localhost.60084 > www.tsinghua.edu.cn.https: Flags [S], seq 864764526, win 64240, options [mss 1460,sackOK,TS val 2739496015 ecr 0,nop,wscale 7], length 0
10:03:31.188496 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [S.], seq 4063746934, ack 864764527, win 2105, options [mss 1460,nop,wscale 2,sackOK,TS val 202217658 ecr 2739496015], length 0
10:03:31.188555 IP localhost.60084 > www.tsinghua.edu.cn.https: Flags [.], ack 1, win 502, options [nop,nop,TS val 2739496346 ecr 202217658], length 0
10:03:31.189003 IP localhost.60084 > www.tsinghua.edu.cn.https: Flags [P.], seq 1:319, ack 1, win 502, options [nop,nop,TS val 2739496346 ecr 202217658], length 318
10:03:31.508859 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [R.], seq 1, ack 319, win 995, length 0
10:03:31.508907 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [R.], seq 1, ack 319, win 995, length 0
10:03:31.510050 IP www.tsinghua.edu.cn.https > localhost.60084: Flags [R.], seq 1, ack 319, win 995, length 0

---

From: David Fifield <[email-masked]>
Date: Thu, 13 Aug 2020 11:30:02 -0600

> even if you don't control a host in China.

Triggering blocking from the outside no longer works. ESNI connections
that originate inside the firewall are still blocked. This was first
observed by GFW report, who were able to isolate the change from
bidirectionality to unidirectional to a five-minute window: between
06:27 and 06:32 UTC on 2020-08-13. I tried it myself, and I confirm that
I am not now able to trigger ESNI blocking from outside the firewall.
https://github.com/net4people/bbs/issues/43#issuecomment-673322409

---

From: Carrick Bartle <[email-masked]>
Date: Thu, 13 Aug 2020 13:04:48 -0700

Weird. Thanks for the update. How are you confirming that it's blocked from inside-out?

> On Aug 13, 2020, at 10:30 AM, David Fifield <[email-masked]> wrote:
>

---

From: David Fifield <[email-masked]>
Date: Thu, 13 Aug 2020 14:13:06 -0600

> Weird. Thanks for the update. How are you confirming that it's blocked from inside-out?

I couldn't test it myself, so I am relying on the reports of colleagues
in China. GFW Report is able to test directly from China.

Measurement vantage points in China are tricky to get ahold of. A
possible alternative is to use a reflected measurement system in the
style of Quack, which uses infrastructural echo servers:
https://censorbib.nymity.ch/#VanderSloot2018a
https://www.usenix.org/conference/usenixsecurity18/presentation/vandersloot
https://github.com/net4people/bbs/issues/2
Censored Planet does regular Quack measurements, but I don't think they
are testing ESNI yet: https://censoredplanet.org/data/raw