A partial solution is to run your own CA, and thus controlling everything end to end.

While this isn't a solution that is suitable in most world-facing environments, most of the places that would employ full time IT staff have control of both ends of the connection, and thus this is reasonable. Heck, OCSP and CRL's might even have a valid place in those deployments.

Most business and education environments already manage end user machines (with a variety of light to heavy touches), and adding a "corporate CA" is a fairly normal and easy to implement solution - usually a one line shell script in most Unix environments, or able to be pushed via AD to most Windows systems.

This of course couldn't be extended to the web in general, unless being able to add arbitrary CA roots from trusted organizations (vs ones decided by OS or browser makers) became normal operating procedure, which it currently isn't.

I actually think that organizational CAs are extremely dangerous today because of the core SSL problem. Sure, your CA is only supposed to be used for internal hosts, but there is nothing that is actually enforcing that. This means that the security of all HTTPS connections made inside the organization is no greater than the security of your organizational CA and I am not really confident about that. How many organizations are going to use well-guarded HSMs, for example?

(I don't think that OCSP protects you in this situation unless you've already gone through a significant amount of CA hardening that strongly ensures that you can only sign certificates that include your OCSP information. If an attacker can gain enough access to sign an OCSP-less certificate, well, they win.)

This also entirely neglects the pragmatic temptation for HTTPS interception of outside secured sites on behalf of your security and antivirus and so on people. I think that having such a loaded gun around is a very bad idea.

The loaded gun analogy is a good one - as a tool a CA has both legitimate and illegitimate uses.

To extend the metaphor, a conventional CA is a howitzer, and your little organizational CA shoots rubber bands. The amount of damage done, and advantaged gained by gaining access to a "Everyone on the internet trusts them" CA is huge, whereas taking over even a larger corporate CA has limited value and scope. Attackers are smart - they're going to go for the maximum value targets, not the marginal value ones.

What it comes down to is hardening the CA creation and use process. Some ideas to resist attacks on the CA that would require minimal cost or overhead:

• Use a secret sharing scheme to prevent a lone/rouge actor from compromising the CA, and for keeping all pass phrases and encryption keys secure.

• Create the CA root on an air gapped machine or set of disks, using encryption on data at rest.

• Use a hierarchy of root and intermediate CA certs, where the validity period is fairly short to temporally contain any problems that occur.

I do agree with the temptation of SSL stripping/interception would need to be addressed, but as with running your own CA, that's a policy and process issue rather than a technical one.

Attackers are smart - they're going to go for the maximum value targets, not the marginal value ones.

Except that "maximum value" isn't the same for everyone.

If you're doing industrial espionage, the "maximum value" could be to go after the internal CA of your competitor. In a slightly-related situation, RSA Security's SecurID system was attacked and hacked, and then that was leveraged to get into Lockheed Martin:

• http://en.wikipedia.org/wiki/SecurID#March_2011_system_compromise

Though one could argue that SecurID is like Verisign's CA business, and that if Lockheed Martin had been running an in-house system like Yubikey and a YubiX back-end, that would would be like LM running an in-house CA.

The time to force people towards HTTPS is when we've solved all of these problems. In other words, when absolutely any website can make itself a certificate and then securely advertise and use that certificate.

That is certainly an important feature to have. Technically one solution is DANE: place X.509 certificates into DNS, and make sure it's secured with DNSSEC. One then holds (hopefully securely) the private keys to signing one's DNS domain, and the private key to the TLS cert for the service in question.

This solution is by no means perfect, and the (real and perceived) problems/risks of it are available if you search, but it is a useful hand-wavy example. But it allows one to have secure communications, with a minimal number of third-party dependencies.

But one problem with these no-third-party-at-all solutions is: how do Internet surfers know to trust a site is the actual one they want? I'm speaking specifically of homograph attacks:

• http://en.wikipedia.org/wiki/IDN_homograph_attack

So if you go to "www.mybank.com", the letter 'a' could be the proper Latin/ASCII 'a' (U+0061), or it could be the Cyrillic 'a' (U+0430). Though that problem exists even now, as you could register "mybank.com" (with IDN) and get certs for it. That is one of the problems the "Extended Validation" (EV) certificates are trying to solve: not only is the ownership of the domain looked at, but also the legal entity that is registered examined and put into the certificate.

It will be a good thing when anyone (good and bad) can issue certificates so that communications are "secured" from eavesdropping. But knowing that you are securely transferring data is meaningless if you're securely sending it to criminals.

Figuring out the trust issue is an important part of the total solution to getting rid of CAs.

Attackers are smart – they’re going to go for the maximum value targets, not the marginal value ones.

https://en.wikipedia.org/wiki/Advanced_persistent_threat

Maximum value to them. We can't always know what value an attacker may be seeking. We can be compromised for as simple a reason as someone having been challenged - 'I bet you can't...'; 'I bet I can get n+1 compromised hosts before you...'. It may be revenge motivated.

It's most likely to be a financial value - either directly with compromised banking accounts, or value of data for resale. But it's unwise to assume that because you can't see financial riches in your site that there isn't someone out there wants something that you have.

One "solution" obviously is DANE. At least in a dream.