So that middlemen can’t spy on which part of the blog you’re visiting / alter the content of the blog / inject ads. There’s also all sorts of vulnerabilities that crop up if you use HTTP and HTTPS on the same site.
All of this was present in the 90s and early 2000s so not really theoretical attacks.
Unless the ISP forces the use of its own Certificate Authority on its users, this isn't possible. TLS and the infrastructure surrounding it were designed with integrity of the connection in mind. Knowing this, I would be very curious to know what specifically you encountered and where. I see you added some details elsewhere, but it still doesn't jive with how TLS works.
Our ISP doesn't force MITM certificates, but used to try to mess with the retrieved pages sporadically with stream-hijacks (you navigate to HN, and got greeted with a full page ad) or banner insertions, forcing connection to mixed status while keeping the inner frame HTTPS.
They're not doing this anymore, because I guess they now know how to use their DPI infra in useful ways to them.
My mobile carrier still injects stuff to HTTP pages, but doesn't mess with HTTPS ones, at least yet.
The overall connection will drop to "mixed status", but the inner frame will still be HTTPS.
My ISP used to do that when they started deploying DPI hardware as a technology demo. They'll hijack your traffic and inject full ads w/o redirection or added (bill) warning banners or ads sporadically to retrieved pages.
My mobile carrier sometimes injects SMS & Notifications arriving to my modem if they find the chance w/o disturbing the connection too much.
So, having a HTTPS connection doesn't make it tamper resistant, but tamper evident, at most.
> The overall connection will drop to "mixed status", but the inner frame will still be HTTPS.
That is not possible. You would get a cert mismatch error.
Consider what your browser does when you navigate to the page: it directly opens a TLS connection to port 443. There's nothing your ISP can do to force the browser to request the page using a non-TLS connection.
What might have happened, is that you might have carelessly typed the address in your URL bar without the "https://" prefix, as in "www.example.com"; for legacy historical reasons, most browsers (except IIRC some very old browsers from the dialup era, which always required an explicit URL scheme) treated that as if you had prefixed it with http:// (so it actually was the non-HTTPS "http://www.example.com" that you were using). Many sites would then redirect you to the HTTPS site, but your ISP could hijack the page before that redirect (since the redirect was not protected by HTTPS). Had you been careful to always prefix any address you type with "https://", there would be no initial non-HTTPS connection to hijack.
Afaik not actually possible in practice. Browsers these days will a) remember valid certs for a domain b) remember that a domain is HTTPS (no downgrades) c) sniff certificates based on crowdsourcing.
Yeah. I hope you realize though why there’s a stern castigation, on a particularly techy and security conscious forum, of using HTTP instead of HTTPS. People here both remember the problems and what’s been done to combat them. It’s discomforting to see backwards progress when so much has been done. Security isn’t purely a technical problem. It’s an educational one too.
They happened rarely, and never survived a reload or further navigation. They completely stopped after a while.
I have a 4G modem from my mobile carrier. They inject a info popup when I receive an SMS or any other notification' if they can manage it. It's very rare now, too.
Scenario A is impossible and has been impossible for as long as https has been a thing.
The only way it would be possible is if you installed a root cert from your ISP onto your computer so that it would trust a cert issued by them. Otherwise, they would not have a valid cert for example.com and you would be presented with a cert error.
This is literally the exact thing https was designed to prevent. It is and always has been impossible (again, unless the client machine is administered by the ISP or whoever the middleman is, and they can install a cert on the machine)
All of this was present in the 90s and early 2000s so not really theoretical attacks.