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.

Maybe this is why it reduced and stopped over the years. I'm not as knowledgeable in contemporary HTTPS and its capabilities, probably.

Because I'm pretty sure that happened.

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.

can you explain further?

Two things have happened in the past.

Scenario a:

1. Navigate to https://www.example.com

2. Arrive at https://www.completelyunrelated-adsite.com while your address bar reads https://www.example.com

They used to do this regardless of your DNS. They directly hijacked that stream/connection.

Scenario b:

1. Navigate to https://www.example.com

2. Get https://www.example.com with an ad-banner on top.

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)

It's possible if the connection goes through an http proxy.