deploy: teleproxy/teleproxy@44ac526

Author: rkline0x

changelog/index.html

@@ -1923,6 +1923,7 @@
 <h1 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">&para;</a></h1>
 <h2 id="unreleased">Unreleased<a class="headerlink" href="#unreleased" title="Permanent link">&para;</a></h2>
 <ul>
+<li><strong>Wildcard certificate support in fake-TLS</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/44">#44</a>). Operators with a wildcard cert like <code>*.example.com</code> served from a concrete vhost (e.g. <code>proxy.example.com</code>) couldn't make fake-TLS work — SNI lookup did literal string compare against <code>*.example.com</code>, every real ClientHello missed the match, and the connection landed on nginx's default vhost serving an unrelated cert (the failure mode also reported against mtg as <a href="https://github.com/9seconds/mtg/issues/394">9seconds/mtg#394</a>). Configure <code>-D '*.example.com:proxy.example.com:443'</code> (or <code>EE_DOMAIN=*.example.com</code>, <code>EE_BACKEND=proxy.example.com:443</code>) and teleproxy now matches any single-label subdomain against the pattern per RFC 6125: <code>proxy.example.com</code> matches, <code>example.com</code> (apex) and <code>a.b.example.com</code> (multi-label) do not. Startup fingerprinting probes the backend hostname, so the captured ServerHello parameters reflect the real cert vhost. Covered by <code>make test-wildcard-cert</code>.</li>
 <li><strong>Document direct-mode limitations</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/79">#79</a>). The <a href="/features/direct-mode/">Direct-to-DC Mode</a> page now spells out what <code>--direct</code> trades away by skipping Telegram's middle-end: media on non-Premium accounts may not load, sponsored channels aren't delivered, and Telegram voice/video calls aren't carried by any MTProto proxy regardless of mode. Answers the recurring symptom in <a href="https://github.com/teleproxy/teleproxy/issues/60">#60</a>.</li>
 <li><strong><code>CONFIG_DOWNLOAD_PROXY</code> env var for the proxy-multi.conf download</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/61">#61</a>). Hosts that can't reach <code>core.telegram.org</code> directly can now route the config refresh through an outbound HTTP or SOCKS proxy. Accepts any URL <code>curl -x</code> understands (<code>http://</code>, <code>https://</code>, <code>socks5://</code>, <code>socks5h://</code>, with optional <code>user:pass@</code>). Falls back to <code>SOCKS5_PROXY</code> when unset, so users who already proxy DC traffic don't need to set anything new. Applies to the initial fetch in <code>start.sh</code> and the 6-hour cron refresh.</li>
 <li><strong>Split SNI domain from camouflage backend</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/62">#62</a>). The fake-TLS feature used to require <code>EE_DOMAIN</code> to be both the SNI hostname and the backend connect target — operators worked around it by editing <code>/etc/hosts</code>. New <code>EE_BACKEND</code> env var separates the two: <code>EE_DOMAIN</code> keeps a clean public SNI name like <code>cloudflare.com</code>, while <code>EE_BACKEND</code> points at the actual backend (<code>127.0.0.1:8443</code>, <code>[::1]:8443</code>, or <code>unix:/run/nginx.sock</code>). Reality-style. Available as TOML too: <code>domain = [{ name = "cloudflare.com", backend = "127.0.0.1:8443" }]</code>. The legacy <code>EE_DOMAIN=host:port</code> and <code>domain = "..."</code> strings still work unchanged.</li>

fa/changelog/index.html

@@ -1923,6 +1923,7 @@
 <h1 id="changelog">Changelog<a class="headerlink" href="#changelog" title="Permanent link">&para;</a></h1>
 <h2 id="unreleased">Unreleased<a class="headerlink" href="#unreleased" title="Permanent link">&para;</a></h2>
 <ul>
+<li><strong>Wildcard certificate support in fake-TLS</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/44">#44</a>). Operators with a wildcard cert like <code>*.example.com</code> served from a concrete vhost (e.g. <code>proxy.example.com</code>) couldn't make fake-TLS work — SNI lookup did literal string compare against <code>*.example.com</code>, every real ClientHello missed the match, and the connection landed on nginx's default vhost serving an unrelated cert (the failure mode also reported against mtg as <a href="https://github.com/9seconds/mtg/issues/394">9seconds/mtg#394</a>). Configure <code>-D '*.example.com:proxy.example.com:443'</code> (or <code>EE_DOMAIN=*.example.com</code>, <code>EE_BACKEND=proxy.example.com:443</code>) and teleproxy now matches any single-label subdomain against the pattern per RFC 6125: <code>proxy.example.com</code> matches, <code>example.com</code> (apex) and <code>a.b.example.com</code> (multi-label) do not. Startup fingerprinting probes the backend hostname, so the captured ServerHello parameters reflect the real cert vhost. Covered by <code>make test-wildcard-cert</code>.</li>
 <li><strong>Document direct-mode limitations</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/79">#79</a>). The <a href="/features/direct-mode/">Direct-to-DC Mode</a> page now spells out what <code>--direct</code> trades away by skipping Telegram's middle-end: media on non-Premium accounts may not load, sponsored channels aren't delivered, and Telegram voice/video calls aren't carried by any MTProto proxy regardless of mode. Answers the recurring symptom in <a href="https://github.com/teleproxy/teleproxy/issues/60">#60</a>.</li>
 <li><strong><code>CONFIG_DOWNLOAD_PROXY</code> env var for the proxy-multi.conf download</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/61">#61</a>). Hosts that can't reach <code>core.telegram.org</code> directly can now route the config refresh through an outbound HTTP or SOCKS proxy. Accepts any URL <code>curl -x</code> understands (<code>http://</code>, <code>https://</code>, <code>socks5://</code>, <code>socks5h://</code>, with optional <code>user:pass@</code>). Falls back to <code>SOCKS5_PROXY</code> when unset, so users who already proxy DC traffic don't need to set anything new. Applies to the initial fetch in <code>start.sh</code> and the 6-hour cron refresh.</li>
 <li><strong>Split SNI domain from camouflage backend</strong> (<a href="https://github.com/teleproxy/teleproxy/issues/62">#62</a>). The fake-TLS feature used to require <code>EE_DOMAIN</code> to be both the SNI hostname and the backend connect target — operators worked around it by editing <code>/etc/hosts</code>. New <code>EE_BACKEND</code> env var separates the two: <code>EE_DOMAIN</code> keeps a clean public SNI name like <code>cloudflare.com</code>, while <code>EE_BACKEND</code> points at the actual backend (<code>127.0.0.1:8443</code>, <code>[::1]:8443</code>, or <code>unix:/run/nginx.sock</code>). Reality-style. Available as TOML too: <code>domain = [{ name = "cloudflare.com", backend = "127.0.0.1:8443" }]</code>. The legacy <code>EE_DOMAIN=host:port</code> and <code>domain = "..."</code> strings still work unchanged.</li>

features/dpi-resistance/index.html

@@ -1085,6 +1085,17 @@
     </span>
   </a>
 
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#wildcard-certificates" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Wildcard certificates
+      
+    </span>
+  </a>
+  
 </li>
 
           <li class="md-nav__item">
@@ -1825,6 +1836,17 @@
     </span>
   </a>
 
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#wildcard-certificates" class="md-nav__link">
+    <span class="md-ellipsis">
+      
+        Wildcard certificates
+      
+    </span>
+  </a>
+  
 </li>
 
           <li class="md-nav__item">
@@ -1917,6 +1939,8 @@ <h3 id="pick-a-high-traffic-domain">Pick a high-traffic domain<a class="headerli
 <p>Choose a popular, CDN-backed domain for SNI (e.g., <code>www.google.com</code>, <code>cloudflare.com</code>). The domain must support TLS 1.3. Teleproxy probes the domain at startup to learn its ServerHello characteristics and mimics them.</p>
 <h3 id="run-a-custom-tls-backend">Run a custom TLS backend<a class="headerlink" href="#run-a-custom-tls-backend" title="Permanent link">&para;</a></h3>
 <p>If you control the server's domain, set up nginx with a valid TLS certificate behind Teleproxy. This makes the server indistinguishable from a normal HTTPS website under active probing. See <a href="../fake-tls/#custom-tls-backend-tcp-splitting">Fake-TLS: Custom TLS Backend</a>.</p>
+<h3 id="wildcard-certificates">Wildcard certificates<a class="headerlink" href="#wildcard-certificates" title="Permanent link">&para;</a></h3>
+<p>If your TLS certificate is a wildcard (e.g. <code>*.example.com</code> served from <code>proxy.example.com</code>), configure the <code>-D</code> flag with the wildcard pattern: <code>-D '*.example.com:proxy.example.com:443'</code>. Teleproxy matches any single-label subdomain of <code>example.com</code> against the pattern (RFC 6125): <code>proxy.example.com</code> and <code>node-7.example.com</code> match; <code>example.com</code> (apex) and <code>a.b.example.com</code> (multi-label) do not. Fingerprinting at startup probes the backend host, not the literal <code>*.example.com</code>. An explicit backend is required for wildcard entries.</p>
 <h3 id="use-random-padding-dd-mode">Use random padding (DD mode)<a class="headerlink" href="#use-random-padding-dd-mode" title="Permanent link">&para;</a></h3>
 <p>For ISPs that fingerprint MTProto by packet sizes, enable random padding by prefixing <code>dd</code> to the client secret.</p>
 <h2 id="what-users-can-do-client-side">What Users Can Do (Client-Side)<a class="headerlink" href="#what-users-can-do-client-side" title="Permanent link">&para;</a></h2>