Re: When good certs do bad things

[Ryan Sleevi]

On Thu, May 26, 2016 at 1:58 PM, Phillip Hallam-Baker
 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: When good certs do bad things

[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 

Re: Job: Is it OK to post a job listing in this forum?

[David E. Ross]

> On Thu, May 26, 2016 at 6:17 PM, Kathleen Wilson 
> wrote:
> 
>> Hi All,
>>
>> I have been asked if it is OK to post job listings in
>> mozilla.dev.security.policy. Surprisingly, I don't recall ever being asked
>> that question before, and I am not aware of a written policy about the
>> content of postings to mozilla.dev.security.policy.
>>
>> So, here is a proposal:
>> ~~
>> Jobs may be posted if they meet the following criteria:
>> * The company/organization name is clearly listed
>> * The person posting the job information actually works for that
>> company/organization and is not a contracted recruiter
>> * A single posting only (for each job opportunity)
>> * The person posting the job info is actively engaged in this
>> mozilla.dev.security.policy forum
>> * The job opportunity is a role relevant to the forum's audience
>> * The posting consists of a paragraph outline and a "read more" URL
>> * The Subject of the posting begins with "Job: "
>> ~~
>>
>> Does that sound reasonable?
>>
>> As always, I will appreciate thoughtful and constructive input.
>>
>> Thanks,
>> Kathleen

I would have several concerns, mostly about Mozilla's ability to verify
the criteria are met and the effort to do that verification.  For
example, how would anyone here verify the following?

 * The company/organization name is clearly listed [that the listed
company would indeed be the actual employer]

 * The person posting the job information actually works for that
company/organization and is not a contracted recruiter [that the person
posting is a W2 employee of the actual employer and not a 1099-MISC
contractor]

 * The job opportunity is a role relevant to the forum's audience [who
would review the posting to verify this?]

If this is a valid use of news.mozilla.org, then perhaps a new MODERATED
newsgroup would be appropriate.  However, that would still require
assigning staff to moderate and monitor the postings, for which there
would be a cost.

-- 
David E. Ross
.

Donald Trump claims he is a successful businessman.
If so, how does he explain the number of his
enterprises that have gone bankrupt?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Job: Is it OK to post a job listing in this forum?

[Eric Mill]

I could tolerate a policy like that, and it's always possible to revisit it
if it turns out to be abused, or causes people to unsubscribe (which I
would recommend Mozilla watching, especially right after postings go out).

One suggested change:

> * The Subject of the posting begins with "Job: "

I would suggest "Job Posting:" (or something else equally specific), so
that I could apply a filter if I wanted, without accidentally filtering
threads along the lines of "Is it the CA's job to police malware?"

-- Eric

On Thu, May 26, 2016 at 6:17 PM, Kathleen Wilson 
wrote:

> Hi All,
>
> I have been asked if it is OK to post job listings in
> mozilla.dev.security.policy. Surprisingly, I don't recall ever being asked
> that question before, and I am not aware of a written policy about the
> content of postings to mozilla.dev.security.policy.
>
> So, here is a proposal:
> ~~
> Jobs may be posted if they meet the following criteria:
> * The company/organization name is clearly listed
> * The person posting the job information actually works for that
> company/organization and is not a contracted recruiter
> * A single posting only (for each job opportunity)
> * The person posting the job info is actively engaged in this
> mozilla.dev.security.policy forum
> * The job opportunity is a role relevant to the forum's audience
> * The posting consists of a paragraph outline and a "read more" URL
> * The Subject of the posting begins with "Job: "
> ~~
>
> Does that sound reasonable?
>
> As always, I will appreciate thoughtful and constructive input.
>
> Thanks,
> Kathleen
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Job: Is it OK to post a job listing in this forum?

[Kathleen Wilson]

Hi All,

I have been asked if it is OK to post job listings in 
mozilla.dev.security.policy. Surprisingly, I don't recall ever being asked that 
question before, and I am not aware of a written policy about the content of 
postings to mozilla.dev.security.policy.

So, here is a proposal:
~~
Jobs may be posted if they meet the following criteria:
* The company/organization name is clearly listed
* The person posting the job information actually works for that 
company/organization and is not a contracted recruiter
* A single posting only (for each job opportunity)
* The person posting the job info is actively engaged in this 
mozilla.dev.security.policy forum
* The job opportunity is a role relevant to the forum's audience
* The posting consists of a paragraph outline and a "read more" URL
* The Subject of the posting begins with "Job: " 
~~

Does that sound reasonable?

As always, I will appreciate thoughtful and constructive input.

Thanks,
Kathleen


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

Re: When good certs do bad things

[Ryan Sleevi]

On Thu, May 26, 2016 at 7:40 AM, Peter Kurrasch  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: SSL Certs for Malicious Websites

[Hubert Kario]

On Thursday 26 May 2016 05:13:43 Peter Gutmann wrote:
> Richard Z  writes:
> >If any criminal can easily get EV certificates what is the point of
> >https?
> The point of HTTPS is twofold:
> 
> 1. Convince users that the Internet is safe to do business on
> (financial transfers, medical data).
> 
> 2. Provide a steady revenue stream for CAs.
> 
> There's also something about privacy from NSA snooping, but that's a
> recent thing, and mostly only geeks care about it.  In addition
> depending on how paranoid the geeks are, HTTPS may not provide the
> privacy they want).

people don't care only if you are asking the wrong questions[1], if you 
frame the question in the way they do understand, they do care: 
https://www.youtube.com/watch?v=XEVlyP4_11M

 1 - https://www.youtube.com/watch?v=G0ZZJXw4MTA
 
> Finally, point 1 doesn't really need HTTPS, you could just slap a
> padlock into the UI and not bother with encryption.  So it's mostly
> point 2.

I don't think that this level of cynicism is helping...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Ryan Sleevi]

On Wed, May 25, 2016 at 6:50 AM,   wrote:
> If I understand you correctly, you are saying that CAs should not be doing 
> any "internet policing" or "content policing" when they receive credible 
> reports their certs are being used by phishers, malware providers, etc. -- 
> but that browsers can and should do "internet policing" or "content policing" 
> when they blacklist sites on such applications as Google Safe Browsing and 
> Microsoft Smart Screen -- am I stating that correctly?  If so, I was not the 
> one to introduce the topic to this string.

As Eric pointed out, no, you are not understanding correctly. I was
merely addressing Kathleen's question about whether all CAs are
required to police, not whether some CAs can, if they so decide. I
don't believe CAs SHOULD police, but that's irrelevant to the more
substantial question - I don't believe CAs MUST police.

> Plus -- I don't agree this string is about promoting encryption only.

That's OK. It's clear we disagree about the value of privacy,
confidentiality, and integrity - which TLS provides. I believe these
three are valuable in and of themselves, and we must not sacrifice
them in order to also add 'brand protection'.

>  Kathleen started by asking for interpretation of existing BR language that 
> requires CAs to revoke and/or non-issue for things like "Certificate misuse, 
> or other types of fraud, compromise, misuse, or inappropriate conduct related 
> to Certificates."

And that's what I was responding to, but you then dove-tailed into an
unrelated discussion about how Microsoft/Google technologies work,
which doesn't seem as germane to the question.

> Why should CAs delegate to or rely on browsers for this type of user 
> protection?

Because security works best when it's composed. Why should CAs
delegate encryption to TLS? Why shouldn't each CA come up with their
own encryption technology, and deploy it using browser plugins? Why
should CAs rely on DNS? Why shouldn't they come up with their own
naming schemes?

The answer is that different parties in the ecosystem have different
roles, and are best suited to different tasks. You've already heard,
several times, the answer to your question - because CAs content
policing themselves comes with real risks and harm. While some CAs
may, as part of their brand, choose to do content policing, site
operators have an easy recourse - simply don't use those CAs. The
market is flexible to permit that. Suggesting, however, that ALL CAs
must do so, implies that ALL CAs must share your values, and it's
clear that such a position can and does cause real harm.

> Isn't it better for CAs to remain involved by revoking certs / refusing to 
> issue certs to known bad sites, like CAs have done for at least the past 8 
> years - why change that now?  Why can't both CAs and browsers work together 
> for maximum user protection?

This has already been responded to several times by participants on
the thread. I don't think it adds value to keep saying it, and it's
been said in a variety of ways that I don't think it bears restating.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy