Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> A lot of enterprises, operators and organizations block or rate-limit UDP traffic

That was my first thought, and the following seem to be assuming that companies will decide to change their policy. But many public WiFi block UDP traffic, are they going to change their policy? Are the people in charge of it even aware about it? (Think coffee shops, restaurants, hotels, ...) Are we going to have websites supporting legacy protocols ("virtually forever") in order to build a highly available internet?

Also, ISPs in some countries have not been UDP-friendly. I'm thinking about China mainly, where UDP traffic if being throttled and often blocked (connection shutdown) if the volume of traffic is consequent - I assume they apply this policy to block fast VPNs. Are they going to change their policy? Worst scenario here, would be to see a new http-like protocol coming out in China, resulting in an even larger segmentation of the internet



Working in a school I block QUIC traffic so my web filter can (attempt to) keep kids off porn. Such filtering is required by law for schools. I haven't found a passive filter that handles QUIC. I don't want to install invasive client software or MITM connections.


There won't ever be a passive filter. The QUIC traffic is deliberately opaque.

If you control the clients you may be able to retain your status quo for some time (by just refusing to upgrade) but the direction is away from having anything filterable. So client software or MITM are your only options.


I've seen it coming for a while. I'll have to decide which is the lesser evil: blocking QUIC/HTTP3 or using MITM.


How do you handle regular old HTTPS?


The filter looks at the SNI header during the TLS handshake. If it doesn't like the host it will reset the connection.


Does this mean you block all of Wikipedia? And what will you do once encrypted SNI becomes popular?


I don't block Wikipedia. I looked at some wire traffic and I can see the SNI header as normal in Firefox 67 and Chrome 72. I found a about:config flag to enable esni, toggled it, restarted the browser, and I still see the SNI. Using Cloudflare's ESNI checker it says my browser isn't using it.

Ignoring ESNI will probably work fine for a good length of time. If pornhub implements it or something I'd probably have to revisit. Or, since I control the clients I might disable it in their browsers.

If enough people bark up the filter vendor's tree I'm sure they'll add a checkbox to drop esni traffic. They added one for QUIC recently.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: