RE: Certificate validation phishing

[Jeremy Rowley]

And why wouldn't a request token fit the patent's interpretation of a "Pass
String"? The only definition I saw in the patent was something generated by
the validating entity and forwarded to the requester. The pass string can be
a code, but that does not necessarily preclude a request token.

"1. the CA picks a random string containing at least 128-bits of entropy and
tells the ACME client" = Pass String?

The rest is really an add on to the Pass String, but there it still looks
like Acme is using a Pass String.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb
Sent: Monday, January 23, 2017 3:42 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate validation phishing

On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley  wrote:
> What do you mean they are weak sauce? Considering at least one of the 
> patents is claimed to cover the ACME challenge validations, they seem 
> pretty on-point.

I thought my comparison illustrated very well what I meant by weak sauce.
People can _claim_ anything they want. Nothing I've seen in the patents
comes close to achieving the desired confidence that the would-be subscriber
is able to exert control over the FQDN to be validated.

[ The remainder of this post might feel like it's picking on GoDaddy. But
actually all the patents are awful, they're just serving as an illustration
]

There are three ACME challenge validations in use today, two are already
covered in Baseline Requirements document version 1.4.2. so that leaves only
dns-01 which would be covered under the proposed 3.2.2.4.7 from Ballot 182
(and Ballot 169).

GoDaddy claims US9183368 is relevant to 3.2.2.4.7 but they have not, so far
as I've seen, claimed that US9183368 actually impacts the ACME dns-01
challenge.

US9183368 is concerned with a "Pass String" which is analogous to the Random
Value described in part of 3.2.2.4.7. The CA chooses a "Pass String", this
is communicated somehow to the would-be subscriber, and then the CA checks
whether it appears in a DNS TXT or CNAME record. That's it, validation done,
That's what I mean by weak sauce. What did we validate? What are we sure
about? Not very much.

ACME's dns-01 challenges can't use a Random Value approach, it would not
achieve the confidence we want that the would-be subscriber and whoever is
fiddling with DNS are one and the same. Fortunately 3.2.2.4.7 also offers
the possibility of using a Request Token rather than a Random Value so ACME
does this:

1. the CA picks a random string containing at least 128-bits of entropy and
tells the ACME client

2. the ACME client uses its private key (the ACME account key, not the
private half of the key for an X.509 certificate) to sign a data structure
containing the random string called a "key authorization"

3. the ACME client puts a base-64 encoded SHA256 digest of the key
authorization in a DNS TXT record [there's your Request Token]

4. the ACME client sends the whole key authorization back to the CA

5. the CA checks the DNS TXT record, verifies that there's a digest inside,
that the digest matches the provided key authorization, that the key
authorization is signed by the ACME account key, and that the authorization
is for the random string it chose in step 1. Only if all these checks pass
is the FQDN validated for this ACME account.

The "Pass String" idea is very simple, but it's wholly inferior in terms of
the confidence that can be achieved.

In particular, the Pass String is subject to a trivial MITM. Anyone who can
convince me to perform US9183368 based validation can use that to pass other
DNS-based validations, whether US9183368 or something else. So maybe I
thought I was validating my domain for a new advertising network, or a
government scheme, but instead I just validated their control of my domain
to a CA and they're getting a certificate issued.

Because the ACME approach uses public key crypto it can render a MITM
ineffective. If Monika chooses to use her own ACME account key then she
can't get the appropriate key authorization digest into the victim's DNS. If
Monika instead lets the victim use their own ACME account keys, the digest
will match up but Monika can't obtain a certificate because now the
validation belongs to the victim.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Misissued/Suspicious Symantec Certificates

[Ryan Sleevi]

Steve,

While I understand that your investigation is ongoing, this does seem
extremely similar, if not identical, to Symantec's previous misissuance.

In that previous incident, Symantec took a number of steps - beginning with
reportedly immediately terminating the employees responsible and then
continuing to a comprehensive system overhaul, as detailed at
https://www.symantec.com/page.jsp?id=test-certs-update#

What is particularly concerning here is that your current explanations
suggest that either they are incomplete, or that Symantec's previous
answers were either misleading or incorrect. This is extremely concerning,
and I'm hoping you can clarify with answers to the following questions,
independent of your ongoing investigation and as soon as possible:

1) In response to the previous incident, Symantec indicated they hold a "no
compromise" bar for such breaches in the post titled "A tough day as
leaders". [1]
  a) Do you believe that the steps to "reduce privileges" represent a
consistent application of that standard?
  b) If not, what additional steps are you taking, consistent with your "no
compromise" standard?

2) In response to the previous incident, Symantec indicated that the use of
any privileged test tool would require senior leader justification from
both QA and Production Operations teams and approvals from the heads of
Engineering and Policy Compliance. [2]
  a) Did Symantec mean that this was limited to validations performed by
Symantec, and not that of Registration Authorities fulfilling the duties
pursuant to Section 1.3.2 of the Baseline Requirements?
  b) At the time Symantec made this statement, did Symantec have any
Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of
the Baseline Requirements?
  c) If such a statement was meant to be limited to Symantec, and not that
of Registration Authorities, why did Symantec not feel it was appropriate
to highlight that it did not extend to activities performed by Registration
Authorities?
  d) If such a statement was not meant to be limited to Symantec, was such
a justification provided, and approvals granted, for the tool that allowed
such Registration Authorities to issue these certificates?

3) In response to the previous incident, Symantec indicated a comprehensive
review of issuance privileges was conducted to ensure only authorized
personnel have the ability to issue certificates, and that a quarterly
access review would be conducted to ensure this. [2]
  a) Did such comprehensive review include that of Registration Authorities?
  b) If not, why did Symantec not disclose that Registration Authorities
were excluded?
  c) Is Symantec currently performing access reviews of Registration
Authorities?
  d) If so, when does Symantec expect this to be completed?

4) In response to the previous incident, Symantec indicated it updated its
internal policies and procedures for test certificates as used for
commercial certificates. Further, it indicated that QA engineers and
authentication personnel were trained on updated practices for test
certificates. [2]
  a) Did Symantec include Registration Authorities in the scope of that
training?
  b) If not, why did Symantec not disclose that Registration Authorities
were excluded?
  c) If so, why did Symantec's corrective actions for the previous
misissuance fail to prevent this continued misissuance?

5) You have indicated that you have at least one WebTrust audited partner
capable of causing issuance using Symantec-operated CAs.
  a) Please provide a link to the audit results for each of these WebTrust
audited partners.
  b) Have you suspended the capabilities of these partners until Symantec
completes its investigation?
  c) If not, why not, and when do you expect to do so?

6) Does Symantec allow is Registration Authorities to deviate from the
policies and standards set forth by its CP, CPS, and internal policies and
controls?
  a) If not, why did Symantec fail to detect that its Registration
Authorities were deviating from its policies for this long?
  b) If so, where does Symantec disclose this deviation within its CP
and/or CPS?

7) When do you expect to provide the next update as to the ongoing
investigation? If it is not within the next three days, why?


Thank you for your time in answering each and every one of these questions
and providing further details, so as to help inform the broader community
as to the steps Symantec has taken and is taking to prevent continued
misissuance contrary to the Baseline Requirements and the Mozilla CA
Certificate Policy.

[1] http://archive.is/Ro70U
[2] https://www.symantec.com/page.jsp?id=test-certs-update
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Question about Baseline Requirements section #7.1.4.2

[Peter Bowen]

On Mon, Jan 23, 2017 at 3:32 PM, Kathleen Wilson  wrote:
> Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only 
> apply to end-entity certificates?
>
> If yes, where does it specify that in the document?
>
> This has come up in a few CA requests, due to errors we get when we run 
> Kurt's x509lint test.
> Example:
> https://github.com/kroeckx/x509lint/issues/17
> https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c17

Kathleen,

I believe that it does not apply to CA certificates, but I can see how
this is not clear.

To help understand the intent of this section, it is helpful to look
at the history of the section.  7.1.4.2 has not been substantially
changed since BR 1.3.0, which was the version that switched from the
old structure to the new RFC 3647 structure.  As seen in
https://cabforum.org/wp-content/uploads/RFC3647_Comparison_Table_for_Baseline_Requirements.pdf,
7.1.4.2 was previously section 9.2 and 7.1.4.1 was previously section
9.1.

In 2015, the CA/Browser Forum passed ballot 148
(https://cabforum.org/2015/04/02/ballot-148-issuer-field-correction/)
which changed sections 9.1 and 9.2 and appears to clearly call out
that the intent is to require different content in the subjects for CA
certificates than end-entity certificates.

I agree that the BRs could be clearer, but it seems to me that the
only requirements are country and organization name.

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

Question about Baseline Requirements section #7.1.4.2

[Kathleen Wilson]

All,

Does section 7.1.4.2 of the CA/Browser Forum's Baseline Requirements only apply 
to end-entity certificates?

If yes, where does it specify that in the document?

This has come up in a few CA requests, due to errors we get when we run Kurt's 
x509lint test.
Example: 
https://github.com/kroeckx/x509lint/issues/17
https://bugzilla.mozilla.org/show_bug.cgi?id=1099311#c17

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

Re: Certificate validation phishing

[Nick Lamb]

On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley  wrote:
> What do you mean they are weak sauce? Considering at least one of the
> patents is claimed to cover the ACME challenge validations, they seem pretty
> on-point.

I thought my comparison illustrated very well what I meant by weak sauce. 
People can _claim_ anything they want. Nothing I've seen in the patents comes 
close to achieving the desired confidence that the would-be subscriber is able 
to exert control over the FQDN to be validated.

[ The remainder of this post might feel like it's picking on GoDaddy. But 
actually all the patents are awful, they're just serving as an illustration ]

There are three ACME challenge validations in use today, two are already 
covered in Baseline Requirements document version 1.4.2. so that leaves only 
dns-01 which would be covered under the proposed 3.2.2.4.7 from Ballot 182 (and 
Ballot 169).

GoDaddy claims US9183368 is relevant to 3.2.2.4.7 but they have not, so far as 
I've seen, claimed that US9183368 actually impacts the ACME dns-01 challenge.

US9183368 is concerned with a "Pass String" which is analogous to the Random 
Value described in part of 3.2.2.4.7. The CA chooses a "Pass String", this is 
communicated somehow to the would-be subscriber, and then the CA checks whether 
it appears in a DNS TXT or CNAME record. That's it, validation done, That's 
what I mean by weak sauce. What did we validate? What are we sure about? Not 
very much.

ACME's dns-01 challenges can't use a Random Value approach, it would not 
achieve the confidence we want that the would-be subscriber and whoever is 
fiddling with DNS are one and the same. Fortunately 3.2.2.4.7 also offers the 
possibility of using a Request Token rather than a Random Value so ACME does 
this:

1. the CA picks a random string containing at least 128-bits of entropy and 
tells the ACME client

2. the ACME client uses its private key (the ACME account key, not the private 
half of the key for an X.509 certificate) to sign a data structure containing 
the random string called a "key authorization"

3. the ACME client puts a base-64 encoded SHA256 digest of the key 
authorization in a DNS TXT record [there's your Request Token]

4. the ACME client sends the whole key authorization back to the CA

5. the CA checks the DNS TXT record, verifies that there's a digest inside, 
that the digest matches the provided key authorization, that the key 
authorization is signed by the ACME account key, and that the authorization is 
for the random string it chose in step 1. Only if all these checks pass is the 
FQDN validated for this ACME account.

The "Pass String" idea is very simple, but it's wholly inferior in terms of the 
confidence that can be achieved.

In particular, the Pass String is subject to a trivial MITM. Anyone who can 
convince me to perform US9183368 based validation can use that to pass other 
DNS-based validations, whether US9183368 or something else. So maybe I thought 
I was validating my domain for a new advertising network, or a government 
scheme, but instead I just validated their control of my domain to a CA and 
they're getting a certificate issued.

Because the ACME approach uses public key crypto it can render a MITM 
ineffective. If Monika chooses to use her own ACME account key then she can't 
get the appropriate key authorization digest into the victim's DNS. If Monika 
instead lets the victim use their own ACME account keys, the digest will match 
up but Monika can't obtain a certificate because now the validation belongs to 
the victim.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate validation phishing

[Jeremy Rowley]

What do you mean they are weak sauce? Considering at least one of the
patents is claimed to cover the ACME challenge validations, they seem pretty
on-point.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb
Sent: Sunday, January 22, 2017 4:27 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate validation phishing

On Sunday, 22 January 2017 10:09:26 UTC, Lewis Resmond  wrote:
> The real solution would be a CAB/BR requirement forcing the CAs not to use
the domain validation method XYZ, once it has been proven as vulnerable.

There are no doubt an unlimited number of vulnerable methods possible.
Instead, and I would argue better, Ballot 169 explicitly listed all the
acceptable means of validation.

However Ballot 169 revealed that several CA/B members have patents related
to domain validation, and that woke a sleeping giant. The patented methods
are in my opinion very weak sauce. They are to the ACME challenge
validations what a plank of wood laid over a stream is to the Bay Bridge.
However they probably reflect, more or less, the actual practice at major
public CAs today.

Of course the CA/B says itself these are only Baseline Requirements, and
Mozilla is free to insist members of its root programme do the moral
equivalent of implementing Ballot 169 anyway, as Ryan has proposed in
another thread.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate validation phishing

[tdelmas]

On Monday, January 23, 2017 at 10:34:42 AM UTC+1, Santhan Raj wrote:
> If a domain administrator approves a request without checking why/who needs 
> the cert, there is little a CA can do to mitigate such threats.

I agree. But the CA could help prevent these threats.

And, in that specific case, the CA did facilitate that threat by stating a 
falsehood: The CA stated that a legitimate employee did requested the cert, 
when, in fact, the CA has no idea who requested it (If I'm not mistaken, in 
both my tests the CA did not validate the ownership of the email of the 
"employee" asking the certificate).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate validation phishing

[Santhan Raj]

If a domain administrator approves a request without checking why/who needs the 
cert, there is little a CA can do to mitigate such threats. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy