> looking at the number of bytes moved in the sessions is sufficient to > determine which firmwares were selected and downloaded.
Theo, I may be completely wrong here (please excuse my ignorance if it is the case), but I see it this way: On a shared server (or one fronted by a CDN) on the same pool of IPs there are lots of domains hosted (at cdn.openbsd.org right now there are 140 domains of which 63 are wildcards and they are shuffled all the time), they could have infinite amount of files. With ESNI there's no way to know which domain we are requesting, so we could be downloading/requesting anything (files and dynamic content, RTC, streaming) from hundreds of unrelated domains. On top of this, if we use HTTP/2 multiplexing and request all the firmware binaries over the same connection, the exact size wouldn't be known either. You can add additional obfuscations if needed, like randomly mix-querying small files over the same multiplexed connection. I know tls1.3 is not there yet in LibreSSL and ESNI is at draft-04 at this moment, but I'm not talking about an immediate fully-DPI-resistant deployment. All CloudFlare hosted domains are with ESNI already for a year [1] and ff has it in nightly. OpenSSL, Fastly, Apple and Google are also working on it, there's a fairly good interop testing ground. My question was about why not to cloud-front-with-https (like cdn.openbsd.org is) the firmware sub-domain too (or cdn.firmware.openbsd.org). Just my 2-cents-IMO :) Regards, Anatoli [1] https://blog.cloudflare.com/encrypted-sni/ On 7/10/19 15:38, Theo de Raadt wrote: > Anatoli <m...@anatoli.ws> wrote: > >> And thank you for your detailed explanation about the certs for firmware >> sub-domain. Just wanted to say that IMO there's actually one thing that >> it would solve: the privacy of the requests, i.e. we wouldn't be leaking >> info about our devices with proprietary fw to anyone listening on the >> wires. But I see it's a considerable effort to set it up. I already know >> whom to contact to collaborate with the infrastructure. > > oh really, https solves that?? > > Sorry to burst your bubble, but looking at the number of bytes moved in > the sessions is sufficient to determine which firmwares were selected > and downloaded. >
