Who do you trust? Why Certificate Authorities are a CARTEL!

Well, this might come as a surprise to many – but the current (and any future group) of certificate authorities (CAs) who control and distribute root SSL certificates are complicit, along with browser vendors, in creating a cartel (similar to OPEC for oil) in security on the basis of a false assurance.

The way CA’s currently run is that a select group (of which you have to go great lengths to become a member) issue their root certificates in conjunction with browser vendors, this in turn means that only certificates issued by this select few can be used without the end-user receiving some kind of nag-screen about the certificate being “untrusted”. This is the key issue – a successful certificate, no matter who signs it – works without any notification.

This means that no matter how secure your solution is – unless you buy a certificate from a “trusted” CA then your users will be led to believe that the site may not be secure. This provides the end-user with false information on which a false sense of security is given.

So…..who decides whether a device or CA is trustworthy? you? me? or your software vendor? and who do you trust to make that decision on your behalf.

Now, as has been proven in recent years – CAs probably don’t have as much security as they would like to think and it has been possible to purchase “fake” certificates for well known sites and domains. Compromised CAs like DigiNotar, Comodo, and the Flame virus’s use of a fake Microsoft certificate, This in turn allows malicious hackers to fake popular sites in order to steal information including passwords for further use. If that hacker has the power to subvert traffic (maybe due to a trojan or compromised DNS server or maybe he/she works for an isp, government agency, company network engineer, etc…), then it is possible for them to present a fake site with a valid certificate – and the end user would never know!

So because it is possible for an end-user to be diverted to a fake site using a fake certificate without the browser warning the end-user – then what trust value does a certificate from a root CA actually have? A friend noted that a serious amount of identity is required to purchase a certificate these days and that is true for most CAs but it only takes one weak system or compromised CA to enable the successful signing in the name of any hostname on the Internet. Also, because a valid certificate just says “yes” this means that so long as it validates then nobody looks at it so who cares if the certificate is registered by someone else? the user wouldn’t know and wouldn’t care.

These extended validation certificates are a bit of a con too – they only make the browser bar go green! it still suffers the same weaknesses as the other CA products for all the same reasons, and I reckon most users wouldn’t notice until it was too late.

It is for this reason that no certificate from any CA is inherently trustworthy just because it is signed by a “trusted” CA, and any assurance of assumed trust could be false and misleading.

So…what do we do with this information? and how do we do away with untrusted root CAs?

The answer is simple – and it is this – delete all of your root certificates for CAs that you don’t trust.

If you don’t use any root certificates then the first time that you connect to an unknown site or service – you have to make a choice of whether to trust the certificate which has been granted to it. This can be tedious at first as many sites use multiple hosts but is the most secure method. Often, for lack of any other knowledge you frequently have to just “assume” that the first certificate is genuine in order to access the service. For this reason it is worth checking the certificate before accepting it as an exception.

This is a personal choice and must be based upon your knowledge and trust of the organisation you are connecting to. Many organisations now have their own certificate services – which can provide a root certificate which applies to all services from a given organisation (but be aware that the organisation’s CA may be more insecure than a public one).

Once the choice has been made to trust the certificate – you can then note it as an ‘exception’, that is, you know what it is because you’ve seen it before, and for lack of root CA signing – am still willing to trust it. From here on in – you have the level of trust you require.

If the certificate is to change then the user will be prompted with a different certificate – where the user has to then make the decision again – do I trust this – or has someone compromised the service I have used previously.

This is the only way of assuring trust – and it does not require a root CA to do so – it requires a user to understand what is meant by trust and for that user to act in accordance with their own assessment.

Ok – so the enterprise people say “we can’t have nag screens for all our users!” – the answer again is simple – sign all of your own services using your own CA chain and then issue your root CA certificate to all of your clients so that they have a trust relationship with your certificates – simple!

Some might say that this last statement counters the whole of my argument, i disagree – the issue with root CAs is not that they exist but the fact that their assurance is no more concrete than yours.

These CAs sell trust to anyone who is willing to pay for a certificate – so who do you trust? and is being willing to pay for a certificate enough of a basis to elicit trust?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s