Hacker News Reader

Comment by Bedon292 | Hacker News Reader

The urls that are used for the streams are pretty well known, and can limit all traffic on those URLS to specific speeds. Here are a few for example:

Twitch: *.ttvnw.net

Netflix: *.nflxvideo.net

Hulu: *.hulustream.com

YouTube: *.googlevideo.com

Amazon Prime: *.aiv-cdn.net

Edit: This is by no means the only way to do it, just a potential way to do it.

View on HN

This is mostly the correct answer, some creative Plex users with shitty cable ISP's (lookin at you Optimum) will run their connections through Cloudflare to avoid upstream throttling of video. It all looks like TLS traffic at the end of the day and since Cloudflare is probably the most common CDN, they can't apply rules to this range.

For mobile ISP's like T-Mobile, they cannot tell that video content is streamed through a VPN protocol like wireguard (but they could add large public providers to the list).

As a good rule of thumb I tell people to run speedtests from both speedtest.net (which is usually whitelisted by every provider) and fast.com (which usually shows up as Netflix video traffic) to see if 'video shaping' rules are in effect.

FYI Cloudflare terms of service (at least for free accounts) doesn't allow using it for video streaming purposes such as Plex:

https://community.cloudflare.com/t/is-plex-allowed/172158/5

Thanks for the update, previously (before 2020) it was believed that if caching was turned off and it was purely routing over Cloudflare, they wouldn't get pissy over the extra traffic. I guess this shows they will anyway.

Cloudflare gets pissy over a lot

Don't forget that Netflix has it's own CDN, so you could just throttle anything from that peering connection knowing that only video content is coming from it.

Oh, wait, they've already been doing that for <insert Gary Oldman> EVERYONE!</insert>

But isn't this over HTTPS? I know the DNS lookup may leak the domain, but that's heavily cached.

I think its just network analysis or possibly even those caching servers that are run by ISPs which hold onto content network's most heavily used files.

I see two possible ways:

1. during the TLS handshake, the domain name itself might be sent in the clear if the SNI extension is used, and if the SNI extension isn't encrypted[1]

2. if the carrier knows the IP, then they can do a reverse DNS lookup to find the domain name

[1] https://stackoverflow.com/questions/499591/are-https-urls-en...

SNI leaks the host name over HTTPS. Also, if the IP addresses are distinct enough they could be used to detect the destination as well.

Note that isn't the case any more with modern browser + server, TLS 1.3 Encrypted Client Hello (ECH) fixes this.

Last time I checked TLS Encrypted Client Hello standard was still under heavy development and implementation in Firefox was disabled by default. Is this not the case anymore?

IMO, it's a bad design... SNI encryption should be done by firewall, not the client.

My mistake, it seems to still be a draft standard

Both this draft and eSNI unfortunately are not widely in use.

But the provider knows where you are connecting, no matter if https is used or not. Https will encrypt the payload/data (layer 7) not where you are connecting (layers 3/4)

The packet header would leak that info too with src/dst IP addresses.

They likely have a peering setup with each of these companies, so they know the IP address ranges they're using for this video traffic. They can tag the traffic and shape it (drop packets in excess of some rate).

Would a vpn work around this?

Yes in my experience.

Yes, the challenge is some of those sites don’t allow streaming on a VPN.

If you have enough upload bandwidth, you could set up a VPN server at home.

Which is what I do. I run pfSense (will switch over someday to opnSense but its what I have now) and just use the built in OpenVPN server. Works very well.

Reply on news.ycombinator.com