It seems to me that "yes, they can". As I saw it in some countries, entering adult content will simply give a warning message that the site is blocked. Some places even block Facebook similarly.

If yes, then technically, ISPs can steal a website's users data by altering legitimate HTML and JavaScript with bad HTML, JavaScript, HTTP headers, CORS headers to send data in cookie/localstorage to https://somewhereelse.example.com.

Note 1: This is just some imaginary situation

Note 2: HTTPS is used as a standard nowadays.

  • 6
    Very similar things to your imaginary situation have been done. Commented Aug 13, 2020 at 2:57
  • 1
    Just want to point out that an encrypted VPN blocks the ISP from doing this. (As long as the ISP lets you connect with the VPN in the first place.)
    – Vincent
    Commented Aug 14, 2020 at 0:37
  • 1
    With "ISP", do you mean the Internet Service Provider of the user, or the ISP which hosts the website? Facebook is of course big enough to host its own site, but most websites are small sites and rely on an ISP for hosting..
    – MSalters
    Commented Aug 14, 2020 at 10:20
  • But then the VPN provider can do it instead.
    – OrangeDog
    Commented Aug 14, 2020 at 11:17
  • Yes. In Russia, mobile ISPs sometimes put advertisements at the top/bottom of HTML pages.
    – Sauron
    Commented Aug 15, 2020 at 19:27

3 Answers 3


Your ISP is per definition a MITM (man-in-the-middle) and therefore can serve you any content it desires.

You mentioned HTTPS and this is of course a game changer. Yes, the ISP can server any arbitrary content when you access e.g. Facebook, but it does not have access to the private server certificate of Facebook and your browser will detect that it is not speaking to the correct server.

Now comes the critical part - the user will get a warning and has to decide what to do with it. If the user ignores the warning and tells the browser to load the fake website nevertheless, the browser will comply. A security aware user will realize that something strange is going on, leave the site and maybe even investigate further.

This means, your ISP can serve any content it likes, but as long as you are using state-of-the-art TLS encryption and validate server certificates, you have the ability to detect that some tampering took place.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Aug 13, 2020 at 16:58
  • ... provided your ISP hasn't added their own root certificates to your installation
    – JCRM
    Commented Aug 15, 2020 at 9:50
  • 1
    @JCRM: Which would require giving them physical access to your computer or yourself running malware that they supplied. Commented Aug 15, 2020 at 19:49
  • ISPs don't ususally call their installation package malware @R..GitHubSTOPHELPINGICE
    – JCRM
    Commented Aug 17, 2020 at 7:55
  • 1
    I've never had an ISP with an "installation package". I'm aware that some have such nonsense, but it's been standard knowledge that you don't touch that stuff for decades. Commented Aug 17, 2020 at 14:13

Yes, they can. The important part is HTTP is still the default protocol in 2020.

Most sites use HTTPS today, but it works by first doing an insecure request which will redirect to HTTPS.

This means, since the ISP controls the default DNS server, the ISP can point to their own reverse proxy with their DNS server. This reverse proxy can do any manipulation you like.

It will of course be shown as "Not secure" in your browser, but you won't get the big scary certificate error.

This won't work for sites registered in the HSTS preload list (most or all of the big sites are), or if the user has visited the site before and the site has HSTS enabled.

  • 3
    "it works by first doing an insecure request which will redirect to HTTPS" - That's not how HTTPS works, and it only happens if you type "http://" and the site doesn't use HSTS or you've never visited it before.
    – OrangeDog
    Commented Aug 14, 2020 at 11:16
  • @OrangeDog that is how web browsers work without HSTS like I wrote in my answer Commented Aug 14, 2020 at 11:27
  • @EsbenSkovPedersen only if you type "http://"
    – OrangeDog
    Commented Aug 14, 2020 at 11:46
  • 7
    @OrangeDog not true, here I typed bbc.co.uk in my browser, and you can see chrome first makes the first request with http imgur.com/a/HwxXyVg Commented Aug 14, 2020 at 11:57
  • 4
    However, what @Esben is getting at is that most users don't enter scheme prefixes. They type "contoso.com" (or even just "contoso") into the url bar. In the first case, the browser will make an insecure request to contoso.com, which will usually (if contoso prefers https) redirect to the https version of the site. (In the second case, the browser these days will interpret the word as a search term, and make an https request to google, bing, or similar, and send your search term to it. The user will usually then click the first link to get to https://contoso.com/
    – Stobor
    Commented Aug 15, 2020 at 12:57

Your ISP has complete control over traffic served. They can't tamper with any traffic without it being detected given the following conditions are true:

  1. HTTPS is used for the request. If HTTP is used, then the ISP can control anything.
  2. HTTPS traffic is allowed to the server. The ISP can refuse to forward secure traffic, pushing the user into choosing between accessing insecurely with the ISPs tampering, or not accessing the site at all.
  3. The Certificate is securely validated. If the certificate is not validated securely, then the ISP can impersonate the web server, and there is nothing the web server can do.
  4. The information the ISP wants is not located in the metadata (Subject alternative name, server IP etc).

For the first condition. Requesting using HTTP is still the default for many configurations, as the browser does not know if the site supports HTTPS outside limited conditions. Outside those limited conditions, the browser can not tell an ISP that is actively blocking HTTPS and tampering with HTTP requests from a site that does not support HTTP, so errors on the side of supporting existing sites. Those limited conditions are if a site is on the HSTS preload list (notable the .bank, .insurance, .dev, and .app tlds are on the list), or the user has previously visited the site on a non malicious connection to retrieve HSTS headers. Alternatively the user may have set there browser up (such as using the HTTPS everywhere extension) to disable the HTTP fallback.

For the second. If the ISP blocks the site, then for either a user may decide to accept the ISPs tampering in exchange for any service at all. Particularly if the user doesn't understand the risks, or relys on the ISP for IT support, this could easily happen.

The certificate is securely validated: This is the biggest weak point. The validation process relies on the user having a set of trusted CAs, which can be trusted such that any certificate they issue for almost any domain authenticates that domain. Any user/program with admin rights on a computer can install additional CA certificates, and this is common to see in corporate filtering environments. If an additional certificate is installed the issuing entity has the ability to impersonate any site. Kazakhstan has been attempting this at a government scale. This could be done by the ISP without the users understanding in the form of some form of parental controls or similar tooling.

Additionally the system uses complex code to parse and validate the certificate. Bugs are regularly found in this code and a malicious ISP could potentially exploit one.

Finally the metadata. In order to allow the request to be routed to its destination correctly, and because the ISP can clearly see and control all attempts at name resolution, the ISP can see exactly which site the user is attempting to connect to, even if they can't see the page. This may be enough to allow blanket blocking of certain categories of site. For example, facebook could be blocked by blocking all requests to facebock.com. This does not allow tampering.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .