3 ms·

Unfortunately, Encrypted Client Hello isn't automatic and requires cumbersome DNS configuration, so it's likely not going to gain widespread adoption. Here's h

Unfortunately, Encrypted Client Hello isn't automatic and requires cumbersome DNS configuration, so it's likely not going to gain widespread adoption. Here's hoping that the next TLS version will automatically encrypt everything. Firewall vendors will not like it, but it's the only way to truly hide everything from middleboxes.

tialaramex 1y ago
Magic is impossible. In order to encrypt a message to Bob, Alice must first have Bob's key. That's why ECH needs DNS records, Bob publishes a key, "Here's the key for all six thousand blog.example sites we publish" and Alice can then encrypt either "Hi Bob, give me clown-porn.blog.example" or "Hi Bob, give me trans-rights.blog.example" and the middlebox can't read it. We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case. Nor can we prevent Bob from deciding to publish separate keys, "these are for the clown porn and lynching videos, we'll use separate keys for the trans-rights stuff because the Government says that is naughty". But we can make that Bob's choice. To do that, Alice needs Bob's key and either Alice has to magically know everybody's keys (which doesn't scale) or it is published somewhere for Alice to find, in this case DNS. If we just say OK we'll encrypt with no particular recipient in mind, that doesn't prevent the scenario we care about, Alice encrypts the message, the middlebox decrypts it (No reason it can't, Alice can't pick Bob as the only recipient) and the middlebox gets to inspect Alice's destination.
- delusional 1y ago
  I agree with this in general. In specific though: > We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case. Seems incorrect. Bob could publish a single key without any indication of what is behind that key. Alice would get that key (from DNS), but since it was just for talking with Bob in general, nobody knows what Bob has. Alice and Bob are then free to talk about their trans rights. The particular point is that there's no reason the middlebox would even know there is a subdomain called trans-rights.bob.example.
  - tialaramex 1y ago
    There are great number of ways in which the operators of the middlebox might come to know that Bob publishes this blog. Most obviously the humans charged with setting up such tech might literally find out in the ordinary course of their life that they ought to add this rule. Fox News show headline "Ban this sick filth", a letter from the Government about "Extremist sites unsuitable for your employees", and so on. But technologically there could be a list, maybe a "Ministry of Truth" provides the list of providers who are forbidden, it needn't say why, and if it does say it could lie, usually such lists are (like spam blackholing) automated and unsupervised. They could search the "Passive DNS" system to find suspicious names and block the entire provider, or likewise with Certificate Transparency. So alas there are reasons the middlebox might be configured this way.

tialaramex 1y ago

Magic is impossible. In order to encrypt a message to Bob, Alice must first have Bob's key. That's why ECH needs DNS records, Bob publishes a key, "Here's the key for all six thousand blog.example sites we publish" and Alice can then encrypt either "Hi Bob, give me clown-porn.blog.example" or "Hi Bob, give me trans-rights.blog.example" and the middlebox can't read it. We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case. Nor can we prevent Bob from deciding to publish separate keys, "these are for the clown porn and lynching videos, we'll use separate keys for the trans-rights stuff because the Government says that is naughty". But we can make that Bob's choice. To do that, Alice needs Bob's key and either Alice has to magically know everybody's keys (which doesn't scale) or it is published somewhere for Alice to find, in this case DNS. If we just say OK we'll encrypt with no particular recipient in mind, that doesn't prevent the scenario we care about, Alice encrypts the message, the middlebox decrypts it (No reason it can't, Alice can't pick Bob as the only recipient) and the middlebox gets to inspect Alice's destination.

delusional 1y ago
I agree with this in general. In specific though: > We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case. Seems incorrect. Bob could publish a single key without any indication of what is behind that key. Alice would get that key (from DNS), but since it was just for talking with Bob in general, nobody knows what Bob has. Alice and Bob are then free to talk about their trans rights. The particular point is that there's no reason the middlebox would even know there is a subdomain called trans-rights.bob.example.
- tialaramex 1y ago
  There are great number of ways in which the operators of the middlebox might come to know that Bob publishes this blog. Most obviously the humans charged with setting up such tech might literally find out in the ordinary course of their life that they ought to add this rule. Fox News show headline "Ban this sick filth", a letter from the Government about "Extremist sites unsuitable for your employees", and so on. But technologically there could be a list, maybe a "Ministry of Truth" provides the list of providers who are forbidden, it needn't say why, and if it does say it could lie, usually such lists are (like spam blackholing) automated and unsupervised. They could search the "Passive DNS" system to find suspicious names and block the entire provider, or likewise with Certificate Transparency. So alas there are reasons the middlebox might be configured this way.