STE WILLIAMS

TLS certificates are very important.

So we thought we’d use a story about a recent certificate security blunder to remind you why.

TLS stands for Transaction Layer Security; it used to be called SSL, for Secure Sockets Layer.

It’s the internet security protocol that puts the padlock in your browser’s address bar when you type https://, among much else.

(A lot of people still talk about “SSL” and “SSL certificates”, in the same way that English speakers in countries that use kilometres still say things like, “Your mileage may vary.”)

The idea is that TLS provides all of the following security features:

1. Confidentiality. At the start, each end agrees securely on an encryption key for the rest of the session. You can’t eavesdrop that key by “sniffing” the network, so the contents of the entire session remain secret.
2. Integrity. Each chunk of data exchanged in the session is digitally signed so that it can’t be tampered with along the way.
3. Authenticity. The website identifies itself up front by presenting a cryptographically-signed digital certificate.

Point 3, as you can probably imagine, requires more than just a certificate presented by the server.

In fact, TLS involves what’s known as a chain of trust.

The certificate sent by the server needs to be vouched for by a sequence of ever-more-trustworthy certificates, ending in a certificate that is explicitly trusted by your operating system or browser.

Otherwise, any server could state that it was nakedsecurity.sophos.com (or any other server, for that matter) and you would have no way of knowing whether it was an imposter.

Visualising the chain of trust

Generally speaking, TLS traffic is signed by a digital certificate that identifies the company that owns the website you’re connecting to.

That certificate is signed, or vouched for, by a Certificate Authority (CA), and that CA’s identity is pre-programmed into your operating system or browser as a “trusted advisor.”

For example, when you visit Naked Security using Firefox on OS X 10.10, you should see something like this:

Naked Security’s certificate is owned by Sophos; Sophos’s right to represent itself as Naked Security is vouched for by GlobalSign; and GlobalSign’s right to vouch for Sophos is vouched for by Firefox.

Web filtering

You hit a bit of a snag if you’re a network administrator who wants to filter HTTPS web traffic, for example to block booby-trapped web sites or to catch malware downloads.

Because you are the network administrator, and you control the network, it’s usually fairly easy to intercept your organisation’s web traffic.

You can use what’s known as a proxy server between your users’ browsers and the websites they’re connecting to (that’s where this approach gets the name Man-in-The-Middle, or MiTM).

That works for HTTP, but it’s not enough for snooping on HTTPS, thanks to Point 1 above: the contents are encrypted end-to-end in each direction.

Although your proxy can see that there’s a conversation going on, you have no idea if the traffic contains kitten photos or data-stealing malware.

What you have to do is to decrypt the traffic coming from the user before it leaves your network, and then re-encrypt it by making your own onward HTTPS connection to the server at the other end:

As a result, the data is briefly unencrypted inside your web filter, so you can examine and analyse it.

Of course, that messes up Point 3 above, because your web filter has to come up with a temporary digital certificate that it can send to the user’s browser, pretending to identify itself as the destination server.

And that bogus certificate won’t be signed by a recognised CA, so (by default at least), your users’ browsers will throw up a warning:

Finessing the chain of trust

The right way to get around MiTM TLS warnings of this sort is to act as your own CA.

You create a CA certificate of your own, which you load into your web filter so it can “mint” temporary digital certificates in the names of other people’s websites, purely for filtering purposes.

You then explicitly configure the operating systems and browsers inside your organisation to trust your own web filter’s CA certificate.

That way, if any temporary man-in-the-middle certificates happen to leak out of your organisation, no-one else’s browser will trust them, so they will be no more use to a crook than fake certificates that he signed himself.

In real life, however, getting all of your users’ computers to trust your web filter may end up being quite a lot of work, depending on your security readiness.

Different procedures are needed for different browsers and operating systems.

So the sneaky approach to getting your own organisation to trust your web filter is to make the whole world trust it in one go.

This “wrong way” involves persuading a root CA – a CA that is already trusted by everybody’s browser – to sign a so-called intermediate CA certificate for you.

Usually, you use an intermediate certificate to run a CA business, which goes something like this:

• Customers ask you to sign website TLS certificates.
• You do some sort of due diligence to check up on the applicants’ identities.
• You check that they really do own the website names they are asking you to certify.
• You sign their certificates and send them back.
• The customers’ certificates are immediately and widely trusted.

The last point works because there is a chain of trust from the customers’ certificates you just signed, through you, through the root CA, to most browsers in the world.

Organisations that sign TLS certificates clearly aren’t supposed to do so automatically or in bulk, since they are supposed to be vouching for the identity of the customers for whom they are signing.

Of course, if you were to upload your new and powerful intermediate CA certificate into your web filter instead, any temporary certificates it created while your users browsed would be trusted right away.

And that’s the “overkill way” of getting your web filter trusted inside your organisation without further effort.

Clearly, you shouldn’t be giving this sort of power to your web filter, because its only reason for signing temporary TLS certificates is to suppress inconvenient SSL warnings amongst your own users.

If crooks got hold of one of those fake certificates, for example by hacking into your web filter, they could suppress “inconvenient” warnings too, on just about any computer in the world, to help them with phishing or malware distribution.

Web filters shouldn’t be trusted with intermediate CA certificates, and that, quite simply, is that.

It happened again

Back at the end of 2013, we wrote about a crisis of confidence caused by temporary digital certificates generated by a web filter run by no less an organisation than the French Treasury.

The Treasury acquired an intermediate certificate for its web filter from the French Public Service Infrastructure Trust Management group (ICG/A); because ICG/A was on most browsers’ already-trusted list, this had the paradoxical effect of breaking the world’s trust in ICG/A

Something similar just happened again.

This time, the culprits were CNNIC, the China Internet Network Information Center, and an Egyptian service provider called MCS Holding.

CNNIC minted a test intermediate CA certificate for MCS; MCS apparently intended to enter the business of providing “trusted public signing capabilities.”

The test certificate was only valid for two weeks, but it seems as though things didn’t go too well for MCS during that time.

The certificate inadvertently ended up installed in an outward facing web filtering proxy.

An IT engineer browsed through the proxy using Google Chrome

As a result, Google “became aware of [unauthorised] digital certificates for several Google domains.”

Any crook who got his hands on the temporary certificate shown above could have enjoyed a two-week period pretending to be Gmail, with a globally-trusted certificate chain to back him up.

What to do?

The offending intermediate CA certificate issued to MCS has been revoked (it would have expired within two weeks anyway), and Google seems to accept that no rogue certificates “identifying” Google domains actually leaked out.

So it’s unlikely any direct harm was done, and no action is required.

But whether the browser community will go on trusting intermediate certificates signed by CNNIC remains to be decided.

Mozilla, for example, has said that the matter will be considered in its security policy forum.

For the rest of us:

• Don’t use globally-trusted intermediate certificates in your web filter.
• Don’t expect CAs (indeed, don’t even ask them) to sign intermediate certificates for this purpose.
• If you are a CA, refuse any such requests.

A chain of trust is only as strong as its weakest link.

Don’t take risks, or make mistakes like MCS did, that could make you into that weakest link.

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/_sTWHhoMgjU/