Digital Certificates

Lots of people have been discussing digital certificates with me lately, with several certificates having to be re-issued due to certificate chain problems. I thought I'd take the time to explain how these things work in simple terms.

Most people come into contact with certificates when either setting up a web server that uses SSL (Secure Sockets Layer) to encrypt data in transit or encrypted e-mail. The two main functions of a certificate are to provide encryption using the keys contained with them and provide assurance that the owner of the certificate is who they say they are. Certificates issued inside an organisation for solely internal use, the second point might not be so important as assurance can be gained through talking to the person who issued the certificate. However, under most circumstances, people need independent assurance that the owner is who they say they are.

Certificate Authorities

A request can be made to have a certificate digitally signed by an independent organisation (certificate authority) which people already trust, making the process of accepting a certificate as valid seamless. However, how does an end user trust the certificate authority? Surely, we still have the same problem in providing identity assurance with these organisations, otherwise we wouldn't be able trust their digital signatures? This has, in the most part, been solved by pre-installing the certificates of these organisations into applications like e-mail clients and web browsers that are likely to come across these signatures. If you want to take a look to see who you trust by default, try going into Tools -> Internet Options -> Content and click on the "Certificates…" button. One of the tabs across the top will be labelled "Trusted Root Certification Authorities". In Firefox in Windows, simply go to Tools -> Options -> Advanced -> Encryption (on a Mac, just go to Preferences -> Advanced -> Encryption) and click on the "View Certificates" button. One of the tabs will be entitled "Authorities". Different browsers and e-mail clients will have similar options.

The reason that these authorities are trusted is because they have stringent verification methods to ensure that certificates are only issued to the correct people or organisations.

However, there is a problem with this model, one which manifested itself at LSE, where a root Certification Authority changes its signing key and certificate pair to one that is not already present in all browsers or clients. The only way to automatically trust certificates signed with the Certificate Authority's new key is to manually install it, which is not recommended. Apart from the obvious danger that the person doing the installing has to do equivalent checks on the identity of the certificate to provide the same level of assurance as the other certificates in the root Certificate Authority list, having to get every client that may connect to that device is a nightmare.

It is by far safer to have certificates signed by a key that is already in the client. This is why most Certificate Authority's certificates have very long lifetimes, equivalent to the expected lifetime of the equipment of the client, to prevent manual updates.

The point of all this is that the client doesn't need to refer back to the root Certificate Authority every time it comes across a certificate signed by that particular CA. Nor do they even, necessarily, require a route back to the CA at any point, as long as the CA's credentials are held locally.

Expiry and revocation

Certificates all have an expiry date. It is assumed that the "private key" (that which is used to decrypt information or digitally sign other messages/certificates) will get compromised at some point. The more protection given to a certificate, the less likely it will be compromised and, therefore, the safer those certificates dependent on it will be. This paper describes the ways in which an organisation might protect its own certificate signing key.

If a private key does get compromised, it is possible (albeit hard) to revoke that certificate and any child certificates using a certificate revocation list (CRL) that is incorporated into the certificate itself. This process is, however, a bit flakey, as it defeats the purpose of being able to do offline verification of certificates based on locally-held, trusted credentials of CAs.

Internet Explorer vulnerability

UPDATED: A lot of people have been asking me about this in the last two days and I thought I'd summarise my observations here. Please leave a comment if you think I've got something wrong or I haven't answered a particular question.

The Issue

It seems that Microsoft have had a bug in Internet Explorer 5.01 (released in November 1999) that exists right up to the latest beta of IE 8. Essentially, someone can write a web page that references a non-existent page element causing an error within IE that allows code to be run on the local machine as if it were the current user of the machine. Usually this would manifest itself by using IE to download a piece of code from a 3^rd website and silently install it, compromising the PC. (Before anyone comments that I've over simplified the problem, I have no intention to get into invalid pointer dereferencing in DHTML arrays in this blog.)

This only affects Internet Explorer – not Firefox, Safari, Opera or Chrome (although I'm still a bit sceptical about the patching regime for Chrome at the moment and am hesitant to recommend it).

Impact

Because the vulnerability essentially means that an attacker can install anything they like on your machine, anything could have been happened. I don't mean to panic people, but I honestly don't have any idea how much information or how many machines have been compromised in this way since the vulnerability was discovered.

Let's get the issue into perspective. We know that at least 10,000 websites have been compromised and, if visited with a vulnerable web browser, will infect your PC. However, given that there are approximately 110.1 million websites being operated, with a total of 550 billion web pages on the Internet, the proportion of the total affected is small.

It's also fairly safe to say that most of the "big" sites like the BBC, Microsoft, Yahoo, Google, Blogspot and other sites that have big operations behind them will very quickly find compromises in their sites and fix them – they can't afford the publicity. Those sites being compromised are the smaller sites, being hosted in a chicken shed at the end of the garden.

I'm definitely not saying this isn't an issue – it is a huge problem. However, equally, I'm not saying we should all run for the hills.

What is happening and what can I do?

Microsoft have stated that they've brought forward a patch for this problem to 1pm EST. This will hopefully solve the problem. There are a few things that you can do, in addition to patching your machine by visiting the Microsoft Update Centre. IMPORTANT: if you're using a PC supported by LSE, or any other organisation, and it's on the corporate/work network, patching should be done automatically, as it is at LSE. There is a big difference between running a personal computer and having a reliable network with several thousand on at the same time on a corporate network. Please don't change the configuration of a work PC. If in doubt, contact your support team (at LSE, these can be found here).

If using your own PC, consider the following:

• Ensure your anti-virus product is up-to-date
  
• Make sure you have a properly configured firewall on your PC
  
• Consider using a different web browser
  
• Patch regularly
  
• Only visit web sites you trust
  
• Change your passwords regularly
  
• Don't use the same password for every website
  

It's also important to note that this whole sorry episode could well be repeated next week, with another vulnerability, or in a different browser. Please be sensible when surfing the web.

I'd welcome any feedback.

UPDATED (18.55, 17/12/2008): Microsoft have released an update page. See: http://support.microsoft.com/?kbid=960714

The Anatomy of a Phishing Scam

We've been suffering from a plethora of phishing scams over the last few weeks at LSE. To put this into context, Messagelabs stop in excess of 250,000 spam e-mails from arriving at our mailboxes every week, which represents 25% of the total (1,108,000). So, when one does get through, it is a bit unusual. In the main, these don't cause a lot of disruption as most people are conditioned to ignore them. However, there's always someone who does reply and the IT department spends quite a bit of time clearing up the aftermath.

So, here is my one top tip to not getting caught:

Never, ever send your password to anyone by e-mail.

It's quite simple. No-one should ever ask you to disclose your password by e-mail and you should never, under any circumstances, give it to anyone.

What happens if you do

Here at LSE, we have a set of Conditions of Use for IT Facilities which clearly state that you shouldn't do this. Most organisations with an information security policy say the same thing. Generally, you can expect your account to be suspended as a minimum.

However, that's not all. Scammers will use the details that they have gained to abuse the account they have access to steal information and, most likely, send spam out from the account. This means that the account gets blacklisted. Which is a pain.

Phishing for Bank Details

This is obviously a subset of a much wider attempt to con people into handing out personal detail, either directly or trying to convince them that they are on a legitimate site. Many people have received e-mails, purportedly from their bank, asking them to log in by clicking a link in the e-mail and filling in all of their authentication information.

There is a simple way to avoid being duped by one of these e-mails. Never click on the links in the e-mail: always go directly to your bank by manually typing their website address in the address box of your browser.

Browser defences

On top of this, many web browsers now (or will soon) incorporate anti-phishing tools. For example, Mozilla Firefox has a feature that, if turned on, automatically blocks access to known phishing site.

If in doubt, don't click. And another tip: don't reply to these scam e-mails with some sarcastic comment: it only confirms your address and you'll end up getting more spam.