Hacker News Reader

Comment by roboben | Hacker News Reader

How do ISPs do a page in front of their service? Do they have a DNS blacklist, resolve to their servers first and then let the users pass when accepting? How is this acceptance working and persisted?

And could you not circumvent this by either using another DNS provider?

View on HN

ISPs in the UK mitm TLS connections and use SNI sniffing in order to block banned sites. You can see this is happening by either visiting a banned site and seeing the connection being reset after the client hello is sent or you can check the TCP SYN packet your client sends on 443 vs the TCP packet the server receives. Oddly enough on the O2 network they are not simply sniffing the packets on the wire but doing a full TCP proxy because the TCP syn packet has been heavily rewritten. For example when using an iPhone the order of the SYN flags is very different from Linux. the SYN packet the server receives will look like it came from Linux even though it originated from an iPhone. This is not what you would expect if they were just doing normal NAT.

What do you mean by the order of the SYN flags?

I meant the order of the TCP options.

For IPv4 the SYN flag is a single bit in the packet at a fixed location. So to say the 'order' is 'very different' does not make any sense.

I misdescribed how you can detect the OS from the TCP packet with the SYN flag set. The order of the TCP options is often different between different OSs.

Wouldn't you need to trust their certificate?

You don't need the certificate to drop connections, it only comes into play if you're trying to impersonate an endpoint.

benmmurphy specifically said mitm. jonas-w is correct that this cannot be done as it would require a root certificate.

I said MITM reading the client hello and using SNI sniffing. They are fully rewriting TCP flow not just what NAT does when they adjust the address and ports on the packets. I'm not exactly sure the reason for this. It could just be a technical choice they made. But it does make it easier to flip a switch to do a full MITM that includes decryption using root certificates or using protocol attacks to decrypt traffic.

> ISPs in the UK mitm TLS connections

They do not. As jonas-w points out, they would need a root certificate, which they don't have.

Much of the value of TLS is protection against untrustworthy ISPs.

Most mobile ISPs in the UK use Procera Networks (now Sandvine) products that do basic deep packet inspection to filter traffic.

You can allocate users to pools and provide contectivity based on the pool, ie allowing you to limit speeds of high usage users or have different filtering lists like this under 18s list.

With these devices you are able to block traffic to specific domains even if SSL is used with relative ease.

As it is done at network level, you can't bypass via different DNS provider, only vpns can bypass

Nothing can stop SNI sniffing & blocking except DNS with encrypted client hello.

Which is taking forever to be standardized.

It depends, but DNS lists are by far the most common, and you can indeed circumvent it by using another DNS server.

Changing DNS servers will not get around the UK ISP “adult content blocks” in my experience, but using a VPN will.

Generally it’s a good idea to disable ISP content blocking if you can, because they can cause all kinds of problems (slowdowns, false positives).

How do they do that? IP Lists?

Probably TLS SNI inspection

Huh. I thought that was encrypted, but apparently we aren’t ESNI yet.

I can get around Sky Broadband's block on Libgen by just using Libgen's IP, for example.

Wouldn't they just block outside DNS?

They can't block a customer-premises recursive resolver. But the SNI is on the TCP connection, not the DNS request; if you have that sort of ISP, they can filter based on SNI.

Why would the location of the DNS resolver matter? If I am running a local DNS resolver, presumably it recurses to an outside DNs server. If my ISP blocks that, I can't use it.

It recurses to the root, and then down the tree. So yes - the final query is a lookup for the name you are targeting, and yes, it goes through your ISP, like all your other traffic.

But it doesn't go through your ISPs DNS infrastructure, it goes direct to the nameserver for the parent domain. And even that doesn't happen if your local resolver has the result cached. The easiest way to block DNS lookups is at the DNS server; using DPI to block DNS lookups is straying into sledgehammer/nut territory.

Yeah, but isn't that laughably easy to block such a scheme? If a packet is destined for port 53 that isn't the ISPs DNS server, poof it's gone!

Or just redirect any outbound port-53 traffic to the ISP's DNS which will pretend to be the server you're talking to while silently applying the filtering.

You're right; that's a very simple firewall rule. But if I can't access a working DNS server over the internet, then I don't have internet service, and whatever kind of provider I have, it's not an "internet service provider".

Each ISP get's to make its own rules, but its the norm where I've lived to have some services blocked. For example, my ISP blocks GRE. At least one in the past I had blocked inbound SMTP & DNS.

Fine. I just don't call that "internet service". That's some kind of walled-garden internet-lite, conceptually the same as the old AOL.

Even with secure DNS, the SNI part is passed as plain text for the ISP to intercept and block.

In short (and from my own layman understanding as networking is not my strong suit) the packets still go through the ISP and can be analysed - data contents itself not as much with encryption, but they can still often figure out the destination.

Reply on news.ycombinator.com