4 ms·

Yes, especially without eSNI (which is probably not that widely used, though I can't find good data one way or another), you can generally figure out that an IP

Yes, especially without eSNI (which is probably not that widely used, though I can't find good data one way or another), you can generally figure out that an IP address correlates with a specific website, but that's it. You don't know what they did on that website, you can't break their pseudonymity, etc.

tialaramex 2y ago
> which is probably not that widely used, though I can't find good data one way or another Which is exactly to be expected. If you could tell how widely it's actually used that's a problem. Encrypted Client Hello (the successor which was actually deployed) is GREASEd so that a client which could do ECH and a client which is doing ECH look the same to outsiders. The server knows which is which, but of course the server already knows that it enabled (or did not) ECH.
- kbolino 2y ago
  I did not know about ECH, but that makes sense. Glad to hear there's a better solution getting real adoption.
- gruez 2y ago
  You're assuming this information has to be collected by the ISPs, but it's very easily collected by browser makers (via telemetry) or by CDN/sites themselves. If either end of the TLS connection is collecting the data, there won't be the issue that you described.
  - tialaramex 2y ago
    That's correct. Either of them could collect telemetry on this. But, to what end? I expect that at some point one of the CDNs will want to advertise that this is a thing they offer. Once upon a time CDNs got a lot of blast for disliking the practice of claiming in TLS that you want some.ordinary.example as a way to conceal the reality that your HTTP transaction is for Host: censored.or.prohibited.example. One purpose of ECH is to enable them to deliver the same functionality but without all the technical problems. Now of course if they actually love censorship and so on, they'll do nothing, but it seems to me several big CDNs want to do this once they have a fix for the technical problems, which ECH gives them.

tialaramex 2y ago

> which is probably not that widely used, though I can't find good data one way or another Which is exactly to be expected. If you could tell how widely it's actually used that's a problem. Encrypted Client Hello (the successor which was actually deployed) is GREASEd so that a client which could do ECH and a client which is doing ECH look the same to outsiders. The server knows which is which, but of course the server already knows that it enabled (or did not) ECH.

kbolino 2y ago
I did not know about ECH, but that makes sense. Glad to hear there's a better solution getting real adoption.
gruez 2y ago
You're assuming this information has to be collected by the ISPs, but it's very easily collected by browser makers (via telemetry) or by CDN/sites themselves. If either end of the TLS connection is collecting the data, there won't be the issue that you described.
- tialaramex 2y ago
  That's correct. Either of them could collect telemetry on this. But, to what end? I expect that at some point one of the CDNs will want to advertise that this is a thing they offer. Once upon a time CDNs got a lot of blast for disliking the practice of claiming in TLS that you want some.ordinary.example as a way to conceal the reality that your HTTP transaction is for Host: censored.or.prohibited.example. One purpose of ECH is to enable them to deliver the same functionality but without all the technical problems. Now of course if they actually love censorship and so on, they'll do nothing, but it seems to me several big CDNs want to do this once they have a fix for the technical problems, which ECH gives them.