Paul Schreiber blogs about the tech behind the websites of presidential candidates. "So, you want to run a country. Can you hire someone who can run a website? ...Here's how the (declared) candidates' sites fare." There's a table comparing 4 candidates' sites based on HTTPS, URL permutations, IPv6, SSL rating, and other related qualities. Schreiber mentions that he will "update this as more candidates declare or sites change."
From the blog comments
HillaryClinton.com was using IIS (and no https) until Sunday morning, when they switched over.
Does HTTPS protect agains an ISP replacing HTML content in-transit?
There are many things HTTPS protects against (and yes, it does protect against the situation in your example). If any of those are important to you or your website, then use HTTPS on your site.
The point of my previous post was that HTTPS is by no means a panacea, particularly in its current form of foolishly-paranoid broswer defaults and CAs compromised by criminal governments.
With self signed certificates it only partially protects. If you've been to the site before, you'll know if there's a MItM attack. Unless te certificate has changed on the server. If you haven't you'll think your secure but won't necceraarily be.
Unlike with SSH, where I know of the very should have chaned, and I log in for the first time when connected on a secure network, with https there's arguably too many false positives from self signed Certs.
Using HTTPS with self-signed certificates is equivalent to using SSH with default key generation and settings.
In both cases, a new visitor/user does not generally have foreknowledge of the site's cryptographic fingerprints, and a man-in-the-middle attack is possible when the user lacks that knowledge.
The single reason for more "false positives" with HTTPS versus SSH fingerprints is that the typical default expiration dates set for HTTPS certificates are set a year or so out, versus no expiration dates for SSH credentials. I can think of no practical value to creating an HTTPS certificate with an expiration date (or, since I recall openssl demanding an expiration date, an expiration time closer than decades into the future) other than to generate revenue for "official" CA businesses that want to sell you a new certificate every year.
Unix-like servers store both types of credentials in the same manner (files on disk), so if you have no problem with servers using SSH, you should have no objection to servers using self-signed HTTPS certificates that effectively don't expire.
And if you want that level of security, browsers are finally offering a way to do it with HTTP opportunistic encryption. The browser vendors have decided that putting "HTTPS" in the URL means that some external authority (either a CA or the NSA ;) has verified that the server really is the right one for the domain.
I really have to ask... do people actually use SSH without verifying host keys? I guess I do for servers like GitHub, but for the vast majority of the servers I have access to, I verify the host key locally (or over a wired LAN at least) before using it over the internet.
And therein lies the rub. SSH and HTTPS credential verification are handled in the same fashion, and there's some level of required trust for the vast majority of users who do not have physical or local-network access to the servers they want to use encryption with.
The NSA and CA system are known threats/weaknesses as far as credential verification systems go, so the existing HTTPS-with-CA system can't be pointed to as a proper "existing solution".
Other private alternatives or methods exist, such as "Perspectives" and "Certificate Patrol" as early examples. Some combination of widespread democratic verification and certificate pinning systems are likely going to be required in functional solutions.