Re: SSL Certs for Malicious Websites

[Eric Mill]

On Mon, May 16, 2016 at 8:24 AM, Ben Wilson  wrote:

> Gerv wrote,
> "Counter-question to many of these: who defines what is malware, and who
> made them king?"
>
> The contract that the CA enters into with the  subscriber should have done
> that.
>
> Subscriber Agreements should have language in them that says something to
> the effect, "We can revoke your certificate if you are [insert bad
> behavior]
> as we determine [insert evidentiary standard or threshold]."  (The
> evidentiary standard might be "as we reasonably believe", "as we determine
> in our sole discretion", etc.)
>

Individual CA terms of service are a much more reasonable place for these
kinds of requirements. That's something CAs can put in their marketing as a
feature to audiences that want that. It doesn't stop malware actors from
getting certificates from CAs that don't police malware, but given that
certificates today are being automatically dispensed for free based sheerly
on technical validation, preventing malware from *obtaining* a certificate
seems like a losing battle.

Putting malware policing into root program requirements is significantly
more dangerous, because that root program has what amounts to unchecked
policing power over any HTTPS domain. And since revocation isn't even
enforced except in limited circumstances by the most popular browser
(Chrome), the positive impact of revoking a malware site's certificate is
quite limited.

So using revocation to block malware is the worst of both worlds: revoking
a "bad guy" certificate fails to save everyone from the bad guy, yet
revoking a "good guy" certificate prevents the good guy from serving a
significant chunk of the global population. And while the folks on this
list might have a similar and narrow shared mental conception of malware,
in the long run and at global scale, "misuse" can get a lot more
subjective.

Will this also be how IP holders might pursue relief if they don't like how
the DMCA safe harbor is working out? Or how a government blocks the release
of material it believes to be classified or societally harmful? It could be
a lot easier and cheaper to convince a root program to tell a CA to revoke
a certificate than it is to convince a judge or go through ICANN's UDRP. It
would also come with zero oversight or defined public process, or the
opportunity for the public interest to be represented.

The absolute last place it should be is in CA/B Forum requirements. Peter
already pointed to some helpful language in the EV Guidelines that suggests
that the Baseline Requirements are explicitly not trying to be in this
business. If there's still ambiguity, maybe Mozilla can be helpful in
resolving it.

More generally, the IANA transition has brought a ton of scrutiny to
internet governance and the role of US governments and corporations in
managing the internet's name system. That scrutiny will only increase,
especially as other large countries clamor for more control and
sovereignty. If HTTPS should be the default on the internet, and the CA
system is the only thing we have right now that can guarantee it, then root
programs and the CA/B Forum start to look a lot like a new internet
governance body.

Being an internet governance body comes with real obligations to the
public, and the real potential to see involuntary regulation if
self-regulation fails. Since only CAs can issue certificates, while other
layers can defend users against malware, the CA system at large should be
very careful about how it weighs malware defense alongside its other
responsibilities.

-- Eric


> ___
> 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

Re: SSL Certs for Malicious Websites

[Kathleen Wilson]

On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
> I am wondering if the BRs need to be updated to:
> + Define what is meant by "Certificate misuse, or other types of fraud". 
> (e.g. being used for a purpose outside of that contained in the cert, or 
> applicant provided false information.)
> + Add text similar to what is in the EV Guidelines stating that TLS/SSL 
> certificates focus only on the ownership of the domain name(s) included in 
> the certificate, and not on the behavior of the website. Note that the BRs 
> already have section 9.6.1 about certificate warranties.
> 

Would someone please volunteer to take this up with the CA/Browser Forum?


I also see a couple places in Mozilla's CA Certificate Policy where the words 
'fraudulent' and 'misused' appear without having been defined...

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"4. We reserve the right to not include a particular CA certificate in our 
software products. This includes (but is not limited to) cases where we believe 
that including a CA certificate (or setting its "trust bits" in a particular 
way) would cause undue risks to users’ security, for example, with CAs that
- knowingly issue certificates without the knowledge of the entities whose 
information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for fraudulent use."

What is meant by "fraudulent use"?
Is the second bullet point essentially a restatement of the first bullet point?
Should the second bullet point be deleted?


https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
"2. CAs must revoke Certificates that they have issued upon the occurrence of 
any of the following events: 
... the CA obtains reasonable evidence that the subscriber’s private key 
(corresponding to the public key in the certificate) has been compromised or is 
suspected of compromise (e.g. Debian weak keys), or that the certificate has 
otherwise been misused;"

Proposal:
Change
"or that the certificate has otherwise been misused;"
to
"or that the certificate has been used for a purpose outside of that indicated 
in the certificate or in the CA's subscriber agreement;"


Thanks,
Kathleen



___
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

[Nick Lamb]

On Tuesday, 17 May 2016 04:19:57 UTC+1, Peter Gutmann  wrote:
> So you're saying users expect CAs to certify malware sites?

I'm a user, and that's what I expect, so trivially yes.
___
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

[Jernej Simončič]

On Tue, 17 May 2016 12:51:53 +0200, Hubert Kario wrote:

> problem is, that this is a slippery slope. What's malware for one person 
> is a research subject for another. What's inflammatory or misleading 
> information for one person is parody and joke material to other. What's 
> illegal in one jurisdiction is completely legal and normal or at least 
> socially acceptable behaviour in another.

I've had problems in the past because files that I host consistently
trigger antivirus warnings, despite being harmless (examples: GIMP
installer for Windows, debug data for GIMP and wget, netcat for Windows).
Luckily, the worst that came from it were some e-mail exchanges and a
lengthy phonecall with my ISP, but I know of people who lost their hosting
thanks to having files that were similarly triggering false antivirus
alerts.

-- 
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CSV Format of CA Program reports

[Rob Stradling]

On 17/05/16 07:09, Miskovic Peter wrote:

Hi Rob,

there are two intermediate certification authorities on your missing list (CA 
Disig I2 Certification Service and CA Disig I1 Certification Service) which are 
no more capable to issue a new SSL certificate and which are no more directly 
chain to a certificate included in Mozilla's CA Certificate Program.

According to the Mozilla CA Certificate Inclusion Policy (Version 2.2):

"All certificates that are capable of being used to issue new certificates, and 
which directly or transitively chain to a certificate included in Mozilla's CA 
Certificate Program, MUST be operated in accordance with Mozilla's CA Certificate Policy 
and MUST either be technically constrained or be publicly disclosed and audited."

The root for that intermediates (CA Disig) was removed from Mozilla's CA 
Certificate Program (see https://bugzilla.mozilla.org/show_bug.cgi?id=1247711) 
due the expiration.


Peter, thanks for pointing that out.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Hubert Kario]

On Tuesday 17 May 2016 03:19:22 Peter Gutmann wrote:
> Matt Palmer  writes:
> >On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:
> >> knowingly issuing/tolerating certificates for sites known to inject
> >> malware is
> >> * contrary to user expectaions
> >
> >[Citation needed]
> 
> So you're saying users expect CAs to certify malware sites?
> 
> (There have been plenty of user studies showing that users expect the
> padlock to protect them from malware, hackers, and all sorts of other
> stuff.  Please produce a study showing that users expect CAs to
> certify malware sites and virus authors).

then users expect impossible

Go to Firefox and check what the connection information dialog says.
Does it say that the party you're communicating with is trustworthy?

CAs certify identity, always had, and unless they themselves start 
hosting those websites, they have no way to certify trustworthiness of 
the data served.
-- 
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: CSV Format of CA Program reports

[Miskovic Peter]

Hi Rob,



there are two intermediate certification authorities on your missing list (CA 
Disig I2 Certification Service and CA Disig I1 Certification Service) which are 
no more capable to issue a new SSL certificate and which are no more directly 
chain to a certificate included in Mozilla's CA Certificate Program.

According to the Mozilla CA Certificate Inclusion Policy (Version 2.2):

"All certificates that are capable of being used to issue new certificates, and 
which directly or transitively chain to a certificate included in Mozilla's CA 
Certificate Program, MUST be operated in accordance with Mozilla's CA 
Certificate Policy and MUST either be technically constrained or be publicly 
disclosed and audited."



The root for that intermediates (CA Disig) was removed from Mozilla's CA 
Certificate Program (see https://bugzilla.mozilla.org/show_bug.cgi?id=1247711) 
due the expiration.



Regards

Peter Miskovic

-
Peter Miskovic
CA Chief Operating Officer

Disig, a.s., Zahradnicka 151, 821 08 Bratislava 2, Slovakia
phone  +421 2 20 85 01 50

peter.misko...@disig.sk
www.disig.sk











-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+peter.miskovic=disig...@lists.mozilla.org] 
On Behalf Of Rob Stradling
Sent: Tuesday, May 17, 2016 12:31 AM
To: Kathleen Wilson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CSV Format of CA Program reports



Thanks Kathleen.



PublicAllIntermediateCertsCSV is missing quite a few entries compared to my own 
CSV export of the "All Public Intermediate Certs" report.



I've reviewed the differences.  It looks like you're now omitting incomplete 
records and records for intermediates that didn't actually need to be 
disclosed.  I presume this is deliberate change, and I think it makes sense.



In case anyone's interested, here's a list of the currently disclosed 
intermediates that aren't in PublicAllIntermediateCertsCSV:

https://docs.google.com/spreadsheets/d/1nd2ie-JsS2CxMOX5nBGQgQEelhmkq-OcTKkvCe4U42Q/edit?usp=sharing



One oddity: Some intermediates (e.g. https://crt.sh/?id=17014784) contain the 
EKU extension with the MS SGC and/or NS Step-Up OIDs and _not_ 
id-kp-serverAuthentication.  The policy says that these don't need to be 
disclosed, but Firefox does trust them as issuers of server authentication 
certs.



On 16/05/16 19:27, Kathleen Wilson wrote:

> The new reports are at the following new links. A couple columns were added: 
> 'Parent Name', 'SHA-256 Fingerprint'.

>

> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCert

> s

> https://mozillacaprogram.secure.force.com/CA/PublicAllIntermediateCert

> sCSV

>

> I have also updated the links in wiki page.

> https://wiki.mozilla.org/CA:SubordinateCAcerts

>

> Thanks,

> Kathleen



--

Rob Stradling

Senior Research & Development Scientist

COMODO - Creating Trust Online

___

dev-security-policy mailing list

dev-security-policy@lists.mozilla.org

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