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.
It seems silly to me to complain about websites that host non-sensitive content and lack HTTPS capability. Last I'd checked, most/all major browsers threw a warning if a website used a self-signed certificate (or worse: e.g. the Mozilla dunderheads changed Firefox to pitch a hysterical temper tantrum by default), and the trustworthiness of the Certificate Authority system is completely compromised in that, in just one example, every CA based in the USA is subject to the NSA's gag-ordered National Security Letters. Most businesses comply with NSLs rather than fight or shut down business like Lavabit did [theguardian.com].
As-is, the owner of a simple website that doesn't handle sensitive information, who understands the broken nature of the CA system and doesn't want to rely on it, is basically stuck between a rock and a hard place. If he chooses to use self-signed certificates, users are shown pointless "suspicious" warnings which will drive some away. If he uses a compromised CA (which potentially includes all of them), he's just participating in security theater. If he takes the simple approach and just sticks to unencrypted HTTP, some self-important idiot is likely to point ignorant fingers and start keening about "unsecure sites".
Certificate pinning can help, but neither that nor private/democratic webs-of-trust will work properly in front of an average user faced with the stupid default browser behavior currently in vogue.
To quote a great computer scientist,
Strike a poseStrike a poseVogue, vogue, vogueVogue, vogue, vogueLook aroundEverywhere you turn is heartacheIt's everywhere that you go [Look around]You tryEverything you can to escapeThe pain of life that you know [Life that you know]Come on, vogueLet your body move to the music [Move to the music]Hey, hey, heyCome on, vogueLet your body go with the flow [Go with the flow]You know you can do it
Strike a poseStrike a poseVogue, vogue, vogueVogue, vogue, vogue
Look aroundEverywhere you turn is heartacheIt's everywhere that you go [Look around]You tryEverything you can to escapeThe pain of life that you know [Life that you know]
Come on, vogueLet your body move to the music [Move to the music]Hey, hey, heyCome on, vogueLet your body go with the flow [Go with the flow]You know you can do it
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.
As an addendum to my previous reply [soylentnews.org] to your comment:
If you have criminals in your ISP and government, the proper fix is not to point fingers and blame at website owners who are not using a mostly-broken security system.
The proper fix is to seize the criminals and punish them after following due process.
Wishfuil thinking and absolutism go hand in hand.
Meanwhile in the real world, real engineers are focused on practical solutions that can get results today, not theoretical results in a theoretical perfect world.
HTTPS as-is does not "get results" today, which was the point originally being made.
While there are limited use cases where HTTPS as-is does offer some benefit, those benefits are overshadowed by the system's brokenness.
People pointing to as-is HTTPS as a "practical solution" are lazy, ignorant, or working for the NSA.
"Hey, the door you installed me has no lock!""So what? If you have criminals in your neighbourhood, don't blame the people not installing locks on doors. Catch and punish the burglars!"
If you believe that your likely-typical door locks and deadbolts are the things that keep criminals out of your house, you are sadly [youtube.com] mistaken [youtube.com]. Locks are used to deter the drunk/confused from ending up in your living room instead of on your porch, or to act as a different type of doorbell to let you know that you need to grab your shotgun instead of your pants.
Well, I have all-metal doors and all the windows also have metal bars. That should slow down the fuckers.
Well, I have all-metal doors and all the windows also have metal bars. That should slow down the fuckers
I was going to agree with you, but frame is typically the weakest spot. Here's a solid wooden door set in a metal frame [youtube.com], and it does take a significant amount of work to get through. Proper frame and door reinforcements can make forced entry effectively impervious to humans lacking power tools [youtube.com]...
... but then there's nothing stopping someone from using a buzzsaw to simply cut a new doorway in a wall, or driving a tank into your house.
Nonetheless, taking simple and inexpensive steps to reinforce entryways can help keep the home's owner from being low-hanging fruit for criminals.