You can (try) to restrict your browsing to HTTPS sites only.

But it's very difficult to ensure that all the communications your device is making (background services, vendor apps...) go through that channel.

If only there were some certification body that ran an App Store with rules against unencrypted traffic...

This issue is two-fold right. You can install plugins that force SSL client side (on the main site and any AJAX calls thereafter) but like you said you have no idea what calls that site is making server side. They could be sending everything you send them over plaintext after the initial TLS secured request. Rough times.

Luckily, the servers past the initial SSL link won’t be using wifi, so at least you won’t be any worse off than before.

Or using a VPN.

It was quite nice to let a wifi router be the VPN client to offload it from all your laptops/phones/etc. and better guarantee "VPN always on".. so much for that.

Too bad DNS doesn't fall under properly protected against local attacks.

Fortunately, SSL/TLS (with HSTS) does not depend on your local DNS resolver being secure.

HSTS only works if you have visited the site before or it is hard coded (see Chrome and Google services for example).

Reality is that DNS remains and will continue to remain a giant hole in TLS.

All major browsers implement HSTS preloading, and getting added is quite simple. A very large percentage of your average internet user's traffic is covered by this.

Preloading is a problem waiting to happen. It works fine when only a small portion of the internet uses it. But when you have 2 GB preload file with a few billion entries things are not going to work so well.

The idea is to make HTTPS the default before that happens. In the meantime, you can fit a lot of domains into bloom filter-like data structures.

Fail-safe is indeed the preferred option here, yet the resulting Denial of Service is still unpleasant.