Re: [TLS] ESNI/ECH: minor progress, much githubbery
On Tue, Sep 29, 2020 at 03:55:54PM +0100, Stephen Farrell wrote: > On 29/09/2020 15:50, Christopher Patton wrote: > > > >> Are there OpenSSL / NSS / etc implementations others can work from? > >> Probably the best way to lock this in and ship is to write the code. > >> > > > > There are three implementations I'm aware of, all works in progress: > > > >1. Cloudflare's prototype (written by me): > >https://github.com/cloudflare/go/pull/30 > >2. boringSSL: https://bugs.chromium.org/p/boringssl/issues/detail?id=275 > >3. NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1654332 > > Mine has a readme at [1]. It works fine for draft-02 to > draft-04. Later stuff (draft isn't working yet. As I said > I had parked it for a bit, but am back working on it now. > > [1] https://github.com/sftcd/openssl/tree/master/esnistuff There is also this, implementing draft-05: https://www.tunnelbear.com/blog/tunnelbear-implements-encrypted-sni/ https://boringssl-review.googlesource.com/c/boringssl/+/42644 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 ref to the followup, can't remember seeing > 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. > 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". 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.189
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 to actually be Skype or a SIP VoIP call. > > 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=80 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 5 > 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... 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. ___ 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
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
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 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:
160303003b013703035b72616e646f6d72616e646f6d72616e646f6d7261
6e646f6d72616e646f6d5d00010effce000a53754772
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))
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
On Wed, Feb 20, 2019 at 03:48:18PM -0800, Christian Huitema wrote: > Out of all the requirements listed in the encryption requirements draft, the > requirement to "not stand out" is probably the hardest to comply with. The > current ESNI draft works but usage of ESNI can still be detected. As Dmitri > points out, there are locales where standing out will enable censorship. So, > what to do? Well, if we want to not stand out yet carry some information, > that's pretty much the definition of a hidden channel. > > Would it be possible to engineer a hidden channel in the TLS 1.3 Hello? I bet > that's quite doable. I am sure that fields like "opaque Random[32]" or "opaque > legacy_session_id<0..32>" could be used creatively, and there are other fields > in common extensions that could also be of service. Of course, "could be done" > does not mean that the IETF will want to standardize it. There's prior research on embedding covert signaling into TLS as a means of preventing blocking by middleboxes. The work I'm familiar with is in the field of decoy routing or refraction networking. There's a list of papers at https://refraction.network/ and there's a good survey in Section 2 of https://censorbib.nymity.ch/#Manfredi2018a. Telex (https://censorbib.nymity.ch/#Wustrow2011a) is a good representative example. Omitting some details: A router has a private key r. On a new connection, the client generates a temporary private key s. The client sets the Random field in its Client Hello to g^s || H(g^(rs)) for some hash function H. The server, knowing r, can distinguish this value from random, but other observers cannot. (There are additional tricks to make g^s uniformly distributed.) Lately the research has been less about the specific means of covert signaling, and more about improving security and deployability, for instance by working of asymmetric routes, or requiring only injection and not flow blocking. There's been an ISP-scale deployment of one of the designs, called TapDance: https://censorbib.nymity.ch/#Frolov2017a. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
On Tue, Feb 19, 2019 at 11:04:06PM +0300, Dmitry Belyavsky wrote: > Please take a look at an initial submission of the draft. > The draft describes a Fake SNI mechanism intended to cheat DPI systems in > a case > when a DPI system blocks the connection if ESNI is present. > > -- Forwarded message - > From: > Date: Tue, Feb 19, 2019 at 10:43 PM > Subject: New Version Notification for draft-belyavskiy-fakesni-00.txt > To: Dmitry Belyavskiy > > Abstract: > The document provides a specification of the Fake Server Name > Indication. Being implemented, the Fake SNI specification provides a > way to work around the monitoring solutions without providing any > additional information to external observers. I initially viewed this proposal negatively, but after thinking about it more during Dmitry's talk today (https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-fake-sni-00), I think there are ways in which it can make sense. The reason I initially viewed it negatively was that it seemed to be a naive attempt at addressing the "proxy distribution" problem--where you have to somehow share secret information with your genuine users but not let it fall into the hands of an adversary, with the challenge that you don't have a secure way to distinguish genuine users from an adversary. The draft acknowledges the challenge but, I think, treats it too lightly, as for me it is the core consideration: "DPI solutions are able to obtain the DNS _fakesni records as legitimate clients do." It's the same problem you would face if you were to establish mirror sites to mitigate blocking: how do you inform your users of the mirror sites' URLs without also informing the adversary you're protecting against? Another way way to think about it is: you have a large set of secret tokens, and you want it so that *anyone* can discover one token, but *no one* can discover all the tokens. There's a fair amount of research on secure proxy distribution, but they all work by imposing limits on the adversary, by leveraging trust relationships among genuine users, tying discovery to real-world resources, or some other method. Here is a selection of research: https://censorbib.nymity.ch/#Nasr2019a https://censorbib.nymity.ch/#Douglas2016a https://censorbib.nymity.ch/#Wang2013a https://censorbib.nymity.ch/#McCoy2011a The Fake SNI draft's DNS discovery doesn't impose any significant limits, so if there is only one or a few fake SNIs, I think the idea won't work against an adversary that can afford to do continuous polling, even if the set of fake SNIs is rotated frequently. But if you ensure that each fake SNI value is distributed once and only once, then I think the idea has some merit. Then, it doesn't help an adversary to do its own polling, because any SNIs it discovers will never be used by a legitimate client. It doesn't help if it blocks SNI values that clients have been seen to use, because those values will not be used again. This all assumes trustworthy DNS, so an adversary can't see the SNI you're about to use before you use it. And it also assumes some level of colocation, or else there is nothing to prevent an intermediary from blocking the IP address regardless of SNI. (The same observations apply to ESNI as well as Fake SNI.) However, even with one-time-use fake SNI values, the design still has a problem with replay. The generic attack is described at https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-04#section-3.1. The adversary observes a client using an SNI value, then makes its own connection to the same server using the same SNI value. Now the adversary knows what particular colocated service on the server the client is accessing, and even if it cannot block the server entirely (because of colocation), it can terminate that client's specific connection. Perhaps the server can check for and reject reused fake SNI values--but then it also needs to be the case that all (or at least many) of the users of the server's colocated services use Fake SNI, not just the ones who are trying to access the services the adversary would like to block, or else you violate the "Do not stick out" criterion. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI robustness and GREASE PRs - client tracking concerns?
On Tue, Dec 18, 2018 at 12:45:22AM -0600, David Benjamin wrote: > Thanks for the comment! The PR did try to touch on this, but perhaps I did a > poor job of wording it: > https://github.com/tlswg/draft-ietf-tls-esni/pull/124/files#diff-4d2dc9df336bea8e17f5eb4ed7cb1107R511 > > The intent is you use the retry keys just for that one retry. Subsequent > connection attempts revert to the DNS-provided ones. Then the server could > correlate the initial connection and the immediately-following retry, but that > initial "connection" was discarded. It's like saying the server can correlate > the client's ClientHello and Finished. An earlier iteration even placed the > retry on the same connection, which makes the analog clearer. (Doing it in the > same connection is rather a mess, so we bounce to a new one.) > > Another possibility might be to require clients treat these like session > identifiers w.r.t. scoping and lifetime, reducing to something existing, but > that is more complex, so the simple solution seemed a better starting point. > > Does that address the concern, or have I missed something? Oh thanks -- I completely missed that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI robustness and GREASE PRs - client tracking concerns?
On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote: > We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd like > the > group's thoughts on. The goal is to make ESNI more robust and eliminate a > bunch > of deployment risks. The PRs are linked below: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124 Under this design, the ESNIKeys structure in DNS gains a public_name field, which is the name against which the client is supposed to verify handshake, in the event that the server cannot descript the ESNI and returns a esni_retry_request response. The esni_retry_request structure contains alternative ESNIKeys for the client to use in its next connection attempt. I started to think: what if the alternative ESNIKeys were a standard TLS extension on their own? The server could tell the client, on each connection, what ESNIKeys to use for its next connection. The client would not have to consult the DNS for ESNIKeys for any connection but the first, as long as the connections were frequent enough that the ESNIKeys didn't expire. But then I reflected: this would enable precise tracking of clients. The server could give different keys to every client--effectively a cookie--and thereby link past and future connections. I think similar tracking concerns apply to the public_name design. A TLS server could publish one global ESNIKeys in DNS. This one, because it is used by all clients, would not help tracking (within the anonymity set of ESNI-using clients). But the server could, whenever it receives an encrypted_server_name extension encrypted with the global ESNIKeys, pretend that it is unable to decrypt and reply with esni_retry_request and a unique "cookie" ESNIKeys, which that client, and no other, would use for future connections. A unique ESNIKeys per client may not be feasible, if the server has to do trial decryption using the private component of all the ESNIKeys cookies it has handed out. There may be a more clever way to do it than trial description. But anyway a server could define some budget, say, 256 trial decryptions per connection, and instead of a unique ESNIKeys per client, choose one randomly from a pool of 256. Clients would then be partitioned into 256 buckets for the lifetime of the ESNIKeys--which other tracking technique could of course refine further. I suppose something like this is possible even in the current draft as written, if the TLS server and DNS server collude. The DNS server could give different ESNIKeys to different clients, enabling not only the linking of a DNS request and TLS connection, but the linking of several TLS connections together. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI padding the Certificate message
On Thu, Dec 13, 2018 at 11:02:54AM -0500, Viktor Dukhovni wrote: > On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote: > > > Random padding does poorly with repeated trials. So, for instance, > > if I get to observe a large number of requests from the same client > > to the same server, you can gradually infer the length of the cert > > chain. > > Yes, I was aware of this. But one might also note that may services > are not behind a CDN, and that data traffic patterns after the > handshake can also fingerprint the target service. > > Session resumption helps to reduce the number of full handshakes > that leak some information about the certificate size. > > Users who really want (better) protection against traffic analysis > should use Tor. TLS traffic analysis protection from ESNI et. al. > is IMHO best-effort protection for casual use. > > If a user visits just one site (and no others) at a particular CDN, > absent traffic flow obfuscation ala Tor, the user's TLS traffic > will eventually stand out from the noise. Tor does not really offer protection against traffic analysis, apart from hiding the source and destination IP addresses. In fact a lot of website fingerprinting research uses Tor as a carrier, *because* it preserves features of the underlying flow. See for example Table 1 at https://petsymposium.org/2018/files/papers/issue4/popets-2018-0039.pdf#page=3 Tor pads most of its cells to 514 bytes (https://spec.torproject.org/tor-spec §0.2 §3), and fairly recently (Tor 0.3.1.7, 2017-09-18) it sends padding cells during quiet periods in order to collapse long-term netflow records (https://spec.torproject.org/padding-spec §2), but neither of these are designed to defend against website fingerprinting attacks; on the contrary, they introduce fingerprints that make it easier to detect the use of Tor inside a tunnel. Don't miss an important use case. Tor and ESNI are not mutually exclusive. A user may want to use ESNI in order to *reach* Tor (or any other service offering additional security properties). ESNI is not just for HTTPS web pages; it's for any TLS service (or service that can be tunnelled in TLS). But any such service is useless if an intermediary can block the server hosting it. This is where ESNI can be of help. I wouldn't put repeated trials to infer a randomized value, and analysis of encrypted application-layer traffic characteristics, in the same class of difficulty, and reason that if the latter is possible, there's no reason to defend against the former. I think part of the reason that Tor does not (yet) do traffic flow obfuscation is that it hasn't been necessary. The networks that block Tor don't do it on that basis. That's not to say it's not something to think about, just that empirically it hasn't proven as pressing as other considerations. Things like Cisco ETA (https://www.theregister.co.uk/2017/06/22/ciscos_encrypted_traffic_fingerprinting_turned_into_product/, https://github.com/cisco/joy#relation-to-cisco-eta, https://arxiv.org/abs/1607.01639) show the commercial world at least reaching for such capabilities, but my understanding is that it's still far short of an operational "identify this HTTPS site" feature. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNIKeys over complex
On Sat, Dec 08, 2018 at 06:38:30PM +0200, Ilari Liusvaara wrote: > While thinking about the previous, I ran into some issues with the > split mode. Firstly, if the fronting server does not encrypt the > client_hello when transmitting it to backend server, passive attack > can match incoming connections with backend servers. This reduces > anonymity set to a single backend server (a lot smaller set). > > And secondly, even if server encrypts the client_hello, but does not > use a tunnel to backend, if server does not have client hello replay > filtering (and such filtering is hard on typical fronting servers), > replay attacks and some very simple traffic analysis can discover the > backend server (again reducing the anonymity set by a lot). > > This means that the fronting server should have an encrypted tunnel > with the backend server (and there is likely double encryption). I see--you're thinking of an observer who can see "both sides" of a connection: the link between the Client and the Client-Facing Server, and the link between the Client-Facing Server and the Backend Server. I agree: such an observer could, through timing analysis, deanonymize client connections (i.e., tell which Backend Server the Client is accessing, as if it were accessing directly and not through the Client-Facing Server). I suppose to really defend against a global observer, you would need some kind of mixnet. It looks like a little bug in the draft. I've checked just now and I don't see that it says exactly *where* the observer is. I had assumed that the observer only sees the Client–Server link (in Shared Mode) or the link between Client and Client-Facing Server (in Split Mode). I don't understand your point about replay and encrypting the Client Hello. An observer doesn't need to see the contents of the Client Hello to identify a Backend Server--the destination IP address is enough. I don't see what specific attack you have in mind using replay, but it seems to me that even an encrypted tunnel is insufficient. Unless the encrypted tunnel additionally obfuscates packet sizes and timing, an observer can correlate e.g. burst sizes and match incoming flows to outgoing flows, in the manner of website fingerprinting. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-sni-encryption
On Wed, Oct 17, 2018 at 07:25:38PM -0700, Eric Rescorla wrote: > >> As it is, there are a number of servers which desperately require > >> the presence of TLS extension SNI, or will fail TLS handshakes either > >> by choking and dropping connections (Microsoft IIS 8.5+) or by > >> very unhelpful alerts (several others), and also HTTP/2.0 requires > >> unconditional cleartext presence of TLS extension SNI. Any kind of > >> heuristics-based approach for clients to guess whether or not to > >> send TLS extension SNI is flawed from the start. If a network > >> middlebox can make a client present a cleartext TLS extension SNI > >> by refusing connections without cleartext TLS extension SNI, > >> the entire effort becomes pretty useless. > > > > Yes, clients must not fall back to cleartext SNI in this case. > > Please give a clear deterministic algorithm how a client can > tell apart a server that requires cleartext SNI from a server > that does not want cleartext SNI. > > > This isn't really the relevant question, as there are many servers > now which do not require SNI. > > The relevant question is how a client can be made aware that > a server does support ESNI and can have high confidence that > it will accept it. Such an algorithm is provided in: > https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-4 > > Note that as explained in detail, it is not necessary that all clients > send ESNI to that server. Right -- it's not a matter of a server requiring or not requiring ESNI. The way I understand it, a server that supports ESNI merely affords clients an opportunity to better protect themselves -- it is still the client's responsibility to resist downgrades, and to somehow discover (through DNS or otherwise) that the server supports ESNI in the first place. I imagine that most servers that support ESNI will continue to simultaneously support plaintext SNI connections. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
