So the way it works is that if you have a setup like so: Your client <-- bad actor --> Public Webserver.

Your first layer of defense is assuming its hard for a bad actor to get to that spot (which this attack is showing is possible).

Now the next thing the bad actor needs to do to compromise your traffic is deal with HTTPS/VPN. The only real way to do that would have to be to convince your client that the certificate from the CA that's signing the https traffic received from the webserver/VPN provider is trusted/ (i.e a classic MITM with a compromised client and a local CA).

Most clients will warn you that this cert is unrecognized, so with an untampered client unless you just clickthrough the cert warnings you will be protected. However, people often ignore cert warnings and that means that all your traffic is now cleartext for the bad actor.

Technically I think it depends on whether someone can mess with your connection enough to convince the browser to fall back to HTTP. And whether you could be tricked into entering credentials on the wrong page.

Your data is safe, but you can be prevented from connecting at all.

How does your VPN handle having its connections blocked by an adversary in the middle?

Does it “fail open”? Or silently fail? Does it alert the user?

Does anything on your device use non-TLS? Software updaters? Are they susceptible to downgrade/fallback attacks?

When I last properly explored this I found a good number of automatic software updaters would fall back to plaintext HTTP (or just didn’t use TLS) and often didn’t perform much or any signature checking on updates.

Yes