Last time we looked at some basics about how TLS and SSL work, and saw that this is basically an application of the same technology used to encrypt e-mails. But we also noted that there are some problems with this approach. We need to recognize that in security there is never a permanent solution, and that vulnerabilities are constantly being discovered, and ideally then being fixed. Some of these may involve highly technical issues about cryptographic methods, but I think the largest category of issues is about the processes around the use of certificates. Let’s start with the Root Certificate Authorities.
Root Certificate Authorities
Root Certificates are certificates that are either unsigned or self-signed. Because they are the starting point (i.e. root) of the hierarchy, they are not vouched for by any other authority. Since there is no other way for these authorities to be validated, each browser includes a list of the root authorities it “trusts”. You can view the list of root authorities that Mozilla uses, for instance, here, and it contains nearly 400 entries, including (as Steve Gibson likes to point out) the Hong Kong Post Office. Because these are considered “trusted”, your browser will consider any certificate they issue or sign as authoritative. But are all of these root authorities truly trust-worthy? Do they carefully evaluate each certificate they are asked to issue? The evidence suggests they are not.
In July 2014 we got a report that an agency of the government of India, the National Informatics Centre, had issued certificates purporting to belong to Google and Yahoo. There were 17 false Google domains and 27 false Yahoo domains that had certificates issued. Why did this happen? I don’t know that we have the answer. Now, as it happens this particular root authority was never trusted by Google or Mozilla, but was trusted by Microsoft. Of course, in the wake of this revelation the NIC was removed from the list of trusted authorities that Internet Explorer uses, but anyone using Windows XP would not get the update since that OS is no longer supported.
Another case came to light in December 2013 when Google discovered a list of fake certificates for its domains issued by the French Government. Why did the French government do this? Quite probably to execute a “man-in-the-middle” attack on Google.
One of the worst examples was the Dutch authority DigiNotar, which was hacked by the Iranian government and used to generate false certificates that were employed in man-in-the-middle attacks against Iranian dissidents. It appears that as many as 300,000 people were victims here.
Man-in-the-Middle Attacks
Man-in-the-Middle attacks are a form of active eavesdropping on supposedly secure communications. The attacker is able to convince each side of the conversation that he is the person they think they are corresponding with. In the context of certificates, if a government can show you a certificate that purports to be from mail.google.com, it can induce you, if you accept the certificate, to log in to a government-owned site using your Gmail credentials. The government then has your login and password and can inspect all of your mail at any time. And the government system can take your credentials when you first log in, immediately open a connection to the real Gmail with those credentials, and then just sit in the middle as you read and send e-mail. Of course, the Iranian government did this for evil purposes. But are the NSA and GCHQ really any better? And what was the French government doing? Remember, all governments regard the privacy of their citizens as a flaw, and takes steps to remedy that flaw.
Of course, there is something similar in corporate networks, though depending on laws in your jurisdiction it may be perfectly legal. For instance, in the U.S. the law says that corporate networks belong to the employer, and they can do pretty much whatever they need to do to protect their network. This means that an employer can provide you a computer, and Internet access, on terms that give them control over what you do. It is common for companies to route traffic through a proxy server, and this server may use certificates to execute what is in essence a man-in-the-middle attack on you. The way this works is that each computer is configured to accept self-signed certificates from the company as trusted root certificates. When you go to your bank, for instance, and ask for a certificate for a secure login, the company server intercepts this request, and sends your login to your bank from the company server. This gives them a secure connection to your bank. Meanwhile, they send you a certificate, signed by their trusted self-signed root certificate, purporting to be from your bank. Your browser accepts this as authentic, you have to all appearances a secure connection to your bank, but in fact all you have a connection to the company server. Whether or not you consider this a good idea (I happen to think it is probably justified), you should be aware of it. It is probably completely legal in at least most jurisdictions.
Protection
What can you do to protect yourself? Here are some reasonable ides from the Electronic Frontier Foundation:
- Always install browser updates as soon as they become available. Remember that the list of trusted root authorities is contained in a list in each browser, and any changes to that list come in the form of a browser update. In the case of the Indian authority, Microsoft issued an update to remove it from the list, but until you installed the update you could be at risk.
- Check for Certificate Revocation. If a certificate is bad, it should be revoked, and you should be able to see this. Unfortunately, this is not available for Google Chrome because their security team has decided that Revocation lists don’t work well. I think this is a mistake, and would not be surprised if public pressure caused them to relent at some point. Firefox does handle it quite well.
The recent Heartbleed vulnerability has really highlighted this issue, because it potentially compromised many sites and caused a spike in certificate revocations by sites that might have been affected. - Another Firefox option is to install the Convergence add-on, which warns you if the certificate you are seeing is not what people in the rest of the world are seeing.
- And another Firefox add-on to look at is Certificate Patrol, which will alert you when a certificate has been updated. This gives you additional information you can use to check the validity of the certificate.
- Enable two-factor authentication when possible. This prevents someone from using your password to log in to your account since they would not have the other factor. Google offers this for all of their accounts, and the way it works is that you get a text message on your phone with a 6-digit number that you need to enter to complete the login. I also obtained a free account from Duo Security recently which I used to secure my WordPress web sites. When I try to login to my site as an admin, I get a notification on my phone which I need to respond to by authorizing the login. Personal accounts are free, so check it out.
Certificate Solutions
While we gave some good advice from EFF on how you as an individual can protect yourself, there is also a question of how we can improve the process and make it less prone to failure. Here are the main ones being used so far:
Certificate Transparency
As I mentioned above Google has not done well with Certificate Revocation, but that does not mean it is ignoring the issue either. They have offered a proposal called Certificate Transparency. As I understand it, this is essentially a public log of all certificates issued, and because it is public it can be examined (and monitored) by anyone. For this to work your browser would need to get a Signed Certificate Timestamp (SCT) from this public log for any certificate that it wants to receive. No SCT, no connection, so that is how you would ensure that certificates are added to the log. This solution relies on domain owners to monitor the log and look for anyone issuing false certificates for their domains.
TLS Extensions
Recall that SSL certificates are only one part of the larger Transport Layer Security protocol. This protocol has received numerous extensions over the years to do things like add new encryption methods and extend the protocol in other directions (e.g.renegotiation of connections). This remains an option for improving the process.
OCSP Stapling
OCSP stands for Online Certificate Status Protocol, and it is a way of verifying a certificate that relies on the issuing authority testifying that the public key is still valid. But it is still vulnerable to a man-in-the-middle attack. OCSP Stapling solves these problems by having the certificate owner obtain the verification from the certificate authority and then “staple” this to the certificate to attest to its validity. This works by including a Certificate Status Request in the TLS Handshake that tells your browser to look for this stapled Certificate Status from the CA. If this is not found, or is for some reason not valid, the browser should query the CA directly. The risk here is that if the CA has been compromised you could get a false response. So this is pretty good for dealing with hackers, but probably not enough to deal with NSA and GCHQ.
These process issues are the main problems with SSL certificates, and there is continuing attention to improving the process. I don’t know that there has to be one-and-only-one approach to improvement, though. I would like to see Google use Revocation lists while also promoting their Transparency option, and all of that can coexist quite nicely with TLS Extensions and OCSP Stapling.
Listen to the audio version of this post on Hacker Public Radio!
Save as PDF