Great comments and feedback. Thank you. Bret
Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Nov 14, 2017, at 10:43 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > > > >> On 14 Nov 2017, at 0:00, Tom Ritter <t...@ritter.vg> wrote: >> >> Are you also interested in collecting reports of where SNI is used to >> censor? Or the list of network vendors that support filtering and >> manipulating traffic based on the value? > > I don’t think naming and shaming is a goal here. > >> In general, the bad uses of SNI are harder to enumerate because people >> aren't willing to come to the WG and explain how they use SNI to >> selectively break or censor the internet for their citizens/users. > > I don’t think that’s true. I used to work for a vendor of a network firewall, > and I can explain how this is done. > > Inspecting the ClientHello to find the SNI for filtering is a weak way to do > filtering. It’s also a light-weight way. So if I want to filter Wikipedia, I > match SNIs to "*.wikipedia.org” and I have my filtering. Depending on how > many cycles I can spare, this is a cost-effective method. We have evidence > that it’s been used for filtering, but sophisticated users can circumvent > this - they can configure the browser to use TLS 1.0 and not send SNI at all. > > More modern firewalls make a probing connection to the server, sending a > ClientHello that is almost identical to the one sent by the real client and > checking the returned certificate. The names specified in that certificate > are used for the filtering. That information is cached so that not every real > ClientHello has to wait for a probing connection. I don’t know if any vendor > has made this scale to filter an entire country’s browsing, but this is > considered to be more reliable than filtering by SNI. > >> We >> have a few confirmed cases, anecdotal evidence, and lots of evidence >> of censors being technically applied by whatever means is available. >> >> But when you pile up all the administrators who will come to the WG >> and say "This really frustrates me and makes my job harder" you're >> going to have a much bigger pile than the users (or even technical >> advocates like myself) we can bring in and say "Plaintext SNI is >> harming the Internet”. > > IMO the real game-changer will be having an encrypted part to the > ClientHello. If all ClientHellos are different, this defeats caching. > >> >>> Side question, it feels like this effort could represent a lot of work and >>> require a lot of dedicated cycles. Does it make sense to continue this >>> effort inside of the TLS WG? If it does, will the WG give us the time, >>> mindshare, and cycles to focus on it (just asking the hard question)? >> >> In August we adopted the draft, so the answer is "Yes". >> >> -tom >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
