Hongkong Post recently issued SHA1 cert that could be used in TLS

[Kathleen Wilson]

All,

It has come to our attention that Hongkong Post has recently issued a
SHA1 cert that can be used in TLS/SSL.

https://bugzilla.mozilla.org/show_bug.cgi?id=1267332#c3

The certificate was signed by the "Hongkong Post e-Cert CA 1 - 10"
intermediate certificate.

From the CA: "This certificate is issued to a person, instead of a
server, as you've seen that it does not contain any DNS name. "Hongkong
Post e-Cert CA 1 - 10" will continue issue client certificates to
individuals, although it has been stopped issuing SSL server
certificates since 1 January 2016.

Our understanding: "The real problem here is that the issuing
certificate is using sha-1 with predictable serial numbers. ... If a
chosen-prefix attack on sha-1 were discovered... an attacker could use
this CA to obtain a certificate for a domain that isn't theirs."

We are looking into this, and as always will greatly appreciate data
that folks have that will aid in assessing this situation.

Thanks,
Kathleen

[Ryan Sleevi]

On Tuesday, August 16, 2016 at 11:53:24 AM UTC-7, Kathleen Wilson wrote:
> Our understanding: "The real problem here is that the issuing
> certificate is using sha-1 with predictable serial numbers. ... If a
> chosen-prefix attack on sha-1 were discovered... an attacker could use
> this CA to obtain a certificate for a domain that isn't theirs."

I think this is a very important part of the consideration, as it suggests a lack of awareness or concern about the security implications about their practices. In particular, https://bugzilla.mozilla.org/show_bug.cgi?id=1267332#c5

If we ignore the CA/Browser Forum's Ballot 164 (Serial Number Entropy), which has an effective day of 30-Sep-2016, and look at the previous versions, we see the following:
"CAs SHOULD generate non‐sequential Certificate serial numbers that exhibit at least 20 bits of entropy."

Similarly, Mozilla's policy ( https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ ) states: "all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number)."

As pointed out on the bug, that's seriously questionable as to whether this CA has implemented this protection. Had they done so, there's at least some work factor an attacker would have to do to predict such serials.

To the claim that this wasn't intended to be used on a server, I can confirm that https://gps.autotoll-gps.com.hk is serving this certificate.

Practically speaking, what steps could be taken?
1) Do nothing. Despite communications such as https://mozillacaprogram.secure.force.com/Communications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 , simply accept that some CAs are continuing grossly insecure practices. Because the BRs have not explicitly stated the scope (anything directly or transitively capable of TLS issuance, as measured by the EKUs, for example), accept that it's OK for CAs to continue practices that put Firefox/Mozilla users at risk, and address this either in the CA/Browser Forum or the CA Policy 2.3

2) Disable SHA-1 certificates if they directly or transitively chain to this CA, in advance of the January deadline. This assumes the worst (a collision attack) and moves to protect users, but makes no statement about whether what the CA did is correct or not.

3) Disable trust in these specific certificates. As far as I know, OneCRL only supports revocation by SPKI or by Issuer+SerialNumber - it doesn't support revocation by Issuer-and-Hash (is this correct?). I'm not sure if the NSS blacklist version supports blacklisting by hash (but I believe it does?)

4) Disable trust in the older intermediates. It's clear that this CA has a had a large and longstanding issue with compliance to the BRs. While their new CA (CA 1 - 15) appears to be issuing certs that have no cablint issues, older CAs such as this are rife with issues. It may be that the appropriate response to protect users - especially if this CA continues to issue certificates from it - is to wholesale blacklist it via OneCRL.

5) Disable trust in the CA. The justification for this would be arguing that the CA failed its obligations with respect to Item #9 in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ , in that the combination of SHA-1 issuance from a publicly trusted, non-constrained intermediate, and the use of seemingly predictable certificates with insufficient entropy, represents a real risk of collision attacks, and the CA has materially failed to follow current best practices, such as adding sufficient entropy to the serial number (as reflected in the CA/Browser Forum's Ballot 164).

It's worth noting that both Symantec and WoSign have recently misissued SHA-1 certificates as well, where in all three cases (two separate incidents for Symantec recently, one for WoSign), these certificates WERE intended for TLS servers. However, each case also included entropy within the serial - although Symantec also reused serials.


I'm curious if there's other options, and I'm curious what the arguments against #4 or #5 would be. Given that CAs provide such a critical function in the ecosystem, and these mistakes have far reaching implications, who would be interested in arguing in favor of keeping this CA/these intermediates trusted?

[Nick Lamb]

On Tuesday, 16 August 2016 23:23:14 UTC+1, Ryan Sleevi wrote:
> I'm curious if there's other options, and I'm curious what the arguments against #4 or #5 would be. Given that CAs provide such a critical function in the ecosystem, and these mistakes have far reaching implications, who would be interested in arguing in favor of keeping this CA/these intermediates trusted?

How about,

6) Engage with other trust store maintainers which trust this CA to determine a common choice of action. I believe Apple and Microsoft both trust this CA. They too should have concerns about its behaviour and have thoughts about how users should be protected. Or maybe they don't.

[Ryan Sleevi]

On Tuesday, August 16, 2016 at 6:14:12 PM UTC-7, Nick Lamb wrote:
> 6) Engage with other trust store maintainers which trust this CA to determine a common choice of action. I believe Apple and Microsoft both trust this CA. They too should have concerns about its behaviour and have thoughts about how users should be protected. Or maybe they don't.

That options pretty much a non-starter for reasons best not speculated about, but I'm curious: Why or how would that improve the security of Mozilla users? And if it doesn't meaningfully improve their security, how would it at least further the Mozilla principle of individuals' security and privacy?

There's three possible outcomes from such (well, more, but again, not going to speculate on things I'm not legally qualified to speculate about):
- Other stores push for a more lenient solution than Mozilla thinks appropriate for their users
- Other stores push for the same solution as Mozilla thinks appropriate for their users
- Other stores push for a more strict response than Mozilla thinks appropriate for their users

The first option is a non-starter if it leaves Mozilla users more at risk. The second option doesn't provide net-value. The third option seems sub-optimal, as it suggests Mozilla's decisions are arbitrary based on coordinated action with other stores, rather than upholding Mozilla's principles and protecting its users.

What about the other way - Convincing other stores to a particular path? They're in the same position, and likely have the same concerns - too weak, the same, or too strong.

You could argue that you believe other trust store maintainers have additional information that they're not willing to share publicly, and while that may be true, it doesn't further Mozilla's goal of consistency and transparency to allow such information to alter the decision making unless it can be shared, and if it could be shared, it could be shared here.

You could argue that you believe coordinated action eliminates the first mover penalty, but we know from ample work in the TLS space that you can't escape the first mover penalty to some degree, because products are on different release cycles.

You could argue it'd be a PR issue if Mozilla took one stance and another browser took another, but isn't that still core to the point - Mozilla should do what's right for Mozilla users, and as according to Mozilla's principles?


So aren't we now back to the same set of question/options posed - which is what does the Mozilla community, and in particular, Mozilla itself, feel is appropriate to protect users of Mozilla products? And that's basically 1-5, AFAIK.

[ma...@certizen.com]

We have already stopped issuing SHA-1 SSL certificates under "Hongkong Post e-Cert CA 1 - 10" since 1 January 2016, and have been issuing SHA-256 SSL certificates under "Hongkong Post e-Cert CA 1- 14" and "Hongkong Post e-Cert CA 1 - 15" respectively (https://bugzilla.mozilla.org/show_bug.cgi?id=1267332#c2).

This certificate is a client certificate issued to a person for private use such as digital signature and encryption of electronic messages, but not for SSL server communication. We are contacting the subscriber to confirm why and how he/she uses that certificate in a server of https://gps.autotoll-gps.com.hk. Once we confirmed that he/she mis-used the certificate, we will revoke this certificate.

[Matt Palmer]

On Tue, Aug 16, 2016 at 10:22:36PM -0700, ma...@certizen.com wrote:
> and have been issuing SHA-256 SSL certificates under "Hongkong Post e-Cert

> CA 1- 14" and "Hongkong Post e-Cert CA 1 - 15" respectively

"respectively" in what sense?

> This certificate is a client certificate issued to a person for private
> use such as digital signature and encryption of electronic messages, but
> not for SSL server communication.

What mitigations are in place to prevent someone from using a chosen prefix
attack to obtain a valid signature issued under this CA which is also valid
for a certificate which *could* be used for SSL server communication?

- Matt

[Kurt Roeckx]

On 2016-08-17 00:23, Ryan Sleevi wrote:
> Practically speaking, what steps could be taken?

6) Ask them to immediately stop issuing SHA-1 based certificates that
chain back to any of the root certificates in the Mozilla root store,
and revoke the one they shouldn't have issued. If they fail to comply
distrust all their certificates.


Kurt

[Matt Palmer]

On Wed, Aug 17, 2016 at 10:22:13AM +0200, Kurt Roeckx wrote:
> On 2016-08-17 00:23, Ryan Sleevi wrote:

> >Practically speaking, what steps could be taken?
>

> 6) Ask them to immediately stop issuing SHA-1 based certificates that chain
> back to any of the root certificates in the Mozilla root store, and revoke
> the one they shouldn't have issued. If they fail to comply distrust all
> their certificates.

Didn't they already get asked to do that?

- Matt

[ma...@certizen.com]

On Wednesday, August 17, 2016 at 3:02:26 PM UTC+8, Matt Palmer wrote:
> On Tue, Aug 16, 2016 at 10:22:36PM -0700, ma...@certizen.com wrote:
> > and have been issuing SHA-256 SSL certificates under "Hongkong Post e-Cert
> > CA 1- 14" and "Hongkong Post e-Cert CA 1 - 15" respectively
>
> "respectively" in what sense?

We took two stages of transitioning to a new BR-compliant subCA "Hongkong Post e-Cert CA 1 - 15" for issuing BR-compliant SSL certificates (https://bugzilla.mozilla.org/show_bug.cgi?id=1267332#c2):

Stage 1: Start issuing SHA-256 SSL certificates from "Hongkong Post e-Cert CA 1 - 14" since 1 January 2015. At that moment, we had announced to stop issuing SHA-1 SSL certificates which are issued under "Hongkong Post e-Cert CA 1 - 10" from 1 January 2016 (http://www.hongkongpost.gov.hk/news/press/73.html).

Stage 2: Start issuing SHA-256 SSL certificate supporting OCSP from "Hongkong Post e-Cert CA 1 - 15" from 1 September 2015. This subCA is used to issue BR-compliant SSL certificates. And we have also announced to stop issuing non-BR compliant SSL certificates under "Hongkong Post e-Cert CA 1 - 14" from 1 September 2016 (http://www.hongkongpost.gov.hk/news/press/76.html).

>
> > This certificate is a client certificate issued to a person for private
> > use such as digital signature and encryption of electronic messages, but
> > not for SSL server communication.
>
> What mitigations are in place to prevent someone from using a chosen prefix
> attack to obtain a valid signature issued under this CA which is also valid
> for a certificate which *could* be used for SSL server communication?
>

Through our effort of sunsetting the "Hongkong Post e-Cert CA 1 - 10" for SSL certificate, majority of SHA-1 SSL certificates will be expired by 31 Dec 2016, remaining only a few SHA-1 SSL certificates that are valid beyond 1 Jan 2017. And in our response to March 2016 CA Communication of Mozilla, we have also committed to have those certificates revoked by 31 Dec 2016.

> - Matt

[Kurt Roeckx]

I don't see that being asked, it was just pointed out that this is a
violation of the BR requirements, and that the CA certificate might get
added to OneCRL preventing it's use to issue certificates for server
authentication.

The BR requirements only apply to certificates that can be used for
server authentication, and they say they stopped using that intermediate
certificate for server authentication at the start of the year. But the
SHA-1 requirement really is about all certificates, not just those that
need to comply with the BR requirements.

I don't think adding that CA certificate to OneCRL is enough, that would
only protect Mozilla users. They should revoke all the relevant
certificates.


Kurt

[Nick Lamb]

On Wednesday, 17 August 2016 04:24:27 UTC+1, Ryan Sleevi wrote:
> That options pretty much a non-starter for reasons best not speculated about, but I'm curious: Why or how would that improve the security of Mozilla users? And if it doesn't meaningfully improve their security, how would it at least further the Mozilla principle of individuals' security and privacy?

I offered it only as one more option, without intending to suggest that I prefer it at all or any cost. The core purpose of this option is to improve security for the _entire_ Web PKI.

Mozilla's users are threatened by attacks on the Web PKI even if those attacks don't work on Firefox itself. Most of its users rely on an OS made by the other trust store operators, and in which almost all TLS-capable components use that store, not NSS for trust decisions. So it is an error to think these users are only "at risk" if Mozilla doesn't act to protect them, the risk persists unless all the major trust stores act.

[Ryan Sleevi]

On Wednesday, August 17, 2016 at 2:53:38 AM UTC-7, ma...@certizen.com wrote:
> Through our effort of sunsetting the "Hongkong Post e-Cert CA 1 - 10" for SSL certificate, majority of SHA-1 SSL certificates will be expired by 31 Dec 2016, remaining only a few SHA-1 SSL certificates that are valid beyond 1 Jan 2017. And in our response to March 2016 CA Communication of Mozilla, we have also committed to have those certificates revoked by 31 Dec 2016.

Unfortunately, I believe you've misunderstood the concern being raised here.

"Hongkong Post e-Cert CA 1 - 10" is technically capable of issuing SSL certificates (that is, it's not constrained in any way to prevent it). We further know this precisely because it was, in the past, used to issue such certificates, and because in the present, it's still trusted for such certificates - because you have them expiring.

However, because you've continued to issue new (non-SSL) SHA-1 certificates from this sub-CA, you create the risk that an attacker can exercise a SHA-1 collision on one type of a certificate (e.g. a client certificate) and transform it into another kind (such as an SSL intermediate CA). That's because regardless of what you signed with SHA-1 originally, an attacker can mutate it into any other type of cert. This is exactly the cause of the Flame MD5 Collision - a sub-CA only used to issue one type of certificate (Terminal Services certificates) wasn't appropriately restricted from other types (via the EKU on the intermediate), and an attacker was able to turn the Terminal Services certificate into a Code Signing certificate by using an MD5 collision.

The further concern is because this CA isn't taking steps to prevent such attacks, such as by including sufficient entropy (20 bits under the previous SHOULD, 64 bits under the new MUST), which would make it much harder for an attacker to exploit this.

So the question is now, since Hongkong Post / Certizen didn't properly protect this intermediate, what should Mozilla do, either for the intermediate or the root?

For example, for the safety of its users, it could decide to distrust the "1 - 10" sub-CA. This wouldn't break any of your client cert use cases (or shouldn't), but would break all of those existing certificates. Mozilla could decide this was acceptable, or it could decide to whitelist those certificates as trusted. If the whitelist was too large to be included built-in, it might be hosted in some sharded, privacy-preserving way, much like Google SafeBrowsing does, or like CRLs in reverse. This is something the Chrome team is considering, for example, and depends on how many certificates issued by "1 - 10"

Certainly, whatever the result, you should understand that by continuing the practices using "1 - 10", no matter what your intent is, you're actively putting people who trust your CA at risk, and that risk may be so great that people begin to distrust you. You should immediately take mitigations to prevent this - such as stopping the use of SHA-1 (ideally, immediately), or revoking that "1 - 10" sub-CA and reissuing your certificates, in a SHA-256 way, to consumers who might be affected by that.

[Ryan Sleevi]

On Wednesday, August 17, 2016 at 2:55:50 AM UTC-7, Kurt Roeckx wrote:
> I don't see that being asked, it was just pointed out that this is a
> violation of the BR requirements, and that the CA certificate might get
> added to OneCRL preventing it's use to issue certificates for server
> authentication.

Except, as I tried to highlight, it's not clear that it's a BR violation (the scope problem), nor is the serial number a clear BR violation (SHOULD under previous versions, MUST not in effect yet)

> The BR requirements only apply to certificates that can be used for
> server authentication, and they say they stopped using that intermediate
> certificate for server authentication at the start of the year. But the
> SHA-1 requirement really is about all certificates, not just those that
> need to comply with the BR requirements.

Right, but this is the scope problem.

> I don't think adding that CA certificate to OneCRL is enough, that would
> only protect Mozilla users. They should revoke all the relevant
> certificates.

Define "relevant"? If a SHA-1 collision has been mounted, Hongkong Post revoking those SHA-1 certs does nothing, because the attacker can manipulate the serial number of the colliding certs. The only level at which any meaningful action can be taken is at the "1 - 10" CA layer - revoking that intermediate, such as by OneCRL and by Hongkong Post's CRL. The rest would just be for show, not security.

[Ryan Sleevi]

On Wednesday, August 17, 2016 at 3:56:55 AM UTC-7, Nick Lamb wrote:
> Mozilla's users are threatened by attacks on the Web PKI even if those attacks don't work on Firefox itself. Most of its users rely on an OS made by the other trust store operators, and in which almost all TLS-capable components use that store, not NSS for trust decisions. So it is an error to think these users are only "at risk" if Mozilla doesn't act to protect them, the risk persists unless all the major trust stores act.

I would disagree with this claim, and I tried to show the logical flaws with it in my previous post. In any event, if we do want to discuss this point more - whether or not it's appropriate in a theoretical sense to coordinate with other stores (setting aside any legal, political, or administrative concerns) - we should likely migrate to a new thread.

[Kurt Roeckx]

On Wed, Aug 17, 2016 at 09:55:24AM -0700, Ryan Sleevi wrote:
> > I don't think adding that CA certificate to OneCRL is enough, that would
> > only protect Mozilla users. They should revoke all the relevant
> > certificates.
>

> Define "relevant"? If a SHA-1 collision has been mounted, Hongkong Post revoking those SHA-1 certs does nothing, because the attacker can manipulate the serial number of the colliding certs. The only level at which any meaningful action can be taken is at the "1 - 10" CA layer - revoking that intermediate, such as by OneCRL and by Hongkong Post's CRL. The rest would just be for show, not security.

It's my understanding that the attack depends on the serial being
predictable, since it's at the start of the certificate. But I
guess they might not need the whole serial to match, I have no
idea at which point it starts to get more practicle to attack.


Kurt

[Andrew Ayer]

On Wed, 17 Aug 2016 19:08:08 +0200
Kurt Roeckx <ku...@roeckx.be> wrote:

> On Wed, Aug 17, 2016 at 09:55:24AM -0700, Ryan Sleevi wrote:

> > > I don't think adding that CA certificate to OneCRL is enough,
> > > that would only protect Mozilla users. They should revoke all
> > > the relevant certificates.
> >

> > Define "relevant"? If a SHA-1 collision has been mounted, Hongkong
> > Post revoking those SHA-1 certs does nothing, because the attacker
> > can manipulate the serial number of the colliding certs. The only
> > level at which any meaningful action can be taken is at the "1 -
> > 10" CA layer - revoking that intermediate, such as by OneCRL and by
> > Hongkong Post's CRL. The rest would just be for show, not security.
>
> It's my understanding that the attack depends on the serial being
> predictable, since it's at the start of the certificate. But I
> guess they might not need the whole serial to match, I have no
> idea at which point it starts to get more practicle to attack.

The attacker has to be able to control (or predict) the prefix of the
data signed by the CA (which in the case of a TBSCertificate, includes
the serial number), as well as the prefix of the forged certificate.
However, they do not have to be the same, and their similarity has no
bearing whatsoever on the practicality of the attack. In fact, the
data signed by the CA need not even be a TBSCertificate - if a CA signs
an OCSP response with SHA-1, an attacker could forge a certificate[1].
This is why action must be taken at the level of the key doing the
SHA-1 signing - that is, the intermediate CA level.

Regards,
Andrew

[1] https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg02999.html

[cspa...@gmail.com]

On Wednesday, August 17, 2016 at 10:31:29 AM UTC-7, Andrew Ayer wrote:
> The attacker has to be able to control (or predict) the prefix of the
> data signed by the CA (which in the case of a TBSCertificate, includes
> the serial number), as well as the prefix of the forged certificate.
> However, they do not have to be the same, and their similarity has no
> bearing whatsoever on the practicality of the attack. In fact, the
> data signed by the CA need not even be a TBSCertificate - if a CA signs
> an OCSP response with SHA-1, an attacker could forge a certificate[1].
> This is why action must be taken at the level of the key doing the
> SHA-1 signing - that is, the intermediate CA level.
>
> Regards,
> Andrew
>
> [1] https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg02999.html

Based on this statement I would assume we need to worry about root CAs issuing SHA-1 CRLs?

Regards,
Curt

[Kurt Roeckx]

On Wed, Aug 17, 2016 at 11:43:45AM -0700, cspa...@gmail.com wrote:
> On Wednesday, August 17, 2016 at 10:31:29 AM UTC-7, Andrew Ayer wrote:

> > The attacker has to be able to control (or predict) the prefix of the
> > data signed by the CA (which in the case of a TBSCertificate, includes
> > the serial number), as well as the prefix of the forged certificate.
> > However, they do not have to be the same, and their similarity has no
> > bearing whatsoever on the practicality of the attack. In fact, the
> > data signed by the CA need not even be a TBSCertificate - if a CA signs
> > an OCSP response with SHA-1, an attacker could forge a certificate[1].
> > This is why action must be taken at the level of the key doing the
> > SHA-1 signing - that is, the intermediate CA level.
> >
> > Regards,
> > Andrew
> >
> > [1] https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg02999.html
>

> Based on this statement I would assume we need to worry about root CAs issuing SHA-1 CRLs?

I think OCSP with a nonce and SHA-1 is probably more something to
worry about.


Kurt

[Andrew Ayer]

On Wed, 17 Aug 2016 11:43:45 -0700 (PDT)

cspa...@gmail.com wrote:

> On Wednesday, August 17, 2016 at 10:31:29 AM UTC-7, Andrew Ayer wrote:

> > The attacker has to be able to control (or predict) the prefix of
> > the data signed by the CA (which in the case of a TBSCertificate,
> > includes the serial number), as well as the prefix of the forged
> > certificate. However, they do not have to be the same, and their
> > similarity has no bearing whatsoever on the practicality of the
> > attack. In fact, the data signed by the CA need not even be a
> > TBSCertificate - if a CA signs an OCSP response with SHA-1, an
> > attacker could forge a certificate[1]. This is why action must be
> > taken at the level of the key doing the SHA-1 signing - that is,
> > the intermediate CA level.
> >
> > Regards,
> > Andrew
> >
> > [1]
> > https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg02999.html
>

> Based on this statement I would assume we need to worry about root
> CAs issuing SHA-1 CRLs?

Fortunately not, as CRLs do not reflect attacker-controlled data. In
addition to having to control or predict the prefix of the signed data,
the attacker must be able to control the part of the signed data
following the prefix. With a TBSCertificate, that's accomplished
through the public key. With an OCSP response, that's accomplished
through either the nonce or the serial number, which are reflected from
the OCSP request (unless the request is pre-generated).

This page goes into greater detail (the picture in section 5.3 is
especially illustrative):

https://www.win.tue.nl/hashclash/rogue-ca/

Regards,
Andrew

[Richard Wang]

I checked the certificate that it is a client certificate issued the personal -- PANG Ming Sum:
CN = PANG Ming Sum
E = todd...@autotoll.com.hk
OU = AUTOTOLL LIMITED
OU = 215063380000215100635386
OU = 0001890584
O = Hongkong Post e-Cert (Organisational)
C = HK

The problem is this certificate don't have EKU to limit to Client certificate, so he/she can use it in website as SSL certificate!
And the another problem is this subscriber is not an employee of " Hongkong Post e-Cert (Organisational)", why its certificate subject O filed use this Hong Kong Post name.


Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of ma...@certizen.com
Sent: Wednesday, August 17, 2016 1:23 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Hongkong Post recently issued SHA1 cert that could be used in TLS

On Wednesday, August 17, 2016 at 2:53:24 AM UTC+8, Kathleen Wilson wrote:

We have already stopped issuing SHA-1 SSL certificates under "Hongkong Post e-Cert CA 1 - 10" since 1 January 2016, and have been issuing SHA-256 SSL certificates under "Hongkong Post e-Cert CA 1- 14" and "Hongkong Post e-Cert CA 1 - 15" respectively (https://bugzilla.mozilla.org/show_bug.cgi?id=1267332#c2).

This certificate is a client certificate issued to a person for private use such as digital signature and encryption of electronic messages, but not for SSL server communication. We are contacting the subscriber to confirm why and how he/she uses that certificate in a server of https://gps.autotoll-gps.com.hk. Once we confirmed that he/she mis-used the certificate, we will revoke this certificate.

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

[ma...@certizen.com]

>
> The further concern is because this CA isn't taking steps to prevent such attacks, such as by including sufficient entropy (20 bits under the previous SHOULD, 64 bits under the new MUST), which would make it much harder for an attacker to exploit this.

We are actually taking steps to transition the issuance of client cert. to a new SubCA, which is separated from the SubCA issuing SSL cert. We are assuming that there is no need to separate into two roots, right? The new SubCA will be generated shortly and signed with SHA256 algorithm and its serial number contains at least 64 bits of entropy.

>
> So the question is now, since Hongkong Post / Certizen didn't properly protect this intermediate, what should Mozilla do, either for the intermediate or the root?
>
> For example, for the safety of its users, it could decide to distrust the "1 - 10" sub-CA. This wouldn't break any of your client cert use cases (or shouldn't), but would break all of those existing certificates. Mozilla could decide this was acceptable, or it could decide to whitelist those certificates as trusted. If the whitelist was too large to be included built-in, it might be hosted in some sharded, privacy-preserving way, much like Google SafeBrowsing does, or like CRLs in reverse. This is something the Chrome team is considering, for example, and depends on how many certificates issued by "1 - 10"
>

If a whitelist would be considered, we're glad to provide information of currently valid SSL cert. There are currently around 135 valid SSL cert., which will continue to decrease month by month due to cert. expiry.

> Certainly, whatever the result, you should understand that by continuing the practices using "1 - 10", no matter what your intent is, you're actively putting people who trust your CA at risk, and that risk may be so great that people begin to distrust you. You should immediately take mitigations to prevent this - such as stopping the use of SHA-1 (ideally, immediately), or revoking that "1 - 10" sub-CA and reissuing your certificates, in a SHA-256 way, to consumers who might be affected by that.

I'd like to add that unlike SSL cert., we do not accept subscriber-supplied CSR for client cert. We take a central key generation approach for client cert. and then many manual steps to securely deliver client cert. to the subscriber. Therefore client cert. does not possibly contain attacker-controlled data. I'm not saying that it risk-free now, but such risk factor should be different from SSL cert.

[Kathleen Wilson]

Thanks to all of you who have provided thoughtful and constructive input into this discussion.

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1299579 to request that the "Hongkong Post e-Cert CA 1 - 10" intermediate cert be added to OneCRL. See the bug for further details.

Kathleen

[Nick Lamb]

On Wednesday, 31 August 2016 19:32:43 UTC+1, Kathleen Wilson wrote:
> Thanks to all of you who have provided thoughtful and constructive input into this discussion.
>
> I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1299579 to request that the "Hongkong Post e-Cert CA 1 - 10" intermediate cert be added to OneCRL. See the bug for further details.

It may make sense to explicitly tell Hongkong Post that it must not do anything which would have the effect of subverting/ undoing this change. For example, if Hongkong Post wants to create a new certificate for the intermediate "Hongkong Post e-Cert CA 1 - 10" (perhaps now with constraints forbidding SSL Server certs) it should ensure Mozilla understands and agrees the contents of that new certificate as appropriate first.

[Man Ho (Certizen)]

What about our existing SSL server certs, which are still valid until 31
Dec 2016? Majority of those cert. subscribers are offering government
and public services to residents of Hong Kong. And I believe the impact
to residents of Hong Kong will be huge when the browser suddenly prompt
a warning of insecure. In fact, all those cert. subscribers have their
own plans to migrate to new SHA-256 SSL server certs by 31 Dec 2016. Are
those existing SSL server certs going to be put in a white list at the
same time?

On 9/1/2016 2:32 AM, Kathleen Wilson wrote:
> Thanks to all of you who have provided thoughtful and constructive input into this discussion.
>
> I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1299579 to request that the "Hongkong Post e-Cert CA 1 - 10" intermediate cert be added to OneCRL. See the bug for further details.
>

> Kathleen

>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

> .
>

[Man Ho (Certizen)]

On 9/1/2016 3:52 AM, Nick Lamb wrote:
> It may make sense to explicitly tell Hongkong Post that it must not do anything which would have the effect of subverting/ undoing this change. For example, if Hongkong Post wants to create a new certificate for the intermediate "Hongkong Post e-Cert CA 1 - 10" (perhaps now with constraints forbidding SSL Server certs) it should ensure Mozilla understands and agrees the contents of that new certificate as appropriate first.

We actually planned to create a new Sub CA ("Hongkong Post e-Cert CA 2 -
16") for transitioning end-entity certs (except the SSL server certs)
under "Hongkong Post e-Cert CA 1 - 10" to it. All SSL server certs under
"Hongkong Post e-Cert CA 1 - 10" would be naturally expired, or revoked
by 31 Dec 2016. The key cutting and certificate generation is scheduled
in next week. It's great for Mozilla understanding the new Sub CA and I
highly appreciate your input so that we're explicitly told about the
requirement of intermediate certificate - that does not issue SSL server
cert.

But the creation of the new Sub CA seems to be off-topic. I will open
another thread when we're ready.

[Matt Palmer]

On Thu, Sep 01, 2016 at 10:14:01AM +0800, Man Ho (Certizen) wrote:
> What about our existing SSL server certs, which are still valid until 31
> Dec 2016? Majority of those cert. subscribers are offering government
> and public services to residents of Hong Kong.

You might want to let them know it's time to get new certs.

- Matt

[Man Ho (Certizen)]

On 9/1/2016 6:13 PM, Matt Palmer wrote:
> You might want to let them know it's time to get new certs.
>
> - Matt

We did inform all subscribers back in October 2014 that SHA-1 SSL server
cert was CEASED since 1 January 2016, and reminded each of them
individually that SHA-1 SSL server cert will no longer be trusted by
browsers starting from 1 January 2017. Some of them might have replaced
their SHA-1 SSL server cert by new cert (either from us or other CA, I
don't know), without letting us know to revoke their SHA-1 SSL server
cert. Some of them might want to keep using their SHA-1 SSL server cert
until its expiry, which is still well before the well-known deadline 1
January 2017. I believe that their rights to use SHA-1 SSL server cert
before deadline should not be affected.

[Nick Lamb]

On Thursday, 1 September 2016 12:48:34 UTC+1, Man Ho (Certizen) wrote:
> We did inform all subscribers back in October 2014 that SHA-1 SSL server
> cert was CEASED since 1 January 2016, and reminded each of them
> individually that SHA-1 SSL server cert will no longer be trusted by
> browsers starting from 1 January 2017. Some of them might have replaced
> their SHA-1 SSL server cert by new cert (either from us or other CA, I
> don't know), without letting us know to revoke their SHA-1 SSL server
> cert. Some of them might want to keep using their SHA-1 SSL server cert
> until its expiry, which is still well before the well-known deadline 1
> January 2017. I believe that their rights to use SHA-1 SSL server cert
> before deadline should not be affected.

The action that triggered this sanction was under your control. If it was vital to Hongkong Post to avoid this outcome, then SHA-1 issuance of any kind under the unconstrained intermediate should have ceased at the end of 2015 as required and then we wouldn't be having this discussion.

Ultimately it is unfair to expose relying parties to additional risk as a result of bad choices by a CA or subscriber, so if somebody has to be inconvenienced it makes sense for it to be Hongkong Post or its subscribers.

If the effect of this action by Mozilla is to encourage some Hongkong Post subscribers to switch to a different CA which doesn't engage in problematic behaviours, OR for those subscribers to demand from Hongkong Post that it should avoid such behaviours in future so as to prevent any further inconvenience to the subscribers; either of those works out well for the relying parties.

[Matt Palmer]

On Thu, Sep 01, 2016 at 07:48:23PM +0800, Man Ho (Certizen) wrote:
>
> On 9/1/2016 6:13 PM, Matt Palmer wrote:
> > You might want to let them know it's time to get new certs.
> >
> > - Matt

> We did inform all subscribers back in October 2014 that SHA-1 SSL server
> cert was CEASED since 1 January 2016, and reminded each of them
> individually that SHA-1 SSL server cert will no longer be trusted by
> browsers starting from 1 January 2017. Some of them might have replaced
> their SHA-1 SSL server cert by new cert (either from us or other CA, I
> don't know), without letting us know to revoke their SHA-1 SSL server
> cert. Some of them might want to keep using their SHA-1 SSL server cert
> until its expiry, which is still well before the well-known deadline 1
> January 2017. I believe that their rights to use SHA-1 SSL server cert
> before deadline should not be affected.

They're within their rights to use it, but if Mozilla's going to blacklist
the intermediate, they're not going to get the results they want from the
product you sold them.

- Matt

[Kathleen Wilson]

I updated https://bugzilla.mozilla.org/show_bug.cgi?id=1299579#c9
with:
""
... here is the approach that we plan to take:

We will add the "Hongkong Post e-Cert CA 1 - 10" intermediate cert to OneCRL at the end of October.

Please replace all of the SSL certs chaining up to this intermediate cert that expire after October, because we do not plan to add them to a whitelist.

We believe that this is a reasonable compromise. However, if there is compelling evidence to do so, we will add the intermediate cert to OneCRL earlier -- we will let you know if this becomes necessary.
""

Thanks,
Kathleen