On Thu, Aug 13, 2020 at 01:04:48PM -0700, Carrick Bartle wrote:
> 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.
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 wrote:
>
> On Fri, Aug 07, 2020 at 05:56:30PM -0600, David Fifield wrote:
>> Most of the functions of the Great Firewall work bidirectionally, and
>> the ESNI
On Fri, Aug 07, 2020 at 05:56:30PM -0600, David Fifield wrote:
> 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
On Wed, Aug 12, 2020 at 06:51:48AM +, Peter Gutmann wrote:
> David Fifield 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
On Tue, Aug 11, 2020 at 11:52 PM Peter Gutmann
wrote:
> ... 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
David Fifield 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
On Tue, Aug 11, 2020 at 11:09 PM Peter Gutmann
wrote:
> Rob Sayre writes:
>
> >I'm confused. That seems to be a bunch of boilerplate surrounding a Salon
> >article from 2015:
>
> I just took the first Google result that seems to cover the material...
>
OK.
> >It also contains references to
Rob Sayre writes:
>I'm confused. That seems to be a bunch of boilerplate surrounding a Salon
>article from 2015:
I just took the first Google result that seems to cover the material...
>It also contains references to supplementary material, like whether
>Intelligent Design can be linked to
On Tue, Aug 11, 2020 at 3:42 PM David Fifield wrote:
> 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
On Tue, Aug 11, 2020 at 01:38:50AM -0700, Rob Sayre wrote:
> On Tue, Aug 11, 2020 at 12:14 AM Peter Gutmann
>
> 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
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
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/
>
On Tue, Aug 11, 2020 at 12:14 AM Peter Gutmann
wrote:
>
> 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.
I'm
Christian Huitema 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
On 8/10/2020 11:49 PM, Christian Huitema wrote:
> On 8/10/2020 11:14 PM, Rob Sayre wrote:
>> On Mon, Aug 10, 2020 at 10:58 PM Peter Gutmann
>> mailto:pgut...@cs.auckland.ac.nz>> wrote:
>>
>> Rob Sayre mailto:say...@gmail.com>> writes:
>>
>> >Do you think this fingerprinting will work with
On Mon, Aug 10, 2020 at 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
On 8/10/2020 11:14 PM, Rob Sayre wrote:
> On Mon, Aug 10, 2020 at 10:58 PM Peter Gutmann
> mailto:pgut...@cs.auckland.ac.nz>> wrote:
>
> Rob Sayre mailto:say...@gmail.com>> writes:
>
> >Do you think this fingerprinting will work with the newer ECH
> design, if the
> >client can
On Mon, Aug 10, 2020 at 10:58 PM Peter Gutmann
wrote:
> Rob Sayre 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
>
Rob Sayre 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.
On Mon, Aug 10, 2020 at 10:33 PM Peter Gutmann
wrote:
> Christian Huitema writes:
>
> >Fingerprinting is a real issue but from the reports, this is not what is
> >happening here.
>
> Sure, I was just pointing out that they're using the brute-force approach
> now
> but presumably at some point
Christian Huitema writes:
>Fingerprinting is a real issue but from the reports, this is not what is
>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
On 8/10/2020 9:26 PM, Peter Gutmann wrote:
> Christopher Wood writes:
>
>> 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
Christopher Wood writes:
>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
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Sun, Aug 09, 2020 at 11:15:25PM -0700, Christian Huitema wrote:
>
> On 8/9/2020 8:31 PM, Peter Gutmann wrote:
> > >From the writeups I've seen, what they're blocking is TLS 1.3, not ESNI.
>
> Please check David Fitfield's message above in the thread. The research
> that he quoted is quite
On Sun, Aug 9, 2020, at 8:31 PM, Peter Gutmann wrote:
> >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)
For the benefit of the list, would you mind sharing these
On 8/9/2020 8:31 PM, Peter Gutmann wrote:
> >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
>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
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
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
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
On Thu, Jul 30, 2020 at 03:45:48PM +, 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
On 7/30/2020 8:45 AM, onoketa wrote:
> Hi,
>
> 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
Hi,
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
34 matches
Mail list logo
