<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://jonsnowwhite.de/feed.xml" rel="self" type="application/atom+xml" /><link href="https://jonsnowwhite.de/" rel="alternate" type="text/html" /><updated>2026-04-21T10:48:08+00:00</updated><id>https://jonsnowwhite.de/feed.xml</id><title type="html">Niklas Niere / JonSnowWhite</title><subtitle>Ph.D Student</subtitle><author><name>Niklas Niere</name><email>niklas.niere(at)uni-paderborn.de</email></author><entry><title type="html">China Extended its SNI Censorship to QUIC</title><link href="https://jonsnowwhite.de/posts/2025/04/04/" rel="alternate" type="text/html" title="China Extended its SNI Censorship to QUIC" /><published>2025-04-04T00:00:00+00:00</published><updated>2025-04-04T00:00:00+00:00</updated><id>https://jonsnowwhite.de/posts/2025/04/china-quic</id><content type="html" xml:base="https://jonsnowwhite.de/posts/2025/04/04/"><![CDATA[<p>QUIC, the successor to TLS over TCP, has become popular in recent years. Despite its increase in popularity, QUIC has remained largely uncensored: Only Russian TSPU devices analyzed QUIC connections and could extract the server’s hostname from the SNI extension. Other censors—such as China’s GFW—have not been found capable of sophisticated QUIC analysis; in January 2025, we noticed sophisticated QUIC censorship in China.</p>

<p>Similar to Russian TSPU devices, the GFW now extracts the SNI extension from QUIC connections and blocks unwanted connections. As of now, the GFW’s QUIC censorship operates on a limited list of hostnames, is residual-only, and triggers inconsistently. Based on these characteristics, we suspect that the deployment of QUIC censorship in the GFW is an ongoing process: This process might culminate in broad QUIC censorship by the GFW. This blog post details our findings.</p>]]></content><author><name>Niklas Niere</name><email>niklas.niere(at)uni-paderborn.de</email></author><category term="Censorship" /><category term="QUIC" /><category term="TLS" /><category term="SNI" /><category term="GFW" /><category term="China" /><summary type="html"><![CDATA[QUIC, the successor to TLS over TCP, has become popular in recent years. Despite its increase in popularity, QUIC has remained largely uncensored: Only Russian TSPU devices analyzed QUIC connections and could extract the server’s hostname from the SNI extension. Other censors—such as China’s GFW—have not been found capable of sophisticated QUIC analysis; in January 2025, we noticed sophisticated QUIC censorship in China.]]></summary></entry><entry><title type="html">Censors Ignore Unencrypted HTTP/2 Traffic</title><link href="https://jonsnowwhite.de/posts/2024/11/19/" rel="alternate" type="text/html" title="Censors Ignore Unencrypted HTTP/2 Traffic" /><published>2024-11-19T00:00:00+00:00</published><updated>2024-11-19T00:00:00+00:00</updated><id>https://jonsnowwhite.de/posts/2024/11/unencrypted-http</id><content type="html" xml:base="https://jonsnowwhite.de/posts/2024/11/19/"><![CDATA[<p>Censors worldwide have long censored unencrypted HTTP traffic. In this blog post, we show that a specific HTTP version—unencrypted HTTP/2—is unaffected by censorship in China and Iran. We access otherwise censored websites in both countries over unencrypted HTTP/2. Despite no web browser implementing unencrypted HTTP/2, we detect that up to 6.28% of websites support unencrypted HTTP/2 traffic. To aid the community and ease future research, we provide a tool that evaluates the unencrypted HTTP support of a website. Finally, we discuss the limitations and potential of unencrypted HTTP/2 for censorship circumvention. We consider our finding an interesting addition to current censorship circumvention techniques.</p>]]></content><author><name>Niklas Niere</name><email>niklas.niere(at)uni-paderborn.de</email></author><category term="Censorship" /><category term="HTTP" /><category term="GFW" /><category term="China" /><category term="Iran" /><summary type="html"><![CDATA[Censors worldwide have long censored unencrypted HTTP traffic. In this blog post, we show that a specific HTTP version—unencrypted HTTP/2—is unaffected by censorship in China and Iran. We access otherwise censored websites in both countries over unencrypted HTTP/2. Despite no web browser implementing unencrypted HTTP/2, we detect that up to 6.28% of websites support unencrypted HTTP/2 traffic. To aid the community and ease future research, we provide a tool that evaluates the unencrypted HTTP support of a website. Finally, we discuss the limitations and potential of unencrypted HTTP/2 for censorship circumvention. We consider our finding an interesting addition to current censorship circumvention techniques.]]></summary></entry><entry><title type="html">Russia Censors the Encrypted Client Hello(ECH)</title><link href="https://jonsnowwhite.de/posts/2024/11/russia-ech/" rel="alternate" type="text/html" title="Russia Censors the Encrypted Client Hello(ECH)" /><published>2024-11-11T00:00:00+00:00</published><updated>2024-11-11T00:00:00+00:00</updated><id>https://jonsnowwhite.de/posts/2024/11/russia-ech</id><content type="html" xml:base="https://jonsnowwhite.de/posts/2024/11/russia-ech/"><![CDATA[<p>Last week, Russia started blocking the Encrypted Client Hello (ECH). This prevents Russian internet users from utilizing ECH for censorship circumvention. It also blocks otherwise uncensored websites such as SteamDB. Below, I summarize ECH, detail Russia’s ECH censorship, and discuss possible remedies for affected users and ECH in general.</p>

<h1 id="when-who-and-what">When, Who, and What</h1>
<p>On November 7th, Russian authorities announced the beginning censorship of ECH<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" class="footnote" rel="footnote">1</a></sup>. This development is a reaction to Cloudflare’s ECH activation roughly two months prior<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" class="footnote" rel="footnote">2</a></sup>. Russia now blocks all ECH connections from Russian Internet users to Cloudflare with dedicated censorship devices (TSPU)<sup id="fnref:3" role="doc-noteref"><a href="#fn:3" class="footnote" rel="footnote">3</a></sup>. This led to Russian Internet users being unable to connect to some Cloudflare websites.</p>

<h1 id="what-is-ech">What is ECH?</h1>
<p>The Encrypted Client Hello (ECH) is an extension to TLS, the protocol that encrypts most Internet connections.
Due to their prevalence, TLS connections are widely analyzed by Internet censors such as the one in Russia.
Key to censors’ analysis of TLS connections is the Server Name Indication (SNI) extension containing the hostname of the accessed website in plaintext.
The ECH extension encrypts the SNI alongside other information that could compromise the server.
This prevents censors from determining the servers’ identity, making ECH a viable censorship circumvention technique.
Further hardening ECH against censorship, a bogus ECH extension can be included in TLS connections to servers without ECH support.
This way, censors can not block all ECH connections as they are indistinguishable from non-ECH connections.</p>

<h1 id="how-russia-censors-ech">How Russia Censors ECH</h1>
<p>Despite its best efforts, ECH is still censorable.
While ECH encrypts the original SNI extension, it introduces another, again unencrypted, SNI extension.
The so-called public hostname in the unencrypted SNI is defined by the server and usually shared by multiple domains.
For instance, Cloudflare specifies <code class="language-plaintext highlighter-rouge">cloudflare-ech.com</code> as the public hostname for all ECH connections.
This makes ECH traffic to Cloudflare detectable and, thus, censorable.
Taking advantage of the situation, Russia now blocks all TLS connections to Cloudflare with an ECH extension and an SNI extension containing <code class="language-plaintext highlighter-rouge">cloudflare-ech.com</code>.</p>

<h1 id="consequences-for-russian-internet-users">Consequences for Russian Internet Users</h1>
<p>Russia’s blocking of ECH has two main consequences for Russian Internet users.
First, censored websites made accessible by ECH are now inaccessible again.
To access them, users have to resort to other circumvention methods.
Second, uncensored websites behind Cloudflare’s ECH mechanism such as SteamDB<sup id="fnref:4" role="doc-noteref"><a href="#fn:4" class="footnote" rel="footnote">4</a></sup> are also inaccessible. 
To access them, users can disable ECH in Firefox and Chrome to make them accessible again.</p>

<h1 id="tackling-the-general-problem">Tackling the General Problem</h1>
<p>To prevent censors from blocking all ECH connections, ECH connections must be truly indistinguishable from non-ECH connections.
This cannot be achieved as long as a static and easily detectable public hostname such as <code class="language-plaintext highlighter-rouge">cloudflare-ech.com</code> is transmitted in plaintext alongside any ECH connection.
Randomizing this hostname or replacing it with an uncensored hostname would solve the problem from a censorship point of view.
While the standard allows such behavior it advises against it<sup id="fnref:5" role="doc-noteref"><a href="#fn:5" class="footnote" rel="footnote">5</a></sup> and Cloudflare rejects all ECH connections with hostnames other than <code class="language-plaintext highlighter-rouge">cloudflare-ech.com</code>.
To make ECH more resilient against censorship, I advertise a discussion about the problems of ECH’s public hostname.</p>

<hr />

<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:1" role="doc-endnote">
      <p><a href="https://cmu.gov.ru/ru/news/2024/11/07/%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC-%D0%BE%D1%82%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D1%8C%D1%81%D1%8F-%D0%BE%D1%82-cdn-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%B0-cloudflare/">https://cmu.gov.ru/ru/news/2024/11/07/%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC-%D0%BE%D1%82%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D1%8C%D1%81%D1%8F-%D0%BE%D1%82-cdn-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%B0-cloudflare/</a> <a href="#fnref:1" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:2" role="doc-endnote">
      <p><a href="https://github.com/net4people/bbs/issues/393">https://github.com/net4people/bbs/issues/393</a> <a href="#fnref:2" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:3" role="doc-endnote">
      <p><a href="https://github.com/net4people/bbs/issues/417">https://github.com/net4people/bbs/issues/417</a> <a href="#fnref:3" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:4" role="doc-endnote">
      <p><a href="https://github.com/net4people/bbs/issues/417">https://x.com/SteamDB/status/1854552613435383836</a> <a href="#fnref:4" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:5" role="doc-endnote">
      <p><a href="https://github.com/net4people/bbs/issues/417">https://www.ietf.org/archive/id/draft-ietf-tls-esni-22.html#name-offering-ech</a> <a href="#fnref:5" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>]]></content><author><name>Niklas Niere</name><email>niklas.niere(at)uni-paderborn.de</email></author><category term="Censorship" /><category term="ECH" /><category term="Russia" /><summary type="html"><![CDATA[Last week, Russia started blocking the Encrypted Client Hello (ECH). This prevents Russian internet users from utilizing ECH for censorship circumvention. It also blocks otherwise uncensored websites such as SteamDB. Below, I summarize ECH, detail Russia’s ECH censorship, and discuss possible remedies for affected users and ECH in general.]]></summary></entry><entry><title type="html">Circumventing the GFW with TLS Record Fragmentation</title><link href="https://jonsnowwhite.de/posts/2023/06/27/" rel="alternate" type="text/html" title="Circumventing the GFW with TLS Record Fragmentation" /><published>2023-06-27T00:00:00+00:00</published><updated>2023-06-27T00:00:00+00:00</updated><id>https://jonsnowwhite.de/posts/2023/06/record-frag</id><content type="html" xml:base="https://jonsnowwhite.de/posts/2023/06/27/"><![CDATA[<p>TCP fragmentation has long been known as a viable deep packet inspection (DPI) circumvention technique. However, censors are increasingly aware of this technique. We propose TLS record fragmentation as a new censorship circumvention technique on the TLS layer that functions analogously to TCP fragmentation. Using TLS record fragmentation, we successfully circumvented the DPI of the Great Firewall of China (GFW). We also found that over 90% of TLS servers support this new circumvention technique. To contextualize TLS record fragmentation for future work, we discuss its possibilities and limitations.</p>]]></content><author><name>Niklas Niere</name><email>niklas.niere(at)uni-paderborn.de</email></author><category term="Censorship" /><category term="TLS" /><category term="SNI" /><category term="GFW" /><category term="China" /><summary type="html"><![CDATA[TCP fragmentation has long been known as a viable deep packet inspection (DPI) circumvention technique. However, censors are increasingly aware of this technique. We propose TLS record fragmentation as a new censorship circumvention technique on the TLS layer that functions analogously to TCP fragmentation. Using TLS record fragmentation, we successfully circumvented the DPI of the Great Firewall of China (GFW). We also found that over 90% of TLS servers support this new circumvention technique. To contextualize TLS record fragmentation for future work, we discuss its possibilities and limitations.]]></summary></entry></feed>