Adding a single root to locally installed copies of a web browser is only really useful for 2 things: testing an SSL configuration for development, and deploying your own CA to all computers on an intranet to so you can MITM their traffic without throwing up warnings.
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.
A 3rd thing, which I've done, is for a private site to collaborate with a small group of people I know in real life. You give them a hardcopy of your CA cert and then they can verify the details when adding it to their browsers.
As long as you're careful to really keep your private keys private; the root of trust gets shifted from a hierarchy of corporations to individuals you know and (personally) trust. I like this "real trust" model a lot more than the current one of a central authority and "being told who to trust", and I think all the advocates of "if you want to use HTTPS you should buy a cert from a CA" are missing this point.
When you hit an SSL site, the remote server (the one you're browsing) presents a number of certificates. One for the actual secure domain, and one or more for the CA that signed that certificate (sometimes more than one because the CA's have intermediate keys. A key which signed a key which signed... etc)
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).
So this single root ploy is what large companies do to MITM their employees at work, I assume.
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.
I know I've heard about this somewhere before, but it seems to me somewhat a hassle to setup MITM attacks if you already have admin access over all the machines. Just put a browser plugin that logs everything and lock down the machines to they can't be messed with by non-admins. Corporate employees are generally not allowed to admin their own machines or expect any privacy on them - so there's no point in hiding the fact that you log everything.
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.
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 remember reading about that trustwave incident, that is definitely messed up!
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.
A browser plugin is really really obvious, whereas if you take a look at the CA's in firefox - there's hundreds. All you need is one subtly different from what's expected - barely noticeable.
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.
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.
