Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

2017-04-01 Thread urijah--- via dev-security-policy
I think page 8 of their manual at least partially explains how and what 
"QuickInvite" is. The whole document is rather interesting...

https://www.geotrust.com/geocenter/resources/partnercenter-user-guide.pdf

On Saturday, April 1, 2017 at 6:01:23 AM UTC-4, Nick Lamb wrote:
> On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com  wrote:
> > I'm Tarah. I am the Principal Security Advocate and Senior Director of 
> > Engineering at Symantec Website Security (the certificate authority.
> 
> Hello Tarah,
> 
> Regular readers of m.d.s.policy will not be surprised that the news media 
> doesn't do a great job of explaining problems with the Web PKI.
> 
> As so often I have questions, none of which involve kittens or Ferris Bueller 
> but instead today focus on QuickInvite URLs.
> 
> 1. Symantec's own web site describes "Quick Invite" in several places, I 
> presume this is the same QuickInvite system you're talking about. It explains 
> that "The Quick Invite Duration default expiration time is 30 days, but can 
> be set during the sending of the invite" with a maximum of one year. 
> Presumably this is simply obsolete documentation, or else it refers to some 
> other feature under a similar name? If the former, I am happy to provide the 
> URLs where I found this, are you able to ensure they get updated or removed ?
> 
> 2. What was the designed purpose of the QuickInvite URL / the QuickInvite 
> system itself ? I appreciate that for you its purpose is very obvious as 
> you've spent time up to your neck in it, but to me it's still rather opaque. 
> Let me set out some possible actors in our play, and hopefully you can tell 
> me which actors arrange for the URL to be sent out, which actors receive it, 
> and what they can do with it. That last is quite important. If the list I 
> provide is inadequate feel free to invent more people, just explain what they 
> do.
> 
> Exam PLE is a small business with a web site, www.example.com
> Andrea is the sysadmin at Exam PLE
> Betty is Alice's boss, her details are listed in WHOIS for example.com
> Catherine is an employee at the CA, Symantec
> Jo is an SSL reseller, she offers cheap Symantec certs
> Valorie is a seemingly helpful person who answers Andrea's queries on Q 
> sites
> Wendy runs a web hosting business, she runs the servers www.example.com uses

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


Re: Next CA Communication

2017-04-01 Thread Gervase Markham via dev-security-policy
On 31/03/17 22:20, Kathleen Wilson wrote:
> Please let me know asap if you see any problems, typos, etc. in this
> version.

Now that policy 2.4.1 has been published, we should update Action 3 to
say the following at the top:

Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been
published. Differences between 2.4 and 2.3 (published Dec 2016),
and between 2.4 and 2.2 (published July 2013) may be viewed on
Github. Version 2.4.1 contains exactly the same normative requirements
as version 2.4 but has been completely reorganized. Please review
version 2.4.1 policy and confirm that your CA complies with it.


And then change the "2.4" to "2.4 or 2.4.1" underneath the bullet points.

Other than that, LGTM - ship it :-)

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


Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

2017-04-01 Thread Gervase Markham via dev-security-policy
Hi Daniel,

We appreciate your additional input into determining the exact scope of
this problem.

On 31/03/17 19:37, Daniel Baxter (Aractus) wrote:
> With all due respect this reply is the most ridiculous load of
> nonsense I've ever read.

However, please keep the tone civil. If it's nonsense, demonstrate why
that's so rather than asserting it.

> Yeah OK, I got a few things wrong on my blog post, I can fix that
> shortly. 

We would appreciate it if you would let us know what the updates are.

> Firstly you claim email accounts should be secure - um since WHEN?

Regardless of the wisdom of this assertion, it is true that many CAs
rely on the (relative) security of email when doing domain validation.
Symantec is not alone in this respect. It's probably not productive to
have an argument at this point over whether email-based domain
validation is a good idea or not.

> Next, you say that URLs in emails should be treated like a password.
> Um - SINCE WHEN? And furthermore, if it should be treated as a
> password, if that's your claim, WHY ARE THEY BEING SENT IN PLAINTEXT
> IN THE EMAIL? You can't have it both ways - if you want customers to
> treat that as they do a password, you need to treat it with the same
> care, and put it behind an authentication.

This leads to a chicken-and-egg problem. To use email for domain
validation, you need to send something in the email which the domain
owner does not already know, and then use that to validate that the
person wanting the certificate is able to receive the email. It doesn't
matter whether it's a token or the username and password to a web interface.

> Again, stop passing the buck. You need to assume that not every email
> account in the world is secure! Also, it's a breach of s.6.1.2:
> 
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
>
>  No party other than subscriber shall archive the private key. I.e.
> it should be impossible to retrieve from an email in the first
> place.

Do you have evidence that private keys were retrievable? Can you provide
steps to reproduce?

> How does that matter? Chris was able to do it, and if he was able to
> then your investigation should have uncovered the vulnerability. The

It would be great if Chris were available to drop in and corroborate
this. I may reach out to him.

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


Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

2017-04-01 Thread Nick Lamb via dev-security-policy
On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com  wrote:
> I'm Tarah. I am the Principal Security Advocate and Senior Director of 
> Engineering at Symantec Website Security (the certificate authority.

Hello Tarah,

Regular readers of m.d.s.policy will not be surprised that the news media 
doesn't do a great job of explaining problems with the Web PKI.

As so often I have questions, none of which involve kittens or Ferris Bueller 
but instead today focus on QuickInvite URLs.

1. Symantec's own web site describes "Quick Invite" in several places, I 
presume this is the same QuickInvite system you're talking about. It explains 
that "The Quick Invite Duration default expiration time is 30 days, but can be 
set during the sending of the invite" with a maximum of one year. Presumably 
this is simply obsolete documentation, or else it refers to some other feature 
under a similar name? If the former, I am happy to provide the URLs where I 
found this, are you able to ensure they get updated or removed ?

2. What was the designed purpose of the QuickInvite URL / the QuickInvite 
system itself ? I appreciate that for you its purpose is very obvious as you've 
spent time up to your neck in it, but to me it's still rather opaque. Let me 
set out some possible actors in our play, and hopefully you can tell me which 
actors arrange for the URL to be sent out, which actors receive it, and what 
they can do with it. That last is quite important. If the list I provide is 
inadequate feel free to invent more people, just explain what they do.

Exam PLE is a small business with a web site, www.example.com
Andrea is the sysadmin at Exam PLE
Betty is Alice's boss, her details are listed in WHOIS for example.com
Catherine is an employee at the CA, Symantec
Jo is an SSL reseller, she offers cheap Symantec certs
Valorie is a seemingly helpful person who answers Andrea's queries on Q sites
Wendy runs a web hosting business, she runs the servers www.example.com uses
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Issues List

2017-04-01 Thread Ryan Sleevi via dev-security-policy
On Sat, Apr 1, 2017 at 12:57 AM, Peter Bowen  wrote:

> (Wearing my personal hat)
>
> Ryan,
>
> I haven't reviewed the audit reports myself, but I'll assume all you
> wrote is true.  However, I think it is important to consider it in the
> appropriate context.


> The GeoRoot program was very similar to that offered by many CAs a few
> years ago.  CyberTrust (then Verizon, now DigiCert) has the OmniRoot
> program, Entrust has a root signing program[1], and GlobalSign Trusted
> Root[2] are just a few examples.
>
> In almost every case the transition to requiring complete unqualified
> audits of the subordinates by a licensed practitioner was a rocky one.
> See DigiCert's thread
> (https://groups.google.com/d/msg/mozilla.dev.security.
> policy/tHUcqnWPt3o/U2U__7-UBQAJ)
> about the OmniRoot program or look at the audits available for some of
> the Entrust subordinates.
>
> I'm not suggesting that the GeoRoot subordinate issues should not be
> considered, but it seems the GeoRoot program was not notably
> exceptional a few years ago.
>

(Wearing a personal hat)

Peter,

There are a few issues to unpack from your reply. I think we're in
agreement that GeoRoot was by no means unique as an offering. I think, when
considering severity, it's important to instead focus on what the CAs
obligations were, what they were aware of, and what they did in response.
Further, in considering the broader scope of attempted remediation, it's
important to consider what risks were or are present as a result of this,
because it significantly impacts the ability to trust the existing set of
issued certificates.

On 2014-05-13, Mozilla requested all participating CAs disclose their
externally operated subordinate CAs. [1]
On 2014-06-03, Symantec reported it disclosed its sub-CAs in [2]
On 2015-04-06, Kathleen pointed out Symantec's disclosure was incomplete,
in [3] and [4]
On 2016-03-29, Symantec informed Google that there were 5 participants in
their GeoRoot program - Aetna, Google, Unicredit, Apple, NTT Docomo (DKHS).
On 2016-05-11 (or later), Symantec received Aetna's audit.
On 2016-05-13, Symantec's most recent audit for the Geotrust roots was made
available [5], which states there were 5 external partner subordinate CAs.
The timing of Aetna's letter suggests that this may be the audit that
"Symantec subsequently received an audit report for the other" - but that
cannot be confirmed without further detail from KPMG and Symantec.
On 2016-06-28, Symantec informs Google that NTT Docomo is part of
Symantec's audit, not separately audited.

This timeline hopefully highlights a particular serious issue: If NTT
Docomo is operated as part of Symantec's operations, then there are several
ways to interpret Symantec's audit statements:
1) KPMG failed to include NTT Docomo as part of the 5 externally operated
sub-CAs noted, and instead treated it as part of Symantec's audit. If this
is true, then there is an as-yet-unidentified intermediate certificate
issued as part of the GeoRoot program
2) KPMG was treating NTT Docomo as part of the 5 externally operated
sub-CAs noted. If this is correct, then it is in one of three sets
  a) The 3/5 sub-CAs for which KPMG identified as having audit reports
  b) The 1/5 sub-CAs for which KPMG identified as having a deficient audit
report (not appropriate to the scheme)
  c) The 1/5 sub-CAs for which KPMG identified Symantec as having later
received an audit report for.

If 2 is correct, then it's unclear of which set Aetna belongs to - that is,
if NTT Docomo is 2a, then Aetna is either 2b/2c, and it suggests that KPMG
may have been incomplete in its examination of the 2a set. If NTT Docomo is
2b, then Aetna is either 2a/2c, but calls into question Symantec's
operations if they were themselves operating this root, as it was not part
of the scope of the audit. If NTT Docomo is 2c, then Aetna is either 2a/2b,
both of which would call into question KPMG. Any of these possibilities is
quite troubling, but nowhere near as troubling as the possibility of 1,
which would imply an undisclosed sub-CA.

Based on the information provided by Unicredit, Unicredit would appear to
be 2b, because it was not performed by a licensed WebTrust practitioner to
the appropriate standards. Based on the information provided, Aetna would
seem to be 2c, but that would require confirmation from Symantec or KPMG.
This means that NTT Docomo is either 2a or 2c - either of which should be
concerning.

Independent of any questions regarding how other CAs (such as the
critically mismanaged Omniroot program) responded to disclosure, the
questions about the scope of "which sub-CAs were examined by KPMG" is very
much relevant to the discussion at hand, and gets to the heart of whether
or not there can be sufficient confidence to trust the existing set of
certificates. This also sets aside the question about whether or not
Symantec can/should be trusted going forward. It also highlights the limits
of relying on a report such 

Re: Criticism of Google Re: Google Trust Services roots

2017-04-01 Thread Gervase Markham via dev-security-policy
On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (more on that
> in a minute) but as written now is mostly OK by me. I do have a
> question as to whether the public discussion as mentioned must take
> place before the actual transfer? In other words, will Mozilla
> require that whatever entity is trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

No. As currently worded, it has to take place before issuance is permitted.

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