> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
