Given the recent problems with SSL certificates provided by third party companies, one has to wonder why we place all this trust in these vendors. We allow them to process and produce “trusted” certificates for our websites, but in the end even Google, Microsoft and state and federal governments are falling victim to fraud.
We have always been told that SSL certificates are only secure if they are issued and signed by a trusted signing authority, and that we should never use a self-signed certificate except for limited internal use and for testing purposes. We would be crazy to implement a self-signed certificate in a production environment.
Is this really true, or simply the Kool-Aid of an industry driven by dreams of revenue?
Consider this: If you know the person or entity you are getting your security keys from, would you trust them more? More often than not the answer is yes, or at least probably. Now, if you were the one issuing your own certificates, would you trust yourself more than someone you know well but not intimately? How about someone you don’t know at all? I hope the answer is yes!
Given this, how could self-signed certificates be suspect if they are implemented properly and securely?
Self-signed certificates do pose a higher risk if not properly implemented, but, in my opinion, offer the same or more security if implemented properly.
Certificates that are issued by a “trusted” certificate authority (CA) are considered trusted because of several criteria. First, they pay the browser suppliers (e.g. Microsoft for inclusion in Internet Explorer) to validate certificates that they sign. What this means is if you have a certificate signed by one of these “trusted” CAs your browser will not balk at the website using it, so long as the information contained within the certificate is accurate and matches the site that you are visiting and that the certificate is installed to protect.
Often individuals and organisations utilise SSL certificates to protect information that is contained on a website or in web-based applications. These applications are targeted at both internal (corporate LAN based) and external (Internet facing) users, depending on the nature of the site the certificate was created to protect.
If you decide to go the route of using self-signed certificates, the first thing you must do is make sure your infrastructure itself is secure. If you cannot protect your internal CA server, then yes, you are no better off than with anyone or anything else. It is like building a house with a weak foundation. If your foundation is not sound the house will be compromised and could collapse at any time.
Next, never colocate your certificate server with any other function; that would be just as bad as leaving the systems out in the wild.
You must also protect your servers that will be issuing SSL certificates so you don’t become just another statistic. Proper implementation of your CA root certificate that is used to sign all SSL certificates in your environment is paramount in order to maintain a secure SSL implementation. If the bad guys get your CA root private certificate, your implementation is useless.
So, make sure you have your server located in the most secure part of your offices/data centre. Location, location, location is critical. It is recommended you have it in a secured area of the building monitored by video surveillance and housed in a locking server cabinet. Least privilege access to this location should be implemented, it’s also not a bad idea to actually shut down this server when not in use.
Now comes the hardest part: proper implementation on the client side. You need to deploy your public root certificate to all users that will be connecting to your site so they do not receive the message that the certificate is not trusted. This can be done either manually in most browsers, or automatically in some.
To make certificates you issue trusted you need to deploy your root server’s public certificates into workstation browsers that will be accessing your secured websites. This is so that when users attempt to access websites that are using SSL certificates signed by your root CA, they are now considered trusted in your web browser just like a “signed trusted certificate”.
Big-name SSL vendors might like you to think that performing this is difficult. While the process is tedious, it is not brain surgery. It can be done, for instance, in Internet Explorer via a Group Policy Object in Active Directory. Firefox and Safari systems require more work, but it can be achieved and, once it is done it is done, you only need to plan this type of update every three to five years. This would be a small price to pay for control of your security.
Yes, the administrative overhead of maintaining your own CA server and your own SSL certificates is higher on your end, but think of it in a different way: This model allows you to be in full control of your environment. You can proactively revoke compromised or suspect certificates. You can reissue new certificates or key pairs at your leisure and discretion. For larger environments, the benefits certainly seem to outweigh the take-backs.
Ultimately you need to map out what your organisation or individual needs are and what is expected from your SSL implementation. Outline that need for security in a formal SSL and cryptography plan for the infrastructure. Ensure all action items are in line with your objectives and make sure that you accept any risks (identified through a formal risk assessment) that arise with the options you choose (this would be ease of use versus overall security and control for instance).
We cannot, after all, as individuals or companies, cry foul because we chose to allow a stranger to hold the CA keys only to find out that stranger turned out to be lax and a party to thieves.
View full post on National Cyber Security » Computer Hacking
