Re: Nation State MITM CA's ?

2019-07-22 Thread Han Yuwei via dev-security-policy
在 2016年1月7日星期四 UTC+8上午7:08:10,Paul Wouters写道:
> 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

Adding banner is a acceptable action to hint this kind of attacking.
Banning this CA can't solve any problem, because KZ ISP can just block any TLS 
connections. But maybe we can let websites choose which CA they would use just 
like HSTS.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Does Heartbleed count for the purposes of BR 4.9.1.1 point 11? ("proven or demonstrated method")

2019-05-27 Thread Han Yuwei via dev-security-policy
在 2019年5月27日星期一 UTC+8上午10:05:25,Matt Palmer写道:
> On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy 
> wrote:
> > If malloc() is correctly implemented, private keys are secure from 
> > Heartbleed. So
> > I think it doesn't meet the criteria.
> 
> Just to make sure I'm understanding you correctly, you're saying that being
> vulnerable to Heartbleed doesn't *necessarily* expose private keys, it
> requires an additional criteria (malloc being "incorrectly implemented"),
> thus it doesn't fit the definition of a "proven method that exposes the
> Subscriber's Private Key to compromise"?
> 
> > CAs can't revoke a certificate without noticing subscriber in advance.
> 
> Can you point me to where that requirement comes from?  Some CAs don't
> necessarily have *any* notification method for their subscribers (Let's
> Encrypt immediately comes to mind); does that mean they're immune from
> revocation requirements?  Is there any requirement around how quickly CAs
> are required to notify subscribers, and does that time come out of the 24
> hour / 5 day budget, or is it some additional time period?
> 
> > But if any bugs found in future which can retrieve private keys from TLS 
> > endpoints, 
> > you can just use automated tools to scan them and get private keys to 
> > request a
> > revoke. I thought this is the best practice to this BR.
> 
> OK, so that's one vote for "just scan the Internet and drop private keys on
> CAs for revocation within 24 hours".
> 
> - Matt

1. Yes, it doesn't fit ( for what I thought)
2. I missed some words. please add "without proven fact that the certificate is 
not secure"

I thought what Matt says is not about charge, it is about potential policy to 
further mass private key compromising. I don't think this have anything to do 
with StartCom.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")

2019-05-26 Thread Han Yuwei via dev-security-policy
If malloc() is correctly implemented, private keys are secure from Heartbleed. 
So
I think it doesn't meet the criteria. CAs can't revoke a certificate without 
noticing 
subscriber in advance.
But if any bugs found in future which can retrieve private keys from TLS 
endpoints, 
you can just use automated tools to scan them and get private keys to request a
revoke. I thought this is the best practice to this BR.
在 2019年5月27日星期一 UTC+8上午9:34:31,Matt Palmer写道:
> Hi everyone,
> 
> In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned
> to everyone's favourite bug, Heartbleed.  Whilst hitting all the vulnerable
> servers and pulling their keys is eminently possible (see, as just one
> example, https://github.com/robertdavidgraham/heartleech), I recalled that
> CAs are responsible for revoking certificates within 5 days (with a "SHOULD"
> of 24 hours) when:
> 
> > The CA is made aware of a demonstrated or proven method that exposes the
> > Subscriber's Private Key to compromise, methods have been developed that
> > can easily calculate it based on the Public Key (such as a Debian weak
> > key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence
> > that the specific method used to generate the Private Key was flawed
> 
> (Taken from BRs v1.6.3, because that's what I happened to have handy)
> 
> That sounds an *awful* lot like Heartbleed: "a [...] proven method that
> exposes the Subscriber's Private Key to compromise".
> 
> Several questions arise from this, which I'd like to get the opinion of the
> members of this illustrious debating society:
> 
> 1. Do others agree that Heartbleed appears to meet the criteria of this
>paragraph in the BRs?
> 
> 2. Assuming "yes" to the above question, is it (still) reasonable to require
>CAs to revoke certificates within 5 days if notified that a certificate
>they issued is being served from an endpoint vulnerable to Heartbleed?
> 
> 3. Assuming "yes" to the above questions, should I stand up a tool to watch
>certificates coming out of CT logs, identify endpoints serving those
>certificates, test them for Heartbleed, and report these facts to CAs for
>appropriate handling?
> 
> Of course, if it's deemed that Heartbleed *isn't* "a proven method etc etc",
> the keys could just be pulled directly, which I'm led to believe typically
> takes a lot less than four days (and which would trigger the
> 24-hour-required revocation), but it seems to me "politer" to everyone to
> use the less intrusive option.
> 
> Additional comments surrounding this issue, not pertaining specifically to
> the above three questions, would also be gladly received.
> 
> - Matt

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


Re: CAA record checking issue

2019-05-11 Thread Han Yuwei via dev-security-policy
This raised a question:
 How can CA prove they have done CAA checks or not at the time of issue? 

在 2019年5月10日星期五 UTC+8上午10:05:36,Jeremy Rowley写道:
> FYI, we posted this today:
> 
>  
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1550645
> 
>  
> 
> Basically we discovered an issue with our CAA record checking system. If the
> system timed out, we would treat the failure as a DNS failure instead of an
> internal failure. Per the BRs Section 3.2.2:
> 
> "CAs are permitted to treat a record lookup failure as permission to issue
> if: 
> 
> . the failure is outside the CA's infrastructure; 
> 
> . the lookup has been retried at least once; and 
> 
> . the domain's zone does not have a DNSSEC validation chain to the ICANN
> root"
> 
>  
> 
> The failure was not outside our infrastructure so issuance was improper. 
> 
>  
> 
> We checked all the applicable CAA records and found 16 where the CAA record
> would not permit us to issue if we were issuing a new cert today. What we
> are proposing is to revoke these certificates and reissue them (if they pass
> all the proper checks). The rest would pass if we issued today so we were
> going to leave these where they are while disclosing them to the Mozilla
> community. 
> 
>  
> 
> Other suggestions are welcome. 
> 
>  
> 
> The issue was put into the code back when CAA record checking became
> mandatory (Sept 2017).  We generally have a peer review of our code so that
> at least one other developer has looked at the system before release. In
> this case, neither PM nor a second reviewer was involved in the development.
> We've since implemented more stringent development processes, including
> ensuring a PM reviews and brings questions about projects to the compliance
> team. 
> 
>  
> 
> Anyway, let me know what questions, comments, etc you have.
> 
>  
> 
> Thanks!
> 
> Jeremy

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


Re: Reported Digicert key compromise but not revoked

2019-05-11 Thread Han Yuwei via dev-security-policy
Thanks for that. So now I should send another email to rev...@digicert.com or 
just wait for revocation? And who should I contact if this address doesn't work?
在 2019年5月10日星期五 UTC+8上午8:26:09,Jeremy Rowley写道:
> No argument from me there. We generally act on them no matter what.
> Typically any email sent to supp...@digicert.com requesting revocation is
> forwarded to rev...@digicert.com. That's the standard procedure. This one
> was missed unfortunately.
> 
> -Original Message-
> From: dev-security-policy  On
> Behalf Of Daniel Marschall via dev-security-policy
> Sent: Thursday, May 9, 2019 4:16 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Reported Digicert key compromise but not revoked
> 
> I personally do think that it matters to this forum. A CA - no matter what
> kind of certificates it issues - must take revocation requests seriously and
> act immediately, even if the email is sent to the wrong address. If an
> employee at the help desk is unable to forward revocation requests, or needs
> several weeks to reply, then there is something not correct with the CA, no
> matter if the revocation request is related to a web certificate or code
> signing certificate. That's my opinion on this case.
> ___
> 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


Reported Digicert key compromise but not revoked

2019-05-09 Thread Han Yuwei via dev-security-policy
Hi m.d.s.p
I have reported a key compromise incident to digicert by contacting 
support(at)digicert.com at Apr.13, 2019 and get replied at same day. But it 
seems like this certificate is still valid.
This certificate is a code signing certificate and known for signing malware. 
So I am here to report this to Digicert. If private key is needed I will attach 
it.

Certificate Info.
CN:Beijing Founder Apabi Technology Limited
SN: 06B7AA2C37C0876CCB0378D895D71041
SHA1: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Found something I can't understand in these cerificates.

2017-08-01 Thread Han Yuwei via dev-security-policy
https://crt.sh/?id=7040227
https://crt.sh/?id=30328289

I am confused for those reasons.

1. the CN of two cerificates are same. So it is not necessary to issue two 
certificates in just 2 minutes.
2. second one used SHA1, though is consistent with BR, but first one used 
SHA256.
3. first one has 39 month period of validity which is very rare.
4. Since they are issued so close they should be logged at CT same time but 
second one are too late.

So is there some common parctice I don't know or another mistake made by Wosign?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Find a 5-year certificate

2017-05-09 Thread Han Yuwei via dev-security-policy
I have found this:
https://crt.sh/?id=6885329

I don't know whether Mozilla had allowed the certificate valid more than 39 
months, so I am here to verify it.

I have searched on Github but found nothing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-03 Thread Han Yuwei via dev-security-policy
A question:How would a domain holder express denial for certain certificate 
requests?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Symantec: Draft Proposal

2017-05-03 Thread Han Yuwei via dev-security-policy
So Mozilla think Symantec's issues are on t serious enough to lose trust 
entirely?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy