8

Lately I've noticed that pages I go to on http sometimes have a large banner at the top from my ISP. What's weird is when I refresh the pages I get the https version of the site and the banner is not there. I try to type the http version into the address bar but when I click enter I get the https version. The network tab in developer tools shows 301 moved permanently when putting in the http version and then I get redirected the https version.

So I'm a bit surprised by how I get this banner. How is the ISP able to inject the banner + display the original site underneath the banner? See below screenshot. I would have assumed that the fact the page was redirected to https, that an ISP wouldn't be able to display the page with a banner? What's going on here?

Note: My dns defaults to 1.1.1.1 and 1.0.0.1 (both cloudflare)

enter image description here

Terence Chow
  • 215
  • 1
  • 5

2 Answers2

9

Your screenshot shows an HTTP ("Not Secure") page, not HTTPS. Your ISP essentially pulled an "SSL Stripping" attack on you; they blocked you from getting the redirect, fetched the HTTPS version of the site themselves, slapped their own content on top of the retrieved HTML, and then returned the modified HTML to you in response to your original HTTP request. They also stored (either on their side or in a browser cookie on yours) the fact that you'd seen the banner, so future requests to that site got redirected to HTTPS without any content being injected.

Remember, your ISP controls everything going between your computer and the Internet. If the connection is already encrypted (HTTPS), there's less they can do (they can cut the connection, they can probably tell what site you're requesting, they can tell how long your request and response are, they can try to spoof the server and hope you click through the certificate error message), but on an unencrypted connection they can do whatever they want. Modify the response, suppress parts of the response, add their own content, redirect you, prevent a redirect, outright impersonate the server...

Also, DNS requests and responses are (usually) sent unsecured. The ISP can do whatever they like there, too. It doesn't matter what server you send your DNS request to; if it's on the Internet, your ISP can see and tamper with it.

Bear in mind, all of the above also applies to a local network attacker (somebody on the same LAN as you, possibly at a business, home, or public WiFi) if they can get a man-in-the-middle position (and it's usually easy).

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • "they can try to spoof the server and hope you click through the certificate error message", what would be the effect of this ? – Deunis Nov 15 '19 at 09:06
  • @Deunis It would allow them to impersonate the server, bypassing the authentication that is part of the TLS handshake. At that point, from their perspective, you might as well not be using HTTPS at all; they can once again read, modify, spoof, and delete content at will. – CBHacking Nov 15 '19 at 18:16
  • 1
    *"DNS requests and responses are (usually) sent secured"* Do you mean "unsecure"? – nobody Dec 21 '20 at 12:04
  • Thanks @nobody, that's what I get for "fixing" old responses at 4AM... – CBHacking Dec 21 '20 at 12:29
-3

ISP is in control of of the content sent to you so I don't understand how it should be too crazy they are able to do this.

An ISP can examine your traffic... They have to be able to see at the very least the IP address of where you are sending a packet so it can make it to its destination. HTTPS connections are initiated with a handshake where a handshake packet is sent to a destination routed through the internet and a response is sent allowing for identification and creation of means for a secure channel of communication. Stackoverflow https packet visibility - HTTPS RFC2818 - S-HTTP

If your ISP were to tamper with this handshake by sitting in the middle of the connection and impersonating both parties then it is possible for them to accomplish what you said above. ISP man in the middle

Let's say you have a malicious ISP. They set up a fake internet in front of your internet. So you try a TSL handshake with 64.233.185.113 google.com. They start a TSL handshake with you from this ip, decrypt your packets send them to google whom they started a TSL handshake with after you connected to the fake site. Now you are receiving real google content through the ISP man in the middle proxy. When a browser sees fishy certificates it will normally warn you with something like this. In your image above the connection says "Not Secure" this could imply you clicked something a different time saying even though this certificate is bad I'm choosing to trust it, allowing you to proceed to the site. It is really the browser that handles that.

Some things to try to mitigate the problem.

  • Use a Proxy. If you have a trusted friend who will allow you to connect to their server and route your packets through their ISP. socks-proxy If the banner disappears on a different ISP then it tells you the network not your computer is the issue.

  • If your browser is at fault or compromised you could try installing a new browser or try deleting all add-ons and extensions. can-google-chrome-browser-extensions-be-dangerous

  • Checking DNS, I still believe it is worth checking to make sure DNS hijacking is not involved. DNS hijacking scenario DNS manipulation is often used in MITM attacks. Man in the middle Cloudfare

Community
  • 1
Michael Hearn
  • 103
  • 3
  • 1
    Does it make a difference if the `http` request responds with a redirect to `https`? The content lives on the `https` site, so the fact that the `https` content appears on a url that is `http` (underneath their ad) is what surprises me. Does this mean they are setting an iframe that is requesting the https site but above the iframe they put their ad? I don't recall seeing an iframe but i'll inspect the html next time again to confirm. Also my DNS was already set to 1.1.1.1 (cloudflare) so not sure how this is happening. – Terence Chow Nov 15 '19 at 03:17
  • They don't have to use an iframe the isp owns the wire that delivers your content. Many sites redirect http-> https so its hard to say. – Michael Hearn Nov 15 '19 at 06:02
  • Sorry, but I have to downvote. This sentence is incorrect: _"A ISP can examine your traffic."_. HTTPS (and more generally TLS) is specifically designed to prevent this. When you have an HTTPS connection, there is end-to-end encryption between your browser an the site you are visiting. Your ISP (or any other router that your traffic passes over) can not see or modify the content of your traffic, other than the IP address, which it needs to know in order to route it properly. – Mike Ounsworth Nov 15 '19 at 20:45
  • @MikeOunsworth A police officer can examine you in traffic it doesn't mean they know what's in the car. How can a ISP route your packet if they don't have some concept of being able to "examine" it. – Michael Hearn Nov 15 '19 at 20:52
  • 1
    A better analogy would be _"How can the postal service deliver your credit card statement without opening and reading it?"_. They can because your address is on the outside of the envelope. Similarly, all the routing information like the IP address is on the outside of a TCP packet; the payload (like the contents of the website you're loading) is in an encrypted inner part of the packet. – Mike Ounsworth Nov 15 '19 at 21:32
  • Inspecting IP header info is a radically different thing from manipulating application layer content. – schroeder Nov 16 '19 at 09:25