I really wish we'd divorce the identity assurance part of PKI from the encryption part. I have no idea how it would be done, but.

If we had dropped the identity bit, every ISP would be running a MITM proxy, because they want control. Already, plenty of businesses enable poor hygiene by including transparent squid proxies that strip SSL.

Encryption without authentication is still incredibly useful, and something that we've NEEDED to have happen pretty much everywhere. Some of the benefits are:

1) The ccost of and attack is significantly larger, by protecting against passive eavesdropping. You can capture massive numbers of passwords trivially by simply logging and unencrypted stream, but full MitM requires more time, effort, and resources to accomplish.

2) MitM attacks can sometimes be detected, either at the time of the attack or in the future due to repeated opportunities for the attack discovered. A passive scanner is impossible to discover, in most cases.

3) Any use encourages a culture of encryption, so the people who ARE authenticating properly aren't as obvious.

4) The cost of moving from a self-signed key to one signed by a 3rd party is small ("get your cert signed"). This makes the upgrade path to full, properly authenticated crypto much smaller.

All of these benefits are worthwhile, so please, stop encouraging the use of plaintext. The proper way of handling this is not to scare people away like Firefox currently does, but to encrypt everything automagically, so it works just like unencrypted HTTP, and only show the lock icon if full authentication has happened. That is, encrypting without auth should be used, but still presented to the user as a plain, unencrypted page.

If it's a personal page (say, a public-facing login to your NAS) you can always check the SSL fingerprint too. You don't have to remember the whole thing, just remember a few characters and check that they're right.

[EDIT] pdkl95 said what I was trying to say more eloquently and in more depth.

That's why you need the identity portion to be tied to the key exchange.

If you've got no verification of the opposite party, literally any computer could be on the other end. The key exchange mechanism is secure, certainly, but any computer can execute it. The attacker can even show you the real website just proxied through, but that's plenty enough to get your password or any other access that the attacker wants.

For a bit of fun, compare the warnings about a self-signed certificate in Firefox with those triggered by attempting to download a self-signed certificate with the CA:true bit set.

With what we know about the current environment, being your own CA is actually the most secure approach.

The CA itself is not a party to this exchange, they only provide the end product - a signed certificate.

If you trust the CA (in your browser config), you also trust by extension every certificate that CA has ever signed (barring revocation lists).

I'll have to investigate what you suggest I do for fun, because I haven't tinkered with these certs before. What flags do you pass to openssl?

The certificates do specify the issuer though. So you could use a self run CA in the manual arrangement to verify that your connection isn't being MITM'd, assuming you don't lose control of your self run CA, or leak its private key. Correct me if I am wrong.

If you're just trying to do a MITM for fun, though, there's nothing magical about the CA or cert. Once you configure the browser to trust a CA, then any cert signed with it will also be trusted by the browser. So if you are also running DNS on the network then you can re-route facebook.com or any domain to point to your own proxy server and serve up your fake cert. The user will see the nice green lock and everything. You could probably even name your CA and certs so that it looked pretty much exactly like a user would see it on the real facebook.com.

The reason why this isn't happening all over the place is just because you need to already have root access to the machine to configure the trusted CAs. The ability to add a CA, I would probably consider that to be a fully owned machine.

https://www.net-security.org/secworld.php?id=12369

https://news.ycombinator.com/item?id=5141342

I'm pretty sure it happens, trustwave apparently issued a cert for these purposes and it's claimed other CA's have done the same. It's a hassle to do, but the goal is to detect and prevent corporate espionage. Most corporates have their own OS media - installing from outside sources without adding corporate security required software is forbidden.

I assume this is how the certs get on to the machines. A browser plugin would be more transparent, possibly defeating the purpose.

I was just really trying to say that adding a rogue CA to the browser trust list vs installing a plugin both require admin permission and are both "noticeable." So neither of them are really ideal for serious espionage. In which case they're only good for non-secret employee monitoring. So, in that case, might as well go with a plugin because it would be the simpler solution.

If you're talking about a compromised "root" CA like trustwave or something where a stock browser will trust fake certs - now you're talking about a technique suitable for espionage or black hat activities.

https://www.bluecoat.com/products/proxysg

I think you'll find the above product interesting. Apparently anti-virus vendors have similar programs - to prevent malware being downloaded over https behind a corporate proxy.

It seems that CDN's such as cloudflare and akamai take the websites SSL _private_ keys too.

http://blog.cloudflare.com/introducing-strict-ssl-protecting...

This blog post is a fancy way of saying that cloudflare content serving customers now have the option of encrypting the link between cloudflare and them. Note that users can still be MITM'd at the cloudflare site - even with the new arragement.

A similar more up-to-date alternative is Perspectives: http://perspectives-project.org/

On perepectives: Convergence is actually based on perspectives with some improvements regarding privacy and latency (which are discussed in the youtube video). Are you aware if any of those improvements have been adopted into perspectives or not?

The issue is that XPKI is _really_ easy to get wrong, but there are alternatives.

Contrary to the Wikipedia page, there's a potential role for CAs. As an example, a CA could still sell a certificate authorising a key to, say, serve HTTPS data for the site foo.com; that key could then delegate authority for bar.foo.com, for www.foo.com and whatever else, without needing to go back cap-in-hand to the original CA.

Among the cool things is that a CA trusted to vouch for people serving data in .com wouldn't necessarily be trusted to serve data for .co.uk. One might have CAs vouching for one's ownership of IP addresses.

All of this was simple and straightforward, with a clean model (unlike the XPKI mess which conflates identity and authorisation), so of course it failed utterly.