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:
- HTTPS is used for the request. If HTTP is used, then the ISP can control anything.
- 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.
- 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.
- 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.