Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 references? Thanks, Chris > 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. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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)." 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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
[TLS] Conclusion of the Adoption Call for draft-wang-opsec-tls-proxy-bp
The call for adoption for draft-wang-opsec-tls-proxy-bp has ended. The chairs believe that there is insufficient support and no consensus to adopt this document as a OpSec WG document. During the adoption call there were a number of comments on the document scope and technical details the document describes. Overall, we think these issues need to be addressed before the working group can consider adopting this document. Thanks to everyone who has reviewed the document and provided the feedback. -- SY, Jen Linkova aka Furry ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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. > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 > misunderstood your question the answer would be "N/A". > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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". > > > 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) 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
