<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>agwa</author><text>Since there are several questions about Encrypted Client Hello (ECH), and I kind of hand waved that section, I thought an example might be useful.&lt;p&gt;Let&amp;#x27;s say the system is running two web server daemons: a multi-tenant blog hosting platform listening on 2001:db8::1, and a multi-tenant bug tracker listening on 2001:db8::2. snid is on 192.0.2.1.  Your DNS records would look like this:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  blogs.example.com. A 192.0.2.1
  blogs.example.com. AAAA 2001:db8::1
  bugs.example.com.  A 192.0.2.1
  bugs.example.com.  AAAA 2001:db8::2
&lt;/code&gt;&lt;/pre&gt;
The various tenants would be CNAMEd to one of these hostnames like:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  blog.domain1.example. CNAME blogs.example.com.
  bugs.domain2.example. CNAME bugs.example.com.
&lt;/code&gt;&lt;/pre&gt;
The &amp;quot;decoy&amp;quot; hostnames (the &amp;quot;public_name&amp;quot; in ECH parlance) would be blogs.example.com or bugs.example.com.  Thus, ECH would hide which tenant the client is connecting to, but would not hide the service.  Note that if the client were connecting over IPv6, an eavesdropper would be able to determine the service anyways by looking at the destination IP address, which is unencrypted.</text><parent_chain></parent_chain></comment><story><title>Using SNI proxying and IPv6 to share port 443 between webapps</title><url>https://www.agwa.name/blog/post/using_sni_proxying_and_ipv6_to_share_port_443</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>twic</author><text>Some lazy questions ...&lt;p&gt;&amp;gt;  Since IPv6 addresses are 128 bits long, but IPv4 addresses are only 32 bits, it&amp;#x27;s possible to embed IPv4 addresses in IPv6 addresses. snid embeds the client&amp;#x27;s IP address in the lower 32 bits of the source address which it uses to connect to the backend.&lt;p&gt;How does this work? snid just makes up an IP address? What socket API calls do you make to do this? Just pick an address and bind, and the kernel is fine with that? And it all gets routed back and forth correctly? Do you have to configure this 64:ff9b:1::&amp;#x2F;48 prefix on the loopback interface?&lt;p&gt;&amp;gt; Encrypted Client Hello doesn&amp;#x27;t actually encrypt the initial Client Hello message. It&amp;#x27;s still sent in the clear, but with a decoy SNI hostname. The actual Client Hello message, with the true SNI hostname, is encrypted and placed in an extension of the unencrypted Client Hello. To make Encrypted Client Hello work with snid, I just need to ensure that the decoy SNI hostname resolves to the IPv6 address of the backend server. snid will see this hostname and route the connection to the correct backend server, as usual.&lt;p&gt;How does the decoy SNI hostname get chosen? This sounds like there needs to be a different decoy hostname for each backend service. Does that come from DNS somehow? The client doesn&amp;#x27;t just make it up at random?</text><parent_chain></parent_chain></comment><story><title>Using SNI proxying and IPv6 to share port 443 between webapps</title><url>https://www.agwa.name/blog/post/using_sni_proxying_and_ipv6_to_share_port_443</url></story>