Are self-signed certificates actually more secure than CA signed certificates now?

Question

Are self-signed certificates actually more secure than CA signed certificates now?

I ask this because recent leaks about the NSA spy programs and the secret FISA courts mean that the US government can force Certificate Authorities in the US to secretly hand over their root certificates and the CAs can't do anything about it because of a secret gag order. Given the US's communication intercepts in all the ISPs and gateways, it would be simple for them to MITM each HTTPS connection coming in and give out their own public key signed with that same root certificate instead, thereby allowing them to intercept the private keys used in the TLS session and forward a copy of all the data back to their Utah data centre for analysis and permanent storage. It seems they've had this capability for a while and there's no telling what information has been stolen. This basically undermines trust in the whole internet.

Knowing this information, would it be technically more secure for a private organisation to generate a self-signed certificate for a server, then manually copy that certificate and give it to their users on a CD/USB drive, then their users would manually load the certificate as trusted into their web browsers? That way if the connection was MITM'd by the US then it would not match the one in their browser.

However because there are already "trusted" CA certificates pre-loaded from Verisign, Comodo et all into the browser, as the US is performing a MITM attack on the connection couldn't they just initiate a request to the real server, copy the public certificate information, then create a new certificate based on that information for that domain being requested, sign it with any of the root CA's certificates they have which are trusted by the browser, thus allowing them to intercept the data? Nobody really bothers to look at these things to see if the certificate was signed by the correct company Verisign, Comodo or another one. Users are just looking at the padlock. It would only look suspicious to the administrator who remembered they created a self-signed certificate, not a certificate signed by Verisign or some other company.

This just made me realize the US only needs one dodgy CA certificate pre-loaded and trusted into most browsers to be able to perform MITM attacks on anything, they simply swap out a site's real certificate for a new one where they signed it with any of the root CA certificates that are trusted by the browser. If that was the case, then you would need a new browser profile, remove ALL the trusted certificates, load in your own organisation's trusted certificate and use that browser solely for communicating within your organisation. Any MITM attempts would throw up a big warning in the browser.

Answer 1

There is a subtle point here. In the envisioned situation, there is one (or several) rogue CA who may emit fake certificates for man-in-the-middle attacks. The vulnerability here is not about a server who uses a (genuine) certificate from that rogue CA; it is about the client potentially accepting a certificate from that CA. To protect yourself (as a client) against the rogue CA, you must un-trust that CA (i.e. remove it from your "trusted roots" certificate store). This merely implies that servers that you still wish to talk to should use some other, distinct CA, for their certificates.

In a corporation, producing self-signed certificates and pushing them to all the clients really is a special case of maintaining your own PKI: the corporation produces one or several roots, which have to be installed in all the clients. This is doable; some corporations do just that. But for MitM as discussed here, nothing is gained until the "trusted roots" store of all clients is cleansed from all other, potentially evil CA.

Unfortunately, you cannot necessarily do that. If your operating system is Windows, then there are a lot of signatures used for various components, in particular for updates from Microsoft. You do want to install security fixes, don't you ? You can get away with removing most of the root CA from your "trusted roots", but not all, otherwise to many things will break in your OS.

The conceptual problem is that some OS (in particular Windows) use a centralized mechanism for certificate validation, in which there is one trust store which is deemed appropriate for everything which deals with certificate validation on the machine (in details, there is one "local machine" trust store, common to all users, and one extra trust store per user, but a user cannot "opt out" of the common local machine trust store). You may have better luck with other operating systems such as Linux, which traditionally don't use X.509 certificates for their internal needs, but OpenPGP keys, with a much more decentralized trust system.

---

The Firefox Web browser, though, uses its own SSL implementation and trust store, separated from that of the base OS. Moreover, Firefox supports profiles, meaning that a user can have several "personas" with Firefox, each with its own settings, including the set of trusted roots. Therefore, a corporation who fears for its data confidentiality could do the following: it could instruct its employees, when they deal with corporate servers, to always use Firefox, with a specific profile which contains only the corporation's own root (or set of self-signed certificates) as "trusted roots".

It is unclear whether the said employees would like it, but it is feasible.

Remember, though, that a powerful attacker is powerful. If that attacker may control "official CA" then it could push a fake update, purportedly signed by Microsoft, which installs a backdoor in every system. Or they could simply ask Microsoft to plant the backdoor themselves. In any case, you don't have much choice: by construction, you must trust the OS and the hardware for not playing foul games on you.

Answer 2

Browser plugins like Certificate Patrol for Firefox can warn you of changes since the last or first time you visited; but you'll find that a lot of legitimate network topology and load-balancing solutions have relied on this interchangeable trust flaw of SSL - so you'll end up with a ton of prompts and warnings while navigating the internet.

You are correct that self-signed certificates or private Root CAs are more secure than pre-trusted public Root CAs; providing you have reason to trust the private certificate chain and a secure channel to receive it. That is: Only ever trust self-signed certificates that you have reason to trust. You will need to delete all other pre-trusted Root CAs.

Perhaps have two differently branded browser instances on the computer. One for secure communication using only a tiny set of vetted root CAs; and another vanilla browser instance for insecure communication.

---

Initially asymmetric encryption (public/private key pairs) was supposed to involve some form of more direct trust such as the popularity of physical key-signing parties in the 1990s. An exact workable approach had not been fully fleshed out before the internet exploded in the mid-90s.

As these physical webs of trust were seen as unworkable for eCommerce over national or international distances - we accepted the creation of companies acting as "trustworthy" Root CAs for the rest of the business community; presumably able to be sued if they signed certificates they hadn't verified. While this is a (mostly adequate) solution for citizen<->business trust for eCommerce purposes; it does nothing for protection against entities with the resources and legal powers to wiretap and coerce commercial certificate authorities.

To paraphrase: The best lie that the NSA* ever told was that their spying doesn't exist or doesn't work.

Data retention takes this to a whole new level.

Personally, ever since reading The Light of Other Days, I've subliminally absorbed the idea that nothing is truly private. It just comes down to how interested the Powers That Be are in you, what is at their disposal and whether a healthy democracy exists to keep them in check.

_{* or [insert favourite spy agency here]}

Answer 3

Everyone else here is quite right, but here's a simple direct answer to your question.

If you can communicate with the server owner out-of-band the first time you accept a self-signed certificate, and verify that it is their certificate, and only recognize that one certificate for future connections to their server, then in theory such a setup could be more secure than a traditional CA-signed certificate. The USB drive transport scenario would work as out-of-band communication here, as long as you can be assured the USB drive has not been compromised in some way.

In such a case, you could do this whether their cert is CA-signed or self-signed, and if that certificate is always "pinned" by your browser (or in your mind; so you would check it's the same signature for each and every visit), then you can be relatively sure no MitM is going on. This involves having to directly speak with and trust each and every server operator beforehand, though, and this is often not feasible.

This scenario would also require an out-of-band revocation channel, too, in the event that a hostile entity breaks into their server and steals their private key. And if you say "well, what if the server operator isn't aware of the private key compromise?" then not much can be done; this is a problem that SSL/TLS can't prevent in general.

Answer 4

It is more secure to use a pinned certificate than just relying on CA sigining. This is independent on whether the certificate is self-signed or signed by a CA.

However, you need to ensure distribution of the pinnng :-)

For the case where you are distributing a "secure browser" in CD, you could install a shortcut with a command line like the «Twitter Like A Boss» of http://scarybeastsecurity.blogspot.com.es/2011/04/fiddling-with-chromiums-new-certificate.html

(beware: current Chrome versions don't support the public_key_hashes property in HSTS, which is being used in that command line to pin the certificate)

Answer 5

Having only a self-signed certificate does not make it more secure. After it is compromised, you have to personally tell all your clients that the connection is no longer secure and that they should no longer trust it, deploy the new certificate and you have to keep your fingers crossed that all your clients are notified in time.

If you want to go this way, you have to build your own CA with your own private root certificate (generated on a machine that has never connected to the internet). You should keep the key on a USB stick only and put it in a vault and only take it out if you need to issue a new certificate (request) (again, only do this on a computer that has never seen the world wide web). Having a CA gives you the ability to create new certificates as you need them. Then setup a OCSP server so that your clients can check on demand (if it is your client software you should enforce OCSP checking before any connect) if any certificates have been revoked.

When everything is set up and working you have to hope that nothing goes wrong (your servers get hacked). But it is a lot of work, and to keep it secure is probably not cheap.