5 ms·
> Since fast.com is a Netflix ip, and the isp can’t distinguish whether it’s video that is being transferred or a file to measure throughout, It is really triv
by bscphil 4y ago
> Since fast.com is a Netflix ip, and the isp can’t distinguish whether it’s video that is being transferred or a file to measure throughout,
It is really trivial to do basic traffic snooping and see what people are looking at. I'm surprised it isn't more common.
I figured it would be harder, or perform worse, but I easily wrote a little piece of software that filters the TLS ClientHello for arbitrary domains. Maybe 10 years ago hardware wouldn't have been able to do this, but I bet it's no big deal now. So your filter chain just looks like <Netflix IP range> -> <has fast.com ClientHello> -> unthrottle. You don't need to do packet inspection on every packet, just ones that you might be interested in (e.g. Netflix IPs).
It's crazy to me that the many people who care about privacy and censorship in tech haven't pushed ECH (encrypted ClientHello) harder. It's such a gaping hole in web privacy that you can still passively snoop domain names sent in cleartext. It makes DoH/DoT almost pointless.
- xyzzy_plugh 4y agoThis isn't applicable to fast.com as it simply makes requests to Netflix's CDN from the frontend. Indistinguishable from regular Netflix traffic.
- bscphil 4y agoGood point, although you could still do logic like only activating the throttle after the customer visits netflix.com. You can't distinguish the CDN traffic, but you can still tell what website is being viewed. Incidentally, my speeds on fast.com are always terrible (about 1/8 of what I get elsewhere), despite the fact that I'm fairly confident it is not being throttled. That's because the speed I see is >100 Mbps, which is like 4 Netflix UHD streams. Wouldn't be much point in throttling to that speed, you'd want 10 Mbps max, and less on wireless.
- the456gamer 4y agothen you might miss embedded clients, right?
- hedora 4y agoPeople drastically overestimate the security properties of TLS. The correct mental model is that it’s good enough to convince 1990’s US internet users to type their credit card into a web page. (Where the downside of a breach is that you have to dispute some charges and change your CC#.) If you need stronger security than that, then many, many caveats start to apply. For instance, by default, anyone that can reliably man-in-the-middle port 80 on your website can get an acme certificate for your domain from a reputable certificate authority.
- boosteri 4y agoIs there more on this mitm cert spoofing somewhere I can read up on? Sounds intriguing to say the least
- james-revisoai 4y agoIt probably isn't too different from other access methods: 1) Get access to port 80 for > 60 seconds. Point it at your temporary VM. 2) Use any cert authority, and for verification, choose a file-specific location verification (you can choose amongst DNS records, an email to admin@domain, or a specific file location on your site with many of them) 3) On your VM, Quickly paste the file-specific location into a django GET route. 4) Run the Django site on port 80. 5) The cert authority verifies you, and emails your account the cert, the website author being none the wiser. You can now use it later to fool future visitors for a deeper attack or email-related attacks.
- Spivak 4y agoThis doesn't work unless the attacker happens to be in between your servers and the cert authority. The ISP that's in-between your laptop and the site can't pull this trick. Also LE actually knows this attack is possible and mitigates it by validating the challenge from multiple sources so the attacker would need to be in the middle of all the LE validators and your servers. https://portswigger.net/daily-swig/lets-encrypt-deploys-new-domain-validation-technology-to-mitigate-bgp-hijacking-risks https://portswigger.net/daily-swig/lets-encrypt-deploys-new-...
- jeroenhd 4y agoFast.com loads from nflxvideo.net for me. They have a /speedtest/ path. Sure, they could apply some kind of advanced DPI assessment based on packets sizes over time and other crap, but if anyone complains it's much easier to just say "well, does speedtest.net work? What about Google's speedtest? Hmm, strange, must be fast.com being slow then!". If they just check for fast.com in the SNI header, I know I'd be loading the speedtest every time I want to watch Netflix. ECH is slowly coming along, but it's still perfectly possible to detect these speed tests. It just takes much more time and effort to set up right. I'm honestly surprised the article shows enabling a VPN actually working to fix the messed up network here. That would be a perfectly valid solution in my opinion; if I notice my ISP is messing with my network like this, there's no way I trust them enough not to use a VPN.
- bradknowles 4y agoAT&T is well know for doing deep packet inspection so that they can properly throttle NetFlix. They are always at the top of the list of Net Neutrality violators that Netflix complains about.