Comments

Johnston • November 14, 2011 2:34 PM

FTA:

“Some of those components are also signed, although this time by an entity called http://www.esupplychain.com.tw.”

Some useful history in understanding .tw’s appearence in malware stories:

For those unaware, Taiwan broke away from China in 1949 when the communists took over. The US recognized Taiwan until around 1972, when it shifted friendship to China, and stopped recognizing Taiwan. Only a few national governments in the world officially recognize it, even though virtually all private entities do, and of course, Taiwan passports are 100% valid in the US and everywhere I know of.

So what’s the point?

When a country isn’t officially recognized it’s in a weakend position. It’s less likely to get “fair-play” from other countries. Look at everyone dumping toxic chemcals off the shore of Somalia, which has no real government to speak of, for example.

In the case of Taiwan, it’s often used by attackers in other countries to better cover their tracks. Diminished international recognition = diminished international collaberation, so it’s a great proxy in that respect.

This is in addition to Asian countries in general having relatively poor computer security, however, the amount of proxied badness coming from Taiwan is disproportionate to its population.

Nick P • November 14, 2011 3:41 PM

@ Bruce

Is it really a failure of SSL or how most SSL implementations blindly trust the CA’s? SSL that exclusively uses trustworthy CA’s or recommends should work fine.

Stupid Security Questions • November 14, 2011 3:54 PM

SSL is working exactly as it was engineered to: It’s verifying that the code was signed by some entity, and that the entity has a valid chain of trust to a CA that it trusts, and then deciding the code is trusted. It’s not SSL’s fault that we’ve fed it chains of trust that allow pretty much anybody and their uncle to sign things.

Marsh Ray • November 14, 2011 5:23 PM

@ Johnston

Taiwan makes a lot of PC hardware. They write a lot of device drivers which need to be signed. Consequently, they have a lot of valid code-signing certificates with private keys sitting on engineer’s PCs. Engineers read emails and open Adobe .pdf and Microsoft Office attachments on their PCs.

That’s why Taiwan is mentioned often in the context of malware signing stories.

Dave Aronson • November 14, 2011 5:39 PM

According the information we received from the Malaysian
authorities, this certificate has been stolen “quite some time ago”.

Certificate Revocation List, anyone?

Alex • November 14, 2011 6:01 PM

@Andy, just to be pedantic for a second, it’s about a key compromission. A key compromise is quite different 😉

Gabriel • November 14, 2011 6:12 PM

What concerns me is that the key was known to be stolen some time ago by the government of Malaysia, yet the f-secure post indicates that we need not worry about the certificate because it expired in September. Why was a known stolen certificate never revoked? It seems like our CA system has become too large to manage trust, especially when the weakest link can be an individual company or government who owns a signing certificate.

RH • November 14, 2011 7:32 PM

I’m going to go out on a limb here, because I don’t know enough about how certificate revocation is handled… correct me if I’m wrong.

It strikes me the first part of the solution to this is to determine a path for which the end user should be able to determine if a certificate is revoked. Along with the signing certificate (the CA part), there should be a quasi-periminent URL for that CA which links to the certificate, and its list of revoked certs. With this system, you could present a cert that is verifiable just like in the current system, but you add the option to go online and check up on the cert to see if it really is still alive.

The second part, of course, is figuring out how to avoid the malaysians saying “oh, we knew it was stolen a long time ago” and not notifying their CA. That is the harder problem, but at least we have a solution for the easier part!

Daniel • November 14, 2011 10:12 PM

“It seems like our CA system has become too large to manage trust…”

That’s the issue. What does it mean to trust a foreign government, anyway. The problem with trust in this context is that it’s a slogan, not an actual fact.

Shifting the trust argument from the compromise to the notification of the compromise doesn’t change the trust analysis. Either a counterparty is trustworthy through the whole process or they are not trustworthy at all.

Steve K • November 14, 2011 11:52 PM

@Dave No one ever checked a CRL. With the now mostly common use of OSCP an automated check is happening.

I don’t know if OCSP works for code signing rather than SSL certs, or if it does, whether it has been implemented (turned on).

Anyone?

AC2 • November 15, 2011 12:13 AM

Trust chain my ***….

We’re uncomfortable with sharing even the most basic details, say on Facebook, with anything beyond directly linked friends but supposedly we should trust a chain of CA’s because our browser comes preinstalled with a set of root CAs that say this is OK.

Have a look at the website for NIC CA which is the “official body responsible for the issuance and maintenance of digital certificates for usage within the Government of India domain” at http://nicca.nic.in/

From the top bar browse to Support -> Frequently Asked Questions and then select Technical FAQs in the left side menu.

Read the answers for the following and laugh/ cry:
– Error Message: “VB script errors”
– Error Message: “Windows cannot determine the validity of this certificate because it cannot locate a valid certificate revocation list from the CA which issued the certificate”

Thankfully the more important sites don’t use certs from this CA, e.g. the online tax assessment/ payment portal and all banks/ ecommerce sites.

Dimitris Andrakakis • November 15, 2011 1:51 AM

@Stupid Security Questions :

Agreed, but the whole point is that it’s NOT a technical failure : the whole system is wrong by design.

I’ve always wondered why a simple delegation check was not implemented : e.g. the goverment of Malaysia’s certificate should only be trusted to sign .my sites. A commercial CA (say, Verisign) should only be trusted to sign .com sites and so on.

Note that this wouldn’t really solve the issue, but it would mitigate the risk to a large extent.

Natanael L • November 15, 2011 4:27 AM

Why do we keep the current trust system? It isn’t even the slightest trustworthy…

We need a system where we can chose to distrust signers and where people can chose to use multiple signers at once.
Why have just one certificate when you can have a PGP key and 5-10 signatures? The latter makes it ridicolously much harder to break your security if you’ve got your private key protected (just like you need to protect SSL certs).

And for end users, you can simply just choose to ignore single signatures and ignore signatures from organizations you don’t trust.

Just consider this: The current system requires ONE signature from Verisign OR Comodo OR [one of the other hundreds of companies]. Instead you can IGNORE signatures when there are just ONE and treat it like regular unprotected connections, and also completely ignore signatures from DigiNotar and other untrustworthy CA’s.
Or you could even let it warn you when a breached CA’s signatures are found!

So instead of breaking down, it just works AND is safer. So only if it would have a signature from Verisign AND Comodo or StartSSL AND some other organization you have some trust in, then the hackers need to hack several companies simultaneously.
You could set quite high requirements for when you start to trust the combined signatures, and set different trust levels for different CA’s.

AC2 • November 15, 2011 5:16 AM

@Natanael L

How would an organisation go around getting their certs signed by every likely CA that their visitors may choose to setup as a part of the rule?

Also this costs more money. Consider that many sites don’t want to use EV certs because of the additional costs involved.

Peter A. • November 15, 2011 5:32 AM

@Natanael:

This won’t work for public services like HTTPS. Remember that all CAs charge for their service and you have to renew the certs once a year or so. So the web service provider in order to satisfy whatever rules his clients may wish to set up would have to pay several tens of CAs to sign his cert every year. For big ones that would not be a problem, they pay a lot more for server space and time, but small businesses most likely won’t do that, choosing only one or two CAs.

In effect they would have very little clients if the default rules in the widely marketed browsers would require more than a few certs to display the coloured lockpad. This won’t help them to earn more money to be able to buy more signatures. Users also will be annoyed if they couldn’t use that cheap online store they’ve just found, and either would click through any warnings or reconfigure the browser to less strict rules. Wich sets us back to the current state of affairs again.

Natanael L • November 15, 2011 8:07 AM

@AC2: “How would an organisation go around getting their certs signed by every likely CA that their visitors may choose to setup as a part of the rule?”
They don’t. Just get signatures from 2 or 3 trustworthy CA’s. The most paranoid users will then not consider that enough, but for the average user the internet will keep working. And when a CA is compromised, they can be blacklisted instantly without breaking the internet for the users.

“Also this costs more money. Consider that many sites don’t want to use EV certs because of the additional costs involved.”
Yeah, but to reach most end-users you only need two signatures instead of one. Not that much more costly for most businesses.
For companies it suddenly becomes much easier to act as a CA internally since you also can certify chosen external sites without them having to change anything.

@Peter A: I know, but they can keep paying just one as long as they only afford to pay for one signature. Hopefully it would be cheaper with this system, but I’m not going to bet it would be.
Once they can afford a second signature from a trusted CA, they could get one.

“In effect they would have very little clients if the default rules in the widely marketed browsers would require more than a few certs to display the coloured lockpad”
Well, signatures from some highly trusted CA’s could be enough by themselves. For less trusted ones, there would have to be several of them.

The idea here is to only show a warning when a breached/highly untrusted CA’s signatures are the only signature found, to show some icon that tells the user there are some signatures when there’s signatures that aren’t yet trusted enough, and to show a that padlock when there’s signatures that’s trusted enough.

Paeniteo • November 15, 2011 9:43 AM

@Natanael:
If your system was implemented, I bet that we would immediately see ‘Meta’-CAs to which you submit your certificate and which would then take care to gather certifications up to your “service level”.
In the end, you would multiply the CAs’ revenues, without any real gain in security.

I, for one, advocate a transition away from CAs and towards the SSH trustmodel.
In its most radical form, it would mean that you blindly accept a certificate on the first visit of a domain and afterwards warn on fingerprint changes.

Natanael L • November 15, 2011 11:13 AM

@Paeniteo: Doesn’t matter. If Meta-CA’s would appear, the CA’s are still supposed to verify that the domain owner is who he says he is. Trustable CA’s will do that. The rest can be ignored by this system. If there’s services that makes it easy to get the right amount of certificates, then great! Then it’s easier for server owners too!

So then we’d still not have the same kind of many-single-points-of-failure as we have today. The servers would still have an appropriate amount of signatures that lets users verify that the server is the right one even if one CA is breached.

By the way, I’m imagining my model as a WoT model. In it’s most “radical form”, it too can work that way – when you see an unknown keypair, an old keypair used for a new domain and/or signatures from unknown keys only when connecting to a new site, you are asked if you want to the site’s keypair and/or the signing keypairs.
Then you’ve got the SSH style system with one keypair + multiple signatures on it to make it easier to verify it.

TimG • November 15, 2011 11:43 AM

@Paeniteo:

I, for one, advocate a transition away from CAs and towards the SSH trustmodel. In its most radical form, it would mean that you blindly accept a certificate on the first visit of a domain and afterwards warn on fingerprint changes.

I’d be surprised if there wasn’t already a Firefox extension for this.

Dirk Praet • November 15, 2011 5:23 PM

@ Nick P

“There was another thing like this, but I can’t remember what it was called. ”

Certificate Patrol ? Convergence.io now has a Firefox add-on too.

The main question in the discussion remains the same: how many compromises will it have to take to move away from the present broken CA system ?

Paeniteo • November 17, 2011 3:45 AM

@Nathanel L: “If Meta-CA’s would appear, the CA’s are still supposed to verify that the domain owner is who he says he is.”

I’m pretty sure that the CAs would establish “fast lane” procedures for the Meta-CAs, since the Metas would be considered “trustworthy”.

Wim L • November 17, 2011 5:36 PM

“I’ve always wondered why a simple delegation check was not implemented : e.g. the goverment of Malaysia’s certificate should only be trusted to sign .my sites. A commercial CA (say, Verisign) should only be trusted to sign .com sites and so on. Note that this wouldn’t really solve the issue, but it would mitigate the risk to a large extent.”

This does exist in the form of the “name constraints” certificate extension (see, eg, RFC5280 4.2.1.10). However, I’ve never seen it used. I don’t think there’s any economic incentive for CAs to minimize risk like that: root CAs don’t want to limit their markets, and they also don’t want to create intermediate CAs which would reduce the revenue going directly to their root.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.