Self Signed Certificates another Layer
There is a lot of Internet press from companies and experts alike that self-signed certificates have to go away. It is a little unfair because they do have their place and if used within these limitations might even increase your security for certain edge cases. A few things to remember before we begin about Certificate Authorities (CA):
1) CA pay to have their spots in most browsers
2) CA have large attack vectors because they are well known
3) CA continue to use cost to determine the level of security you receive. Want larger keys, then pay a little bit more, etc.
What if you had a limited number of users that needed security and you were capable of providing your own root CA for your users? In that case, you could sign them yourself and use very large key lengths to increase the security in addition to other layered approaches. You could also take the CA offline so that it couldn’t be hacked. Its limitations are that you need to explicitly revoke your CA by hand and its difficult to scale this or expect to. They are not appropriate where with lots of users and ecommerce, parties do not know each other in advance. Self-signed certificates are more useful in private data and email exchange between limited clients and servers where you control all aspects.
Without a few facts, this entry would be no better than the companies that tell you self-signed certs are bad. I’ll list two good papers and discuss them below.
- Creating Rogue Certificate Authorities – Research Paper on hash collisions and techniques
- Certificate Authority Compromised – Comodo Group
- Another Certificate Authority Compromised – DigiNotar
- Sick SSL ecosystem: 90% https sites insecure
- Are self-signed SSL certificates as insecure as they say? – Article from Network World
- WOSIGN hacked and issues fake certs
Here is the premise of this article:
“We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.”
Followed by this:
“This successful proof of concept shows that the certificate validation performed by browsers can be subverted and malicious attackers might be able to monitor or tamper with data sent to secure websites. Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites.”
Why we need CAs?
A certificate is a document that contains both an identity and a public key, binding them together by a digital signature. This digital signature is created by an organisation called a Certification Authority (CA). This organisation guarantees that upon creating the digital signature it has checked the identity of the public key owner (e.g. by verifying a passport) and that it has checked that this public key owner is in possession of the corresponding private key. Anybody in possession of the CA’s public key can verify the CA’s signature on the certificate. In this way the CA guarantees that the public key in the certificate belongs to the individual whose identity is in the same certificate.
Hierachy of CA’s
X.509 certificates fit into a hierarchy of CA and end user certificates. A signature on data can be verified by the signer’s public key. This public key is linked to the owner’s identity by a certificate. This link can be verified by verifying the certificate’s signature, using the public key of the issuing CA. This CA public key can be found inside the CA certificate, one layer upwards in the hierarchy. This CA certificate will itself be signed by a CA another layer up. At the top of the hierarchy there is the “root certificate”, that is “self-signed”, and that has to be trusted for its own sake.
Many of these self-signed root certificates are installed in browsers or operating systems. Applications using them, such as web browsers, will trust them automatically, i.e. the applications will accept the certificates as authenticated and genuine without explicitly asking the user if it should do so. The user may be notified by small security signs such as a closed padlock symbol in the browser’s frame. Every certificate that is in a hierarchy of which the root certificate is trusted, is also automatically trusted.
CA will continue to be primary attack vectors for governments and other interested parties. If they can get a signed CA certificate, they can break the chain of trust. It is a matter of time before SHA1 follows MD5 if it hasn’t already. There are cases where a private self-signed key can offer protection against this type of attack but it is not a solution for all cases. As you scale you decrease the trust as more parties are involved. I realize this is probably not conforming but security is a series of layers of defense and in some instances this can be an effective strategy when used with other best practices.
Final Words and Research:
Recent research papers again are in the news including one recently by facebook explaining the issues from real world data and additional concern for forged Certs and Certificate Authorities. I hope this is a good starting point for others in their research in this field.
Free certs in 2015 being reported on slashdot. Great discussion on CA’s and trust in the threads for this article.
With recent info about the NSA defeating the PKI, here is yet another discussion on pinning and self signed certificates. Very good read. Myself I like to use this firefox plugin with my browser from calomel.org to help understand what I am looking at.
Update: With browsers such as firefox 34 now supporting OSCP by default, one needs to either setup their own OSCP server or notifying all the clients how to revoke the self signed certificate in their browser settings should you reissue. This can be a complicated mess and side effect of using self-signed certificates but you probably want direct control in the first place if you don’t trust the PKI. 🙂
Update2: Everything you need to know to run a CA from xca.sourceforge.net project.