Understanding SSL

Nothing is 100% secure.

1: Yes, the CA system — and particularly and preferably with certificate transparency enabled — is a bit of a mess and there are certainly questions around which CAs might be trusted — pinning helps detect these sorts of shenanigans — but the current system is better than any other alternative that's been proposed. Particularly if you're using TLSv1.2 and decent ciphers. But if you happen to have a better approach than this current mess, you may well end up quite successful.

2: Math. Brute-forcing the algorithms used is computationally massively expensive, given present and near-term computing capabilities. (Yes, quantum computing might throw a wrench in this, when those computers become viable.)

3: The differences between a public CA and a private CA are the cost — LetsEncrypt (in private beta) seeks to address that cost, private CAs are free — and the trusted path for loading the CA root certificate public key into the client device. Public CAs already have their root public keys or an intermediate public key already loaded into most clients. Private CAs are at least as secure as public CAs, once the public root CA key is loaded and marked as trusted into the clients. To be secure with a private CA, keep your private root CA key offline. Maybe set up intermediate certificates. Etc.

There are more than a few discussions and debates around this topic posted around the 'net.

There isn't certainty here, as was mentioned earlier. Look up "black bag operation" or "evil maid" or other such, for some of the sorts of things that can be used to target security, for instance.

I think I will give this one a shot. You are right in having a hard time understanding all this. However, it is the best we have at the moment.

1) The entire SSL system seems like an enormous flaw by centralising the trust of the entire world in very few points (the certificate authorities). I don't understand this well but it seems to me that if the CA could be hacked, it would be a security breach that would cascade to the entire world using that CA at the top of their chain.

The Certificate Authorities goes through great pains to protect their infrastructure to prevent exploit. However, exploit has occurred. Look up the history of DigiNotar for example. But the reality is that the CAs are not just selling certificates. They are selling trust. Few people remember the days when buying a cert took weeks and required faxing (yes faxing) electric bills and other identifying forms to prove that you really existed. Today, you do a host validation and poof, you have a cert. So the reality is yes, the root CAs can be hacked. But if they are, the hope is that they will discover it quickly, invalidate the root which thus invalidates all certs. I believe that not one of the CAs wants to live through that scenario. In most cases, they will be out of business. Recovering from a breach like that would be almost impossible.

2) If a CA's public key is available to everyone, what keeps people from getting the content of a valid certificate and then making a program encrypting that with all kinds of keys and trying to decrypt it with the CA's public key until the day the public Key decrypts the encrypted content?

The nature of the public key is that it is exactly what it says... public. It doesn't matter who knows it. It is only good if the corresponding private key remains valid.

3) How can you setup your own CA server 100% securely?

Technically, you probably can't. Well, unless you become a root CA. I can not imaging the cost and time to make this happen. Now, that does not mean you can not create your own CA. Plenty of businesses do this. Why pay a 3rd party for all your certs when most are used for internal services? Roll your own and then you can issue as many certificates as you would like. Ah, but only devices with your root CA will explicitly trust the certs. And as csound1 already stated, nothing is 100% secure.

At this point, using the SSL infrastructure is the best solution we have for security. After all, look no further than Apple's App Store. Every developer is issued a certificate that is embedded in apps and installers. If that developer is found to be nefarious, Apple revokes their certificate. The revocation means that any internet connected device will immediately fail to run the app or installer. This is the ultimate kill switch in the sky. It is backed by certificates.

So while you should expect exploit and the possibility of hacking, your best plan is likely to pick trusted vendors. Picking the cheapest SSL provider may not be the best solution for you and your business. Pick a partner that you trust. Then trust that they will hold up their end of the bargain and keep those private keys safe.

Reid

Apple Consultants Network

Author "El Capitan Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "El Capitan Server – Control & Collaboration" :: Exclusively available in Apple's iBooks Store

Author of Yosemite Server and Mavericks Server books

Veritas C et E wrote:

I have a really hard time understanding many security processes.

Regarding SSL:

1) The entire SSL system seems like an enormous flaw by centralising the trust of the entire world in very few points (the certificate authorities). I don't understand this well but it seems to me that if the CA could be hacked, it would be a security breach that would cascade to the entire world using that CA at the top of their chain.

2) If a CA's public key is available to everyone, what keeps people from getting the content of a valid certificate and then making a program encrypting that with all kinds of keys and trying to decrypt it with the CA's public key until the day the public Key decrypts the encrypted content?

3) How can you setup your own CA server 100% securely?

These issues have already been answered here by others but I will just add the following.

1) As mentioned this relies on trusting the CA authority and is the current best approach devised. As mentioned some CA authorities have been hacked or turned out to have other issues, for example Google recently found some issues with lots of Symantec issued certificates. However what others here have not mentioned is that a CA authority also has the ability to 'revoke' a certificate that someone has bought if it has been compromised. CA authorities are supposed to run a CRL (Certificate Revocation List) and/or an OCSP (Online Certificate Status Protocol) server so that devices can check to see if a certificate is still valid.

2) The maths used in SSL means it would take a very long time to crack the encryption used via SSL even with todays super computers.

3) Your own CA server is not necessarily any more or less secure than a public one as it is using exactly the same maths and routines. However the most important thing is to ensure that you do not allow anyone to steal a copy of your CA's private key. If someone has your private key they can then create their own certificates that all your devices will think are valid. They can even point these certificates to their own CRL or OCSP server so you cannot revoke them. If you do have your CA private key compromised you basically have to create a brand new CA and brand new certificates for all your devices which could be a huge task.

John Lockwood wrote:

However what others here have not mentioned is that a CA authority also has the ability to 'revoke' a certificate that someone has bought if it has been compromised. CA authorities are supposed to run a CRL (Certificate Revocation List) and/or an OCSP (Online Certificate Status Protocol) server so that devices can check to see if a certificate is still valid.

Revocation and OCSP are not as effective as has been hoped. Detection of problems also increasingly involves what's called pinning, and the revocation also involves pushing out an update to the affected products. CRLs aren't ubiquitous, and OCSP has been disabled in Chrome. Safari and Mozilla browsers, and other tools, do use OCSP. But not without concerns: the use of OCSP exposes what you're accessing to a third-party, and there are cases when you can't reach the OCSP servers. As a response to these and other issues, many newer server certificates are being issued on shorter windows by various providers, with lifetimes such as 90 days.

If someone has your private key they can then create their own certificates that all your devices will think are valid. They can even point these certificates to their own CRL or OCSP server so you cannot revoke them. If you do have your CA private key compromised you basically have to create a brand new CA and brand new certificates for all your devices which could be a huge task.

Ayup; don't lose your private keys. They're the same as passwords. Only you're changing them on a whole lot more hosts. Don't lose the private keys associated with your servers and commercial certificates, for that matter.

The use of intermediate certificates can sometimes help for these cases — these let you keep the highest-value certificates (further) offline, and also allow the use shorter lifetimes on the "lower value" intermediate certificates. You can potentially also isolate which certificates need to be reissued by using multiple intermediates. Massive over-designs are also easily possible, of course.

Along with revocation, figure out how you're going to renew the private root CA, too. Either a long lifetime and intermediates (e.g. don't renew for a decade or two, but don't lose the root CA private key along the way), or figure out how you're going to push out and manage new root CA public keys. There are details posted around the 'net.