Re: Misissuance Report: Incorrect CA-Issuers URI in some certificates

[Wayne Thayer via dev-security-policy]

Neil,

Thank you for posting this detailed incident report. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1568356 to track this issue
and I have no questions at this time.

- Wayne

On Tue, Jul 23, 2019 at 10:20 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> To m.d.s.p,
>
> The following contains an incident report, compiled as a result of the
> release of two example certificates with an incorrect CA-Issuers URI
> included.
>
> Any questions or observations on this incident are gratefully received,
> and I will endeavour to answer them as quickly as I can.
>
> Regards,
>
> Neil Dunbar,
> CA Administrator,
> TrustCor Systems, S. de R.L.
>
> —
>
> 1. How your CA first became aware of the problem (e.g. via a problem
>   report submitted to your Problem Reporting Mechanism, a discussion in
>   mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit),
>   and the time and date.
>
> 2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log
> monitoring process, Internal QA identified two (2) certificates which
> contained an incorrect URI value in the CA Issuers part of the
> authorityInformationAccess extension.
>
> 2. A timeline of the actions your CA took in response. A timeline is a
>   date-and-time-stamped sequence of all relevant events. This may include
>   events before the incident was reported, such as when a particular
>   requirement became applicable, or a document changed, or a bug was
>   introduced, or an audit was done.
>
> 2019-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue.
> 2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA
> hierarchy suspended, pending investigation of issue.
> 2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected
> certificates completed.
> 2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect
> value stipulated for an Internal Example Certificate profile under the
> ECA-1 root (no other hierarchies shared this issue).
> 2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile
> values for ECA-1 internal example certificates corrected on testing and
> production platforms.
> 2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected
> certificates.
> 2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected
> certificates.
>
> 3. Whether your CA has stopped, or has not yet stopped, issuing
>   certificates with the problem. A statement that you have will be
>   considered a pledge to the community; a statement that you have not
>   requires an explanation.
>
> TrustCor stopped issuing certificates identified with this problem and
> rapidly resolved the issue.
>
> 4. A summary of the problematic certificates. For each problem: number
>   of certs, and the date the first and last certs with that problem were
>   issued.
>
> Two (2) certificates were identified with this issue. The first was
> issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued
> at 2019-07-22 11:22:10 UTC.
>
> 5. The complete certificate data for the problematic certificates. The
>   recommended way to provide this is to ensure each certificate is logged
>   to CT and then list the fingerprints or crt.sh IDs, either in the report
>   or as an attached spreadsheet, with one list per distinct problem.
>
> Two (2) certificates were identified: one was revoked immediately post
> production (as it is there to demonstrate a revoked certificate), and
> the second certificate, which was otherwise valid, was then revoked
> upon identifying the issue.
>
> The crt.sh URIs for the certificates (now revoked) are:
>
> https://crt.sh/?id=1695491402 
> https://crt.sh/?id=1695520034 
>
> 6. Explanation about how and why the mistakes were made or bugs
>   introduced, and how they avoided detection until now.
>
> The problem was that the authorityInformationAccess CA-Issuers URI, (BR
> Section 7.1.2.3, subsection c) was set to the Basic Secure Site CA
> certificate, not the ECA-1 External CA certificate. While the BRs do not
> actually mandate the inclusion of the CA-Issuers URI, providing an
> incorrect value is certainly a mis-issuance.
>
> When TrustCor CA created the new certificate profiles for the ECA-1 example
> hierarchy, the profile QA tool previously only verified that the CA issuers
> URI point to a valid TrustCor CA certificate.
>
> Certificate profiles being copied from the test CA software are compared
> with the intended profiles for production as part of the QA
> process. Because the CA-Issuers URI is always different in test
> vs. production, and the test URI domain is different from
> production, the error was missed before the certificates were issued.
>
> 7. List of steps your CA is taking to resolve the situation and ensure
>   such issuance will not be repeated in the future, accompanied with a
>   timeline of when your CA expects to accomplish these th

Re: Nation State MITM CA's ?

[nyxtom--- via dev-security-policy]

On Wednesday, January 6, 2016 at 5:08:10 PM UTC-6, Paul Wouters wrote:
> As was in the news before, Kazakhstan has issued a national MITM
> Certificate Agency.
> 
> Is there a policy on what to do with these? While they are not trusted,
> would it be useful to explicitely blacklist these, as to make it
> impossible to trust even if the user "wanted to" ?
> 
> The CA's are available here:
> http://root.gov.kz/root_cer/rsa.php
> http://root.gov.kz/root_cer/gost.php
> 
> One site that uses these CA's is:
> https://pki.gov.kz/index.php/en/forum/
> 
> Paul

Coordinated blacklisting. We shouldn't incentivize this kind of behavior.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DarkMatter CAs in Google Chrome and Android

[Devon O'Brien via dev-security-policy]

(Writing on behalf of Google Chrome and Android)

On behalf of Google Chrome and Android, we would like to thank the participants 
that have contributed to the discussion on the broader M.D.S.P thread on this 
topic. We will be taking similar steps to those proposed by Wayne and approved 
by Kathleen, in that we will be removing trust in the DarkMatter-operated 
intermediates across Google Chrome and Android and we will not be including 
DarkMatter’s proposed new root certificates. We anticipate these changes will 
be delivered via our existing in-band delivery mechanisms to clients and 
require no user action.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Misissuance Report: Incorrect CA-Issuers URI in some certificates

[Neil Dunbar via dev-security-policy]

To m.d.s.p,

The following contains an incident report, compiled as a result of the release 
of two example certificates with an incorrect CA-Issuers URI included.

Any questions or observations on this incident are gratefully received, and I 
will endeavour to answer them as quickly as I can.

Regards,

Neil Dunbar,
CA Administrator,
TrustCor Systems, S. de R.L.

—

1. How your CA first became aware of the problem (e.g. via a problem
  report submitted to your Problem Reporting Mechanism, a discussion in
  mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit),
  and the time and date.

2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log
monitoring process, Internal QA identified two (2) certificates which
contained an incorrect URI value in the CA Issuers part of the
authorityInformationAccess extension.

2. A timeline of the actions your CA took in response. A timeline is a
  date-and-time-stamped sequence of all relevant events. This may include
  events before the incident was reported, such as when a particular
  requirement became applicable, or a document changed, or a bug was
  introduced, or an audit was done.

2019-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue.
2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA hierarchy 
suspended, pending investigation of issue.
2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected certificates 
completed.
2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect value 
stipulated for an Internal Example Certificate profile under the ECA-1 root (no 
other hierarchies shared this issue).
2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile 
values for ECA-1 internal example certificates corrected on testing and 
production platforms.
2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected certificates.
2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected 
certificates.

3. Whether your CA has stopped, or has not yet stopped, issuing
  certificates with the problem. A statement that you have will be
  considered a pledge to the community; a statement that you have not
  requires an explanation.

TrustCor stopped issuing certificates identified with this problem and
rapidly resolved the issue.

4. A summary of the problematic certificates. For each problem: number
  of certs, and the date the first and last certs with that problem were
  issued.

Two (2) certificates were identified with this issue. The first was
issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued
at 2019-07-22 11:22:10 UTC.

5. The complete certificate data for the problematic certificates. The
  recommended way to provide this is to ensure each certificate is logged
  to CT and then list the fingerprints or crt.sh IDs, either in the report
  or as an attached spreadsheet, with one list per distinct problem.

Two (2) certificates were identified: one was revoked immediately post
production (as it is there to demonstrate a revoked certificate), and
the second certificate, which was otherwise valid, was then revoked
upon identifying the issue.

The crt.sh URIs for the certificates (now revoked) are:

https://crt.sh/?id=1695491402 
https://crt.sh/?id=1695520034 

6. Explanation about how and why the mistakes were made or bugs
  introduced, and how they avoided detection until now.

The problem was that the authorityInformationAccess CA-Issuers URI, (BR
Section 7.1.2.3, subsection c) was set to the Basic Secure Site CA
certificate, not the ECA-1 External CA certificate. While the BRs do not
actually mandate the inclusion of the CA-Issuers URI, providing an
incorrect value is certainly a mis-issuance.

When TrustCor CA created the new certificate profiles for the ECA-1 example
hierarchy, the profile QA tool previously only verified that the CA issuers
URI point to a valid TrustCor CA certificate.

Certificate profiles being copied from the test CA software are compared
with the intended profiles for production as part of the QA
process. Because the CA-Issuers URI is always different in test
vs. production, and the test URI domain is different from
production, the error was missed before the certificates were issued.

7. List of steps your CA is taking to resolve the situation and ensure
  such issuance will not be repeated in the future, accompanied with a
  timeline of when your CA expects to accomplish these things.

The profile QA tool has already been adjusted to ensure that the CA
Issuers URI points to a certificate within the allowed set of issuing
CAs for that profile. This should reduce the chances of this error
occurring again. Note that a profile could contain multiple potential
CAs (TrustCor CA's configuration is not so configured, but the EJBCA
software does permit such an arrangement).

We have updated our process to include an extra validation step, by
Internal QA, to confirm 

Re: Nation State MITM CA's ?

[whateverusernameforme--- via dev-security-policy]

On Tuesday, July 23, 2019 at 7:34:11 AM UTC+4, Matthew Hardeman wrote:

> It is an interesting question.  It essentially becomes a gamble on whether
> they'll back down or just fork their own KazakhFox.  But if they do push
> this all the way with a national browser, then their people are even
> further worse off.

Pardon my broken English. I will be referring to "totalitarian governments" in 
general, not naming a specific country (countries) to be one.

I plea that doing nothing or implementing an easily dismissable warning will be 
an equivalent of a green light for mass-scale government-sanctioned MiTMs and 
further political persecutions based on the collected data. While a ban of the 
CA will be a warning for any totalitarian state that such measures have a 
hidden cost and complications that they are not ready to take - even if they 
will make a "TruthFox" and it will turn out to be less secure, the only added 
risk on top of it will be a slight increase of a chance of a trojan infection.

We know that MiTM is not just blocking access - MiTM also means collection of 
information. Between staying free/alive and a not working hard drive (or loss 
of personal data/money that is not comparable to a lengthy prison sentence with 
a criminal record or a *loss of life*) everyone will chose the first, not the 
second - ergo, the end user will be harmed more if no action/insufficient 
action is taken.

With all due respect, all theoretical measures that a totalitarian government 
might take to negate CA ban in all major browsers will require them to spent 
*even more resources* and complicate the spying process even further. Speaking 
generally, corrupt governments like to spent resources "on security", but will 
become rather stingy when it will turn out that a significant sum of money will 
be spent out of their pockets. In turn, it will lead to pushing all of the 
support on third parties while increasing the levels of corruption, 
miscommunication, non-compliance and etc., breaking the process down and 
postponing it/cancelling it entirely. Since all of that can not be done 
instantly, all of this will happen on the background of increasing civil 
unrest, where the totalitarian government's actions will be to blame to 
"messing with the internet" and the suffering from it commercial sector will be 
very active in lobbying for the repeal of the law.

I believe that the Russian anti-blogger law of 2014 has practically fallen 
apart in 2017 exactly due to a non-compliance of foreign parties and a feeble 
implementation in general - such a thing wouldn't happen if major social 
platforms didn't treat it as a slight and easily ignorable nuisance.

I ask everyone opposing taking drastic measures to reconsider - it's not the 
time to worry about the market share of the browser, comparing it to legitimate 
activities of a commercial sector or thinking of all theoretical ways the 
government might defeat the taken measures. Today is Kazakhstan, tomorrow - 
Russia (I believe we almost did the similar thing too, but it was thrown away 
due to encryption licensing complications - don't quote me on that, I haven't 
checked updates on this topic), the day after it might be your country 
(remember all proposals (or even the accepted laws) against encryption in major 
Western countries). Even little "sticks in the wheel" help and warn everybody 
else against doing the same.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy