5 ms·

Looks like the paper referenced is from May, if you have a subscription to Nature: https://www.nature.com/articles/s41586-020-2278-9 https://www.nature.com/arti

by zootm 6y ago

Looks like the paper referenced is from May, if you have a subscription to Nature: https://www.nature.com/articles/s41586-020-2278-9 https://www.nature.com/articles/s41586-020-2278-9

NieDzejkob 6y ago
If you do not have a subscription to Nature: https://sci-hub.se/https://www.nature.com/articles/s41586-020-2278-9 https://sci-hub.se/https://www.nature.com/articles/s41586-02...
- JorgeGT 6y ago
  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).
  - tsimionescu 6y ago
    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.
    - bawolff 6y ago
      Sometimes people use the phrase mitm loosely to mean sniffing SNI and then blocking the connection in some fashion.
      - JorgeGT 6y ago
        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 https://pastebin.com/RHwPWBug
        dwightgunning 6y ago
        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.
        bawolff 6y ago
        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 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)
        JorgeGT 6y ago
        Good idea! I tried the domain-fronting curl request and it works, so they seem to be indeed sniffing the SNI...
    - JorgeGT 6y ago
      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 https://pastebin.com/RHwPWBug It appears to work with ESNI activated in Firefox. Interesting to see these techniques in use...
      - muxator 6y ago
        > 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.
        mcbits 6y ago
        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.
        mhh__ 6y ago
        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)
    - IncRnd 6y ago
      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.
      - IncRnd 6y ago
        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.
      - tsimionescu 6y ago
        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.
        IncRnd 6y ago
        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.
  - perlgeek 6y ago
    my ISP's DNS resolver just returns NXDOMAIN for that. $ dig @8.8.8.8 sci-hub.se. +short 186.2.163.219
    - semi-extrinsic 6y ago
      what happens if you try the .st TLD? .se is Sweden, I was surprised to see that they haven't taken down sci-hub.
      - perlgeek 6y ago
        sci-hub.st works here (Telekom in Germany).
  - traceddd 6y ago
    Which ISP do you use?
    - JorgeGT 6y ago
      It's Vodafone Spain.
  - Yetanfou 6y ago
    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.
deleted 6y ago
[deleted]
hatmatrix 6y ago
And the accompanying overview/summary: https://www.nature.com/articles/d41586-020-01455-w https://www.nature.com/articles/d41586-020-01455-w

by zootm 6y ago

Looks like the paper referenced is from May, if you have a subscription to Nature: https://www.nature.com/articles/s41586-020-2278-9 https://www.nature.com/articles/s41586-020-2278-9

NieDzejkob 6y ago

If you do not have a subscription to Nature: https://sci-hub.se/https://www.nature.com/articles/s41586-020-2278-9 https://sci-hub.se/https://www.nature.com/articles/s41586-02...

JorgeGT 6y ago
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).
- tsimionescu 6y ago
  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.
  - bawolff 6y ago
    Sometimes people use the phrase mitm loosely to mean sniffing SNI and then blocking the connection in some fashion.
    - JorgeGT 6y ago
      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 https://pastebin.com/RHwPWBug
      - dwightgunning 6y ago
        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.
      - bawolff 6y ago
        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 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)
        JorgeGT 6y ago
        Good idea! I tried the domain-fronting curl request and it works, so they seem to be indeed sniffing the SNI...
  - JorgeGT 6y ago
    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 https://pastebin.com/RHwPWBug It appears to work with ESNI activated in Firefox. Interesting to see these techniques in use...
    - muxator 6y ago
      > 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.
      - mcbits 6y ago
        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.
      - mhh__ 6y ago
        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)
  - IncRnd 6y ago
    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.
    - IncRnd 6y ago
      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.
    - tsimionescu 6y ago
      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.
      - IncRnd 6y ago
        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.
- perlgeek 6y ago
  my ISP's DNS resolver just returns NXDOMAIN for that. $ dig @8.8.8.8 sci-hub.se. +short 186.2.163.219
  - semi-extrinsic 6y ago
    what happens if you try the .st TLD? .se is Sweden, I was surprised to see that they haven't taken down sci-hub.
    - perlgeek 6y ago
      sci-hub.st works here (Telekom in Germany).
- traceddd 6y ago
  Which ISP do you use?
  - JorgeGT 6y ago
    It's Vodafone Spain.
- Yetanfou 6y ago
  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.

deleted 6y ago

[deleted]

hatmatrix 6y ago

And the accompanying overview/summary: https://www.nature.com/articles/d41586-020-01455-w https://www.nature.com/articles/d41586-020-01455-w