When good certs do bad things

[Peter Kurrasch]

It strikes me that some people might not have a good idea how people use certs to do bad things. As the token bad guy in this forum I'll take it upon myself to share some examples of how I might use a perfectly good cert in a "bad" way:

‎

* ‎Create a phishing site to harvest login credentials from unsuspecting people. For this I might create my own bogus domain or piggyback off an existing, legitimate domain. Either way, I can use the cert to help create the illusion of legitimacy to a victim while I steal his or her info.

* Use a server to distribute malware via online adverts (malvertising). Having a cert helps make it look more legit and is required by some advertising services.

‎

* Set up a spam email server and use the cert for my login page to the control panel.‎ The cert wouldn't be used on the email side of things but controlling access to a server that lets me do bad stuff.

‎

* Use a server to distribute malware via downloads. When I launch a spam campaign I'll attach an infected document with some dropper malware in it. The dropper malware then contacts my server to get the real malware, be it ransomware or a banking trojan or remote desktop control or general zombie code or.... Whatever the case may be I can use certs to encrypt the malware download making it harder for people to figure out what's really going on.  

‎

‎* Sign my malware code so that Windows or MacOS will happily‎ install it.

‎* Set up a command and control server and use certs to send encrypted messages between the malware on the devices I've pwnd and my server.

‎

* Set up a media server so that people can download some great movies that I pilfered from someone else.

* Create a forum so people can talk about things their government does that really bugs them and how to evade the different law enforcement agencies.‎ Obviously I'm using certs to make it harder for those agencies to snoop on the forum participants. 

‎

* Set up an online marketplace to swap/buy/trade any compromised keys and the certs that go with them. Naturally I'd have a place to discuss which CA's have the easiest security measures to bypass.

‎‎

* And sometimes it's just fun to park outside a hotel and setup a free WiFi network to do some MITM. People do some crazy things when they think no one is watching, and certs keep people from getting suspicious that anything is amiss.

* Oh, and Lenovo and Dell demonstrated some out of the box thinking with all the Superfish stuff.

‎

The point here is that while "bad" can be a subjective term there are some behaviors that ought to be discouraged. There is a role for CA's to play in that effort but not in any sort of absolute, all or nothing sense.

My suggestion is to frame the issue‎ as: What is reasonable to expect of a CA if somebody sees bad stuff going on? How should CA's be notified? What sort of a response is warranted and in what timeframe? What guidelines should CA's use when determining what their response should be?

All of this is worthy of discussion, but it's gonna get complicated. 

[Ryan Sleevi]

On Thu, May 26, 2016 at 7:40 AM, Peter Kurrasch <fhw...@gmail.com> wrote:
> My suggestion is to frame the issue‎ as: What is reasonable to expect of a
> CA if somebody sees bad stuff going on? How should CA's be notified? What
> sort of a response is warranted and in what timeframe? What guidelines
> should CA's use when determining what their response should be?
>
> All of this is worthy of discussion, but it's gonna get complicated.

With all due respect, a number of the items on your list are
orthogonal to certificates - they're a discussion about "bad" things
you can do if "encryption" is possible / if "privacy" is possible. I
don't think it's ignorance about how encryption can be used to do bad
things, it's a valuation that the *good* things
encryption/confidentiality/integrity enable far outweigh the bad. We
saw this in the First Crypto Wars, and we're seeing this now, arguably
the Second Crypto Wars.

You haven't actually addressed how or why CAs have a role to play here
- it's presented as a given. You recognize there's nuance about
expectations, which is an open question, but you're ignoring the more
fundamental question - do CAs have a role to play in *preventing*
encryption, or is the only role they have to *enable* encryption.

While not speaking for Mozilla, I think the unquestionable desire from
some here is to find ways to increase encryption, but not to introduce
ways to prevent encryption - whether through means of policy or
technology.

[Nick Lamb]

On Thursday, 26 May 2016 15:40:35 UTC+1, Peter Kurrasch wrote:
> I might use a perfectly good cert in a "bad" way:

Maybe it's worthwhile to consider what happens instead if we live under a regime (whether legally enforced or just de facto because of choices made by browser vendors) where you can't get a "perfectly good cert" for these scenarios. But in some cases I might not be clear what you propose.

> * ‎Create a phishing site to harvest login credentials from unsuspecting people. For this I might create my own bogus domain or piggyback off an existing, legitimate domain. Either way, I can use the cert to help create the illusion of legitimacy to a victim while I steal his or her info

You don't need your own "perfectly good" cert, the legitimate domain has one, which you retain. To stop this we must prevent legitimate domains obtaining certificates. There is precedent for this as an anti-crime strategy - don't try to arrest criminals, instead go after victims, with their prey thinning the criminals will starve. It's not terribly... nice, though is it?

> * Use a server to distribute malware via online adverts (malvertising). Having a cert helps make it look more legit and is required by some advertising services.

Again, it is much cheaper to use somebody else's servers. Since you're a criminal it hardly matters that this is illegal.

> * Set up a spam email server and use the cert for my login page to the control panel.‎ The cert wouldn't be used on the email side of things but controlling access to a server that lets me do bad stuff.

A self-signed certificate works for this purpose too. To prevent this we could perhaps outlaw encryption? Or email?

> * Use a server to distribute malware via downloads. When I launch a spam campaign I'll attach an infected document with some dropper malware in it. The dropper malware then contacts my server to get the real malware, be it ransomware or a banking trojan or remote desktop control or general zombie code or.... Whatever the case may be I can use certs to encrypt the malware download making it harder for people to figure out what's really going on.  

Again, self-signed certificates work fine. Indeed they are already widely used for this purpose.

> ‎* Sign my malware code so that Windows or MacOS will happily‎ install it.

As with web browsers the Dancing Pigs problem applies. Users will happily click past the "not signed, danger of death" dialog so long as they think they're getting nude pictures of a celebrity rather than having their bank account emptied.

We know the CA role isn't relevant here because in the Android ecosystem where there is no third party proof of identity users instead click past the (OS enforced) capabilities warnings, authorising an app to spend their money or spam their friends in the hope that this way they get to see the Dancing Pigs.

> ‎* Set up a command and control server and use certs to send encrypted messages between the malware on the devices I've pwnd and my server.

Self-signed certs work really well here.

> * Set up a media server so that people can download some great movies that I pilfered from someone else.

Self-signed certs are very popular in this role as far as I understand

> * Create a forum so people can talk about things their government does that really bugs them and how to evade the different law enforcement agencies.‎ Obviously I'm using certs to make it harder for those agencies to snoop on the forum participants. 

If you want to attract people who really care which type of foil is best then judging from openbsd-misc you should dismiss TLS altogether, they don't trust it at all. They will want a web-of-trust type setup, although (due to dancing pigs) they won't actually check any of the signatures so plaintext HTTP would also work (www.openbsd.org didn't do TLS until this month).

> * Set up an online marketplace to swap/buy/trade any compromised keys and the certs that go with them. Naturally I'd have a place to discuss which CA's have the easiest security measures to bypass.

It seems like the choice of certificate for the site itself is an implicit endorsement of one CA at least, is it not? But certainly such a group could use a self-signed certificate if they wanted, it's hardly as though they lack the sophistication.

> * And sometimes it's just fun to park outside a hotel and setup a free WiFi network to do some MITM. People do some crazy things when they think no one is watching, and certs keep people from getting suspicious that anything is amiss.

Have you actually tried this? Inside a corporation, with Group Policy and suchlike on your side, TLS MITM breaks all sorts of unexpected things still, causing our users to be quite irate (I'm on their side, but it's a big corporation...). I can't believe it would work even one tenth part so well with an unauthorised MITM these days with HSTS and so on. And I don't see how a few "bad" certificates from a public CA really contribute at all.

> * Oh, and Lenovo and Dell demonstrated some out of the box thinking with all the Superfish stuff.

Superfish is about adding an untrustworthy CA to the root store, is it not? That's an actual trust scenario. We don't trust Superfish, so they shouldn't be a CA. But end-entity (non-CA) certificates aren't about trust, they're about identity.

[Phillip Hallam-Baker]

What has encryption got to do with it?

The reason the WebPKI exists is for authentication. Encryption is a
secondary concern that is only required because the credit card protocols
are lame and people use passwords for authentication which is also lame.


The WebPKI model was two stage. First we make it difficult for people to
gain unlimited numbers of credentials. There is a cost to acquire a
certificate that is (hopefully) low for a legitimate user but makes it
uneconomic for a criminal to treat them as disposable.

The second stage is revocation of credentials when the holders do bad
things. Such as running a phishing site, signing malware, or the type of
thing listed above.

The design brief was to make electronic commerce possible. That is why the
system is designed the way it is. in particular the threshold requirement
was to make online shopping 'as safe' for the consumer as bricks and mortar
stores or traditional MOTO transactions.


Now the problem here is that there are also folk who just want to turn on
encryption and that is all and they don't care about doing online commerce
or banking. They just want to keep their email secret. And that is fine.
But that does not mean that people who only want to do confidentiality
should rip up the infrastructure that is designed to serve a different
purpose.

[Peter Kurrasch]

You are right to point out that many of those scenarios could be accomplished with a self-signed cert or indeed no cert at all. The decision to use a good cert or the likelihood of a good cert being used in any given scenario is not necessarily that important. What matters is that once we find a good cert has been used, what should we do about that cert?

I don't think we should absolve CA's of any responsibility or involvement when something "bad" comes along but neither do I think it falls entirely to them to figure out what to do. Getting the right balance will be tricky but I think it's worth fleshing out if people are interested.


  Original Message  
From: Nick Lamb
Sent: Thursday, May 26, 2016 1:25 PM‎

On Thursday, 26 May 2016 15:40:35 UTC+1, Peter Kurrasch wrote:

> I might use a perfectly good cert in a "bad" way:

Maybe it's worthwhile to consider what happens instead if we live under a regime (whether legally enforced or just de facto because of choices made by browser vendors) where you can't get a "perfectly good cert" for these scenarios. But in some cases I might not be clear what you propose.

> * ‎Create a phishing site to harvest login credentials from unsuspecting people. For this I might create my own bogus domain or piggyback off an existing, legitimate domain. Either way, I can use the cert to help create the illusion of legitimacy to a victim while I steal his or her info

You don't need your own "perfectly good" cert, the legitimate domain has one, which you retain. To stop this we must prevent legitimate domains obtaining certificates. There is precedent for this as an anti-crime strategy - don't try to arrest criminals, instead go after victims, with their prey thinning the criminals will starve. It's not terribly... nice, though is it?

> * Use a server to distribute malware via online adverts (malvertising). Having a cert helps make it look more legit and is required by some advertising services.

Again, it is much cheaper to use somebody else's servers. Since you're a criminal it hardly matters that this is illegal.

> * Set up a spam email server and use the cert for my login page to the control panel.‎ The cert wouldn't be used on the email side of things but controlling access to a server that lets me do bad stuff.

A self-signed certificate works for this purpose too. To prevent this we could perhaps outlaw encryption? Or email?

> * Use a server to distribute malware via downloads. When I launch a spam campaign I'll attach an infected document with some dropper malware in it. The dropper malware then contacts my server to get the real malware, be it ransomware or a banking trojan or remote desktop control or general zombie code or.... Whatever the case may be I can use certs to encrypt the malware download making it harder for people to figure out what's really going on.  

Again, self-signed certificates work fine. Indeed they are already widely used for this purpose.

> ‎* Sign my malware code so that Windows or MacOS will happily‎ install it.

As with web browsers the Dancing Pigs problem applies. Users will happily click past the "not signed, danger of death" dialog so long as they think they're getting nude pictures of a celebrity rather than having their bank account emptied.

We know the CA role isn't relevant here because in the Android ecosystem where there is no third party proof of identity users instead click past the (OS enforced) capabilities warnings, authorising an app to spend their money or spam their friends in the hope that this way they get to see the Dancing Pigs.

> ‎* Set up a command and control server and use certs to send encrypted messages between the malware on the devices I've pwnd and my server.

Self-signed certs work really well here.

> * Set up a media server so that people can download some great movies that I pilfered from someone else.

Self-signed certs are very popular in this role as far as I understand

> * Create a forum so people can talk about things their government does that really bugs them and how to evade the different law enforcement agencies.‎ Obviously I'm using certs to make it harder for those agencies to snoop on the forum participants. 

If you want to attract people who really care which type of foil is best then judging from openbsd-misc you should dismiss TLS altogether, they don't trust it at all. They will want a web-of-trust type setup, although (due to dancing pigs) they won't actually check any of the signatures so plaintext HTTP would also work (www.openbsd.org didn't do TLS until this month).

> * Set up an online marketplace to swap/buy/trade any compromised keys and the certs that go with them. Naturally I'd have a place to discuss which CA's have the easiest security measures to bypass.

It seems like the choice of certificate for the site itself is an implicit endorsement of one CA at least, is it not? But certainly such a group could use a self-signed certificate if they wanted, it's hardly as though they lack the sophistication.

> * And sometimes it's just fun to park outside a hotel and setup a free WiFi network to do some MITM. People do some crazy things when they think no one is watching, and certs keep people from getting suspicious that anything is amiss.

Have you actually tried this? Inside a corporation, with Group Policy and suchlike on your side, TLS MITM breaks all sorts of unexpected things still, causing our users to be quite irate (I'm on their side, but it's a big corporation...). I can't believe it would work even one tenth part so well with an unauthorised MITM these days with HSTS and so on. And I don't see how a few "bad" certificates from a public CA really contribute at all.

> * Oh, and Lenovo and Dell demonstrated some out of the box thinking with all the Superfish stuff.

Superfish is about adding an untrustworthy CA to the root store, is it not? That's an actual trust scenario. We don't trust Superfish, so they shouldn't be a CA. But end-entity (non-CA) certificates aren't about trust, they're about identity.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Thu, May 26, 2016 at 1:58 PM, Phillip Hallam-Baker
<ph...@hallambaker.com> wrote:
> What has encryption got to do with it?

The "bad" raised was unrelated to certificates, publicly trusted or
otherwise. As Nick also pointed out, a number of the "bad" is just as
accomplish through other means independent of certificates - whether
using raw public keys, DANE, etc. That is, the concerns raised were
about TLS, not about certificates.

> The WebPKI model was two stage. First we make it difficult for people to
> gain unlimited numbers of credentials. There is a cost to acquire a
> certificate that is (hopefully) low for a legitimate user but makes it
> uneconomic for a criminal to treat them as disposable.

That's not true, present or historically, but I don't believe it's
germane to the discussion to get into the nuance here, as it doesn't
really fit Peter (K's) discussion of bad.

> Now the problem here is that there are also folk who just want to turn on
> encryption and that is all and they don't care about doing online commerce
> or banking. They just want to keep their email secret. And that is fine. But
> that does not mean that people who only want to do confidentiality should
> rip up the infrastructure that is designed to serve a different purpose.

It would seem you're suggesting that CAs aren't the right
infrastructure to enable the Internet's growth and user's security,
which may be true, but would be a surprising statement to make.
Otherwise, the choice of the term "rip up" to suggest that, regardless
of original intent, the infrastructure may better serve users' and
security more by doing something more broadly scoped seems...
unnecessary simplistic.

Put differently, even if it were true that the goal of the Web PKI was
to "prevent bad," it still suffers from the same problem - first, the
definition of "bad" posited on this thread is largely related to
encryption (first and foremost), and thus orthogonal to certificates,
but in several of the remaining cases, the definition of bad is a
statement that users have unrealistic expectations about what
certificates can/do provide. Ironically, those unrealistic
expectations may have been caused by CAs themselves and by their
marketing teams.

So to address these "bad" uses of certificates, it's necessary as the
community to decide whether encryption is bad, whether the
'undesirable' uses of encryption and the desire to prevent such uses
is worth the risk to the 'good' uses of encryption and the desire to
promote them, and to decide on what the reasonable and realistic
expectations of certificates should be.

But I think it's uncharitable to suggest the infrastructure is being
ripped up - it's being questioned as to whether the original goals,
whatever they may be, were realistic, and whether the promises made,
especially by CAs, are ones we can or should keep.

[Peter Kurrasch]

I wasn't intending to get into a broader discussion about the merits of encryption. My initial point was two-fold: First, that there are a lot of different scenarios to consider--too many, in fact. Second, that a "good" cert could be used for any of those bad things, although the use of certs is not necessary in all cases. 

Regarding use of the term "bad", what does anyone think about this as an alternative: "furtherance of criminal activity"

Granted the term criminal might be a bit subjective, but I can't think of good uses for trojans or botnets or ransomware. And I would hope that CA's would agree that furtherance of criminal activity is an inappropriate use of the PKI system?

Thoughts? 


  Original Message  
From: Ryan Sleevi
Sent: Thursday, May 26, 2016 11:44 PM‎

On Thu, May 26, 2016 at 1:58 PM, Phillip Hallam-Baker
<ph...@hallambaker.com> wrote:
> What has encryption got to do with it?

The "bad" raised was unrelated to certificates, publicly trusted or
otherwise. As Nick also pointed out, a number of the "bad" is just as
accomplish through other means independent of certificates - whether
using raw public keys, DANE, etc. That is, the concerns raised were
about TLS, not about certificates.

...snip...

‎

[Nick Lamb]

On Friday, 3 June 2016 17:25:11 UTC+1, Peter Kurrasch wrote:
> Regarding use of the term "bad", what does anyone think about this as an alternative: "furtherance of criminal activity"

As far as I'm aware all of the following are examples of criminal activity:

Gambling (in some but not all of the United States of America)

Glorifying Adolf Hitler (in Germany).

Advertising the availability of sexual services such as in-call prostitution (United Kingdom)

Insulting the King of Thailand (Thailand)

Maybe you personally don't think any of the above should be permitted on the World Wide Web. But this discussion is about the policy of Mozilla's trust store and not about you personally, so the question becomes whether any Mozilla users expect to be able to "further" any of these activities using Firefox and I think the unequivocal answer is yes, yes they do.

[Phillip Hallam-Baker]

On Fri, Jun 3, 2016 at 2:03 PM, Nick Lamb <tiala...@gmail.com> wrote:

> On Friday, 3 June 2016 17:25:11 UTC+1, Peter Kurrasch wrote:

> > Regarding use of the term "bad", what does anyone think about this as an
> alternative: "furtherance of criminal activity"
>

> As far as I'm aware all of the following are examples of criminal activity:
>
> Gambling (in some but not all of the United States of America)
>
> Glorifying Adolf Hitler (in Germany).
>
> Advertising the availability of sexual services such as in-call
> prostitution (United Kingdom)
>
> Insulting the King of Thailand (Thailand)
>
> Maybe you personally don't think any of the above should be permitted on
> the World Wide Web. But this discussion is about the policy of Mozilla's
> trust store and not about you personally, so the question becomes whether
> any Mozilla users expect to be able to "further" any of these activities
> using Firefox and I think the unequivocal answer is yes, yes they do.

> _______________________________________________
>

The original design of the WebPKI required authentication of the
organization for that exact reason.

If a company is registered in Germany, you probably expect it to follow
German laws. If you are buying from a company, the fact that they are
registered in Germany or Nigeria may affect the expectations you have for
performance of the contract - and the types of assurance you would require.