<?xml version='1.0' encoding='utf-8'?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0"><updated>2025-11-09T11:23:08.088527Z</updated><id>tag:,2018:/isso/thread/publications/usenixsecurity25/en/</id><title>Comments for /publications/usenixsecurity25/en/</title><entry><id>tag:,2018:/isso/27/1025</id><title>Comment #1025</title><updated>2025-11-09T11:23:08.088527Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-1025" /><content type="html">&lt;blockquote&gt;
&lt;p&gt;Notably, a substantial number of &lt;a href="http://googlevideo.com" rel="nofollow noopener"&gt;googlevideo.com&lt;/a&gt; subdomains (35,443) appeared on the blocklist, suggesting a broader blocking rule targeting *.googlevideo.com&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Hi, could you publish a list of possible blocking rules? I found a useful script:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://github.com/ooni/probe/issues/2834#issuecomment-2564856033" rel="nofollow noopener"&gt;https://github.com/ooni/probe/issues/2834#issuecomment-2564856033&lt;/a&gt;&lt;/p&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/649" href="feed/publications/usenixsecurity25/en/#isso-649" /></entry><entry><id>tag:,2018:/isso/27/670</id><title>Comment #670</title><updated>2025-08-06T06:46:16.702291Z</updated><author><name>Xi Jinping</name></author><link href="feed/publications/usenixsecurity25/en/#isso-670" /><content type="html">&lt;p&gt;Thanks for your presentation of freedom of expression.&lt;/p&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/669" href="feed/publications/usenixsecurity25/en/#isso-669" /></entry><entry><id>tag:,2018:/isso/27/669</id><title>Comment #669</title><updated>2025-08-05T17:11:34.193392Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-669" /><content type="html">&lt;p&gt;希⁢望⁢这⁢攻⁢击⁢漏⁢洞⁢早⁢日⁢修⁢复⁢，⁢以⁢及⁢强⁢化⁢可⁢预⁢见⁢未⁢来⁢会⁢大⁢规⁢模⁢使⁢用⁢的⁢Q⁢U⁢I⁢C⁢审⁢查⁢，⁢
⁢在⁢防⁢火⁢墙⁢防⁢护⁢下⁢都⁢有⁢这⁢么⁢多⁢傻⁢逼⁢，⁢可⁢预⁢见⁢没⁢有⁢防⁢火⁢墙⁢傻⁢逼⁢只⁢会⁢更⁢多&lt;/p&gt;</content></entry><entry><id>tag:,2018:/isso/27/657</id><title>Comment #657</title><updated>2025-08-01T08:32:46.034435Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-657" /><content type="html">&lt;p&gt;Thank you for sharing your test. We only contacted Fang Binxing once on Thu, 23 Jan 2025. At that time, our email was not bounced back. It&amp;#39;s possible that this email address got more attentions and has thus been removed.&lt;/p&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/652" href="feed/publications/usenixsecurity25/en/#isso-652" /></entry><entry><id>tag:,2018:/isso/27/656</id><title>Comment #656</title><updated>2025-08-01T08:28:56.616812Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-656" /><content type="html">&lt;p&gt;That&amp;#39;s true. A few line of code using python scapy sendpfast/tcpreplay to send a recorded QUIC Initial should be enough. In the paper, we demonstrated that it&amp;#39;s feasible to overwhelm the censor empirically, however, we don&amp;#39;t think it&amp;#39;s necessary or the most effective to overwhelm the censor for censorship circumvention:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;The GFW&amp;#39;s slowness in decryption could be improved if the censor got enough time, resources, and motivation. It will likely take the censor quiet some time to actually improve it, given its fundamental inflexibility (see our essay: &lt;a href="https://github.com/net4people/bbs/issues/136" rel="nofollow noopener"&gt;https://github.com/net4people/bbs/issues/136&lt;/a&gt;);&lt;/li&gt;
&lt;li&gt;In terms of censorship circumvention, there&amp;#39;s better censorship circumvention strategies. For example, one may first send legitimate QUIC Initials with wrong but uncensored SNI (e.g. &lt;a href="http://baidu.com" rel="nofollow noopener"&gt;baidu.com&lt;/a&gt;), and then send the real intended QUIC Initial with the censored SNI (e.g. &lt;a href="http://google.com" rel="nofollow noopener"&gt;google.com&lt;/a&gt;). The destination server will ignore the first packet since it&amp;#39;s SNI doesn&amp;#39;t match the server&amp;#39;s domain name, but will accept the second one. The GFW, however, will have to make sure to inspect more packets after a QUIC Initial for each connection, which may be costly to track flows.&lt;/li&gt;
&lt;/ol&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/649" href="feed/publications/usenixsecurity25/en/#isso-649" /></entry><entry><id>tag:,2018:/isso/27/655</id><title>Comment #655</title><updated>2025-08-01T08:12:55.920020Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-655" /><content type="html">&lt;blockquote&gt;
&lt;p&gt;Have you noticed that the PGP key CNCERT published on their site since 2003 is too weak to be trusted now?&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Good catch. We indeed noticed that, and that&amp;#39;s part of the reason why we didn&amp;#39;t use PGP encryption on the email to CNCERT: we were not even sure if they still had the private key to decrypt our message, should we send an encrypted message. &lt;/p&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/645" href="feed/publications/usenixsecurity25/en/#isso-645" /></entry><entry><id>tag:,2018:/isso/27/654</id><title>Comment #654</title><updated>2025-08-01T08:10:15.489333Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-654" /><content type="html">&lt;blockquote&gt;
&lt;p&gt;Looking at the Venn diagram at 4.1, I had a feeling that such domain blacklists are decentralized among different entities, like the sensitive keyword list also varies among different Chinese social platforms.
For example, the TLS SNI list is probably managed by cybersecurity company Q, and the QUIC one is done by Z...
CNCERT&amp;#39;s cooperation companies: &lt;a href="https://web.archive.org/web/20250315145412/https://www.cert.org.cn/publish/main/32/10.html" rel="nofollow noopener"&gt;https://web.archive.org/web/20250315145412/https://www.cert.org.cn/publish/main/32/10.html&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;It&amp;#39;s a very plausible hypothesis that difference companies and groups are maintaining different censorship devices as part of the GFW. Anonymous et al. found that even for DNS censorship, there are at least three difference DNS Injectors that have different parsing logic, different packet fingerprints, and different block lists (see Table 3 of Anonymous et al. &lt;a href="https://gfw.report/publications/foci20_dns/en/#tbl:3-summary-dns-injectors-dns-aa-ip-df-flags" rel="nofollow noopener"&gt;https://gfw.report/publications/foci20_dns/en/#tbl:3-summary-dns-injectors-dns-aa-ip-df-flags&lt;/a&gt;). &lt;/p&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/645" href="feed/publications/usenixsecurity25/en/#isso-645" /></entry><entry><id>tag:,2018:/isso/27/652</id><title>Comment #652</title><updated>2025-08-01T07:25:26.251933Z</updated><author><name>Fang Bin Xing</name></author><link href="feed/publications/usenixsecurity25/en/#isso-652" /><content type="html">&lt;p&gt;Did your email arrive his mailbox?&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;a href="mailto:fangbx@iie.ac.cn"&gt;fangbx@iie.ac.cn&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I tried sending to this address but got a &lt;code&gt;&amp;lt;fangbx@iie.ac.cn&amp;gt;: host &lt;a href="http://mx.cstnet.cn" rel="nofollow noopener"&gt;mx.cstnet.cn&lt;/a&gt;[159.226.251.12] said: 550 User not found: fangbx@iie.ac.cn (in reply to RCPT TO command)&lt;/code&gt;.&lt;/p&gt;</content></entry><entry><id>tag:,2018:/isso/27/649</id><title>Comment #649</title><updated>2025-08-01T02:56:19.758640Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-649" /><content type="html">&lt;p&gt;Given that it takes a very small amount of bandwidth to disrupt the GFW, I suppose someone can come up with a easier-to-deploy version of the degradation attack to really do some distributed damage. Doing the public some good for a low cost.&lt;/p&gt;</content></entry><entry><id>tag:,2018:/isso/27/648</id><title>Comment #648</title><updated>2025-08-01T01:35:15.599879Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-648" /><content type="html">&lt;p&gt;Xiausescu? In topic please.&lt;/p&gt;</content><thr:in-reply-to ref="tag:,2018:/isso/27/646" href="feed/publications/usenixsecurity25/en/#isso-646" /></entry><entry><id>tag:,2018:/isso/27/646</id><title>Comment #646</title><updated>2025-08-01T01:13:52.706515Z</updated><author><name /></author><link href="feed/publications/usenixsecurity25/en/#isso-646" /><content type="html">&lt;p&gt;习近平死！！！&lt;/p&gt;</content></entry><entry><id>tag:,2018:/isso/27/645</id><title>Comment #645</title><updated>2025-07-31T06:50:27.314968Z</updated><author><name>Gundaz Aghayev</name></author><link href="feed/publications/usenixsecurity25/en/#isso-645" /><content type="html">&lt;p&gt;Looking at the Venn diagram at 4.1, I had a feeling that such domain blacklists are decentralized among different entities, like the sensitive keyword list also varies among different Chinese social platforms.&lt;/p&gt;

&lt;p&gt;For example, the TLS SNI list is probably managed by cybersecurity company Q, and the QUIC one is done by Z...&lt;/p&gt;

&lt;p&gt;CNCERT&amp;#39;s cooperation companies: &lt;a href="https://web.archive.org/web/20250315145412/https://www.cert.org.cn/publish/main/32/10.html" rel="nofollow noopener"&gt;https://web.archive.org/web/20250315145412/https://www.cert.org.cn/publish/main/32/10.html&lt;/a&gt;&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Responsible Disclosure. We shared our findings on China’s QUIC censorship and the circumvention strategies with the anti-censorship and open-source communities. In specific, we contacted&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;&lt;del&gt;lol, the only entities you didn&amp;#39;t contact is leaders and operators of Great Firewall, says Cyberspace Administration of China.&lt;/del&gt; No, you actually did at the end.&lt;/p&gt;

&lt;p&gt;Have you noticed that the &lt;a href="https://web.archive.org/web/20250721130759/http://www.cert.org.cn/cncert.asc" rel="nofollow noopener"&gt;PGP key CNCERT published on their site&lt;/a&gt; since 2003 is too weak to be trusted now?&lt;/p&gt;</content></entry></feed>