Hacker News Reader

Comment by JorgeGT | Hacker News Reader

Nice, it appears that my parent's ISP is doing DPI and a MiTM attack to block Sci-Hub (and I do have a subscription to Nature).

View on HN

Use the Telegram bot @scihubot, that will probably evade the DPI trap. Just send the DOI or the full article name to this bot and you'l either get a PDF back or a message about the article not yet being in the database.

my ISP's DNS resolver just returns NXDOMAIN for that.

     $ dig @8.8.8.8 sci-hub.se. +short
     186.2.163.219

what happens if you try the .st TLD?

.se is Sweden, I was surprised to see that they haven't taken down sci-hub.

sci-hub.st works here (Telekom in Germany).

Is it possible they are simply blocking DNS or the IP(s)?

MiTM should be impossible on HTTPS - if they somehow obtained legitimate certs for sci-hub , you should really announce someone at Mozilla and/or Google.

Sometimes people use the phrase mitm loosely to mean sniffing SNI and then blocking the connection in some fashion.

Apologies if the usage is incorrect. They appear to indeed sniff the SNI and then inject a one-line website with a self-signed certificate: https://pastebin.com/RHwPWBug

Thanks both for taking the time to acknowledge and explain the subtlety. Helps somebody like me who’s casually following along to better understand both scenarios.

Its still possible that instead they are just hijacking the ip space. You could probably distinguish by running traceroute. Or doing something like curl https://186.2.163.219 --header "host: sci-hub.se" -k (which should not send an SNI that can be sniffed but still send the corect host header inside the encrypted http stream so the connection would work minus a cert failure, but DPI by the isp wouldnt be able to detect. If that curl fails they are probably doing ip address hijacking. If domain-fronting request works then they are probably sniffing SNI)

Good idea! I tried the domain-fronting curl request and it works, so they seem to be indeed sniffing the SNI...

They appear to do deep packet inspection looking at the SNI and insert an invalid certificate from Allot, redirecting the connection to a very short "Vodafone can't show you this" website: https://pastebin.com/RHwPWBug

It appears to work with ESNI activated in Firefox. Interesting to see these techniques in use...

> Por causas ajenas a Vodafone, esta web no esta disponible

"Due to causes independent on Vodafone, this website is not available".

How so? This is plain false. I bet they do not even inform their customers that the connectivity service they sell is endangered by Deep Packet Inspection.

That just means the decision to block the site was made by someone outside of Vodafone. Assuming they face meaningful penalties for noncompliance, I wouldn't consider it false. But it would be nice if these kinds of messages identified who is to blame.

Virgin Media give you a message for blocked porn, but not the VPNs they stop you accessing.

It's quite insidious - the VPN blocks are textbook government overreach.

If we ever have a written constitution in the UK we need rules stopping the government fucking about with this stuff (As it seems to be the entropic end-state of all policy to protect the children)

That isn't true except for the case of cert pinning. This sort of MiTM (or redirection at the very least) reglarly happens from employers, isps, and many others.

I'm amazed that my comment was downvoted on a tech board, where presumably people are informed about these things.

Of course TLS connections are regularly inspected. A simple google search will show you edge boxes you can purchased to perform this on your network. IT people know all about this. No, this does not mean that the cryptography used by TLS has been broken.

ISPs can't deeply inspect TLS traffic. Employers of course can, because they can insert their own trusted certificates on their own boxes.

Now, if by 'inspect' or MITM in this case you are talking about inspecting the TLS headers, that's possible, and based on the other comments it is exactly what this ISP was doing - checking the SNI of the TLS requests and blocking based on those.

But an ISP that hasn't somehow broken TLS isn't in a position to check the encrypted contents of your packets (e.g. HTTP headers, bodies etc). Your employer can very well have installed a TLS MITM device that is trusted by your company-issued device to actually inspect the contents of your encrypted packets (by acting as a proxy - you actually have a TLS tunnel with the MITM device, and it has a separate tunnel with the TLS server).

Certificate pinning can block even these types of employer MITM inspection, and it can also protect from rogue CAs issuing ilicit certs. But if your ISP is in possession of PKI certs for google.com and outlook.com, then the CA that issued them will soon be removed from the trusted list.

You didn't read my comment that is right next to yours. Or the one that you replied to, where I mentioned cert pinning. You are repeating my comments back to me.

The device does not always need to have a special trust relationship with the client browser, since a trust relationship can already exist with FTU.

Which ISP do you use?

It's Vodafone Spain.

Reply on news.ycombinator.com