Expired Certificates Listed by Certificate Manager

2017-07-25 Thread David E. Ross via dev-security-policy
Under the Servers tab for Certificate Manager, I see several root
certificates whose expiration dates have passed.  I believe these were
all marked untrusted at one time.  For example, I see six DigiNotar
certificates, CNNIC's MCSHOLDING TEST, Equifax's MD5 Collisions, among
others.  Is it safe to delete these?

No, I would not delete DigiNotar Root CA or DigiNotar PKIoverheid CA
Organisatie, neither of which have yet reached their expiration dates.

-- 
David Ross


President Trump now denies there are any tapes that
recorded his conversations with ex-FBI Director Comey.
Between when Trump hinted there might be such tapes
and his denial, there was sufficient time to destroy
any tapes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

2017-07-25 Thread Matthew Hardeman via dev-security-policy
On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5, birg...@princeton.edu wrote:
> We have been considering research in this direction. PEERING controls several 
> ASNs and may let us use them more liberally with some convincing. We also 
> have the ASN from Princeton that could be used with cooperation from 
> Princeton OIT (the Office of Information Technology) where we have several 
> contracts. The problem is not the source of the ASNs but the network anomaly 
> the announcement would cause. If we were to hijack the prefix of a 
> cooperating organization, the PEERING ASes might have their announcements 
> filtered because they are seemingly launching BGP attacks. This could be 
> fixed with some communication with ISPs, but regardless there is a cost to 
> launching such realistic attacks. Matthew Hardeman would probably know more 
> detail about how this would be received by the community, but this is the 
> general impression I have got from engaging with the people who run the 
> PEERING framework.

I have some thoughts on how to perform such experiments while mitigating the 
likelihood of significant lasting consequence to the party helping ingress the 
hijack to the routing table, but you correctly point out that the attack 
surface is large and the one consistent feature of all discussion up to this 
point on the topic of BGP hijacks for purpose of countering CA domain 
validation is that none of those discuss have, up to this point, expressed 
doubt as to the risks or the feasibility of carrying out these risks.  To that 
ends, I think the first case that would need to be made to further that 
research is whether anything of significance is gained in making the attack 
more tangible.

> 
> So far we have not been working on such an attack very much because we are 
> focusing our research more on countermeasures. We believe that the attack 
> surface is large and there are countless BGP tricks an adversary could use to 
> get the desired properties in an attack. We are focusing our research on 
> simple and countermeasures CAs can implement to reduce this attack space. We 
> also aim to use industry contacts to accurately asses the false positive 
> rates of our countermeasures and develop example implementations.
> 
> If it appears that actually launching such a realistic attack would be 
> valuable to the community, we certainty could look into it further.

This is the question to answer before performing such an attack.  In effect, 
who is the audience that needs to be impressed?  What criteria must be met to 
impress that audience?  What benefits in furtherance of the work arise from 
impressing that audience?

Thanks,

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


Re: dNSName containing '/' / low serial number entropy

2017-07-25 Thread Alex Gaynor via dev-security-policy
Hi Mark,

Are you saying you do intend to revoke all of these certificates in the
next 24 hours?

While subscribers are allowed to continue using bad certificates as long as
they desire, the BRs require CAs to revoke non-compliant certificates
within 24 hours of becoming aware of them.

Alex

On Tue, Jul 25, 2017 at 3:20 PM, Policy Authority PKIoverheid via
dev-security-policy  wrote:

> Op woensdag 19 juli 2017 00:26:16 UTC+2 schreef Charles Reiss:
> > - Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to
> > Staat der Nederlanden Root CA - G2) has issued certificates which serial
> > numbers that appear to be of the form 0x1000 + sequential counter
> > with notBefores as recent as 8 June 2017.
>
>
> Hi Charles,
>
> Many thanks for bringing this to our attention. We have looked into this
> matter immediately. Meanwhile the Policy Authority PKIoverheid has
> prohibited Digidentity (one of the Trusted Service Providers within the
> PKIoverheid/Staat der Nederlanden hierarchy) from issuing new certificates.
>
> After investigation it emerged that a total of 777 certificates were issued
> from September 30th 2016 that are not compliant with BR ballot 164
> (https://cabforum.org/2016/07/08/ballot-164/) echoed by the same
> requirement
> in version 2.4 (Compliance date: February 28, 2017) from the Mozilla CA
> Certificate Policy. Digidentity will revoke and
> replace these non-compliant certificates. This wil take place on or before
> 31 August 2017. However this action requires the cooperation from
> subscribers. As you know we are in the midst of the Holiday Season so we
> can't completly rule out that some certificates will be replaced a couple
> of days after August the 31th. Nevertheless Digidentity will do her utmost
> to revoke and replace all certs before the 31th.
>
> As evidence that Digidentity is now compliant with regard to the
> certificate
> serial number requirement from the BR check the new issued SSL cert on this
> website: https://www.digidentity.eu/nl/home/
>
> The Policy Authority PKIoverheid has judged that Digidentity can resume
> issuing certificates now that they are in compliance with Ballot 164 and
> the Mozilla CA Policy.
>
> Please let me know if you have any questions.
>
> Further questions could also be answered by my collegaues Jorik van 't Hof
> or Jochem van den Berge.
>
> Thanks.
>
> Regards,
> Mark Janssen
> ___
> 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


Re: dNSName containing '/' / low serial number entropy

2017-07-25 Thread Policy Authority PKIoverheid via dev-security-policy
Op woensdag 19 juli 2017 00:26:16 UTC+2 schreef Charles Reiss:
> - Digidentity Services CA - G2 (https://crt.sh/?caid=868 ; chains to 
> Staat der Nederlanden Root CA - G2) has issued certificates which serial 
> numbers that appear to be of the form 0x1000 + sequential counter 
> with notBefores as recent as 8 June 2017.


Hi Charles,

Many thanks for bringing this to our attention. We have looked into this 
matter immediately. Meanwhile the Policy Authority PKIoverheid has
prohibited Digidentity (one of the Trusted Service Providers within the 
PKIoverheid/Staat der Nederlanden hierarchy) from issuing new certificates.

After investigation it emerged that a total of 777 certificates were issued 
from September 30th 2016 that are not compliant with BR ballot 164
(https://cabforum.org/2016/07/08/ballot-164/) echoed by the same requirement 
in version 2.4 (Compliance date: February 28, 2017) from the Mozilla CA 
Certificate Policy. Digidentity will revoke and
replace these non-compliant certificates. This wil take place on or before 
31 August 2017. However this action requires the cooperation from
subscribers. As you know we are in the midst of the Holiday Season so we 
can't completly rule out that some certificates will be replaced a couple
of days after August the 31th. Nevertheless Digidentity will do her utmost 
to revoke and replace all certs before the 31th.

As evidence that Digidentity is now compliant with regard to the certificate 
serial number requirement from the BR check the new issued SSL cert on this 
website: https://www.digidentity.eu/nl/home/ 

The Policy Authority PKIoverheid has judged that Digidentity can resume 
issuing certificates now that they are in compliance with Ballot 164 and the 
Mozilla CA Policy.

Please let me know if you have any questions.

Further questions could also be answered by my collegaues Jorik van 't Hof 
or Jochem van den Berge.

Thanks.

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


Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

2017-07-25 Thread birgelee--- via dev-security-policy
On Monday, July 24, 2017 at 5:31:33 AM UTC-7, Jakob Bohm wrote:
> On 22/07/2017 02:38, birge...@princeton.edu wrote:
> > On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
> >> It seems that a group of Princeton researchers just presented a live 
> >> theoretical* misissuance by Let's Encrypt.
> >>
> >> They did a sub-prefix hijack via a technique other than those I described 
> >> here and achieved issuance while passing-through traffic for other 
> >> destination within the IP space of the hijacked scope.
> >>
> >> They've got a paper at: 
> >> https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf
> >>
> >> I say that theoretical because they hijacked a /24 of their own /23 under 
> >> a different ASN but I am given to believe that the "adversarial" ASN is 
> >> also under their control or that they had permission to use it.  In as far 
> >> as this is the case, this technically isn't a misissuance because 
> >> hijacking ones own IP space is technically just a different routing 
> >> configuration diverting the traffic to the destination they properly 
> >> control to another point of interconnection they properly controlled.
> > 
> > Hi,
> > 
> > I am Henry Birge-Lee, one of the researchers at Princeton leading that 
> > effort. I just performed that live demo a couple hours ago. You are correct 
> > about how we performed that attack. One minor detail is that we were forced 
> > to use the same ASN twice (for both the adversary and the victim). The 
> > adversary and the victim were two different routers peering with completely 
> > different ASes, but we were forced to reuse the AS because we were 
> > performing the announcements with the PEERING testbed 
> > (https://peering.usc.edu/) and are not allowed to announce from another 
> > ASN. Thus from a policy point of view this was not a misissuance and our 
> > BGP announcements would likely not have triggered an alarm from a BGP 
> > monitoring system. Even if we had the ability to hijack another ASes prefix 
> > and trigger such alarms we would be hesitant to because of ethical 
> > considerations. Our goal was to demonstrate the effectiveness and ease of 
> > interception of the technique we used, not freak out network operators 
> > because of potential hijacks.
> > 
> > I know some may argue that had we triggered alarms from the major BGP 
> > monitoring frameworks, CAs might not have issued us the certificates the 
> > did. We find that this is unlikely because 1) The DV certificate signing 
> > process is automated but the type of BGP announcements we made would likely 
> > require manual review before they could be definitively flagged as an 
> > attack 2) There is no evidence CAs are doing this (we know Let's Encrypt 
> > does not use BGP data because of their transparency and conversations with 
> > their executive director Josh Aas as well as their engineering team).
> > 
> 
> Another testing option would have been to use another AS legitimately
> operated by someone associated with your research team.  Unless
> Princeton has historically obtained 2 AS numbers (this is not uncommon),
> 
> Cooperating with a researcher at another research facility could obtain
> the other AS number without any actual breach or hijack.
> 

We have been considering research in this direction. PEERING controls several 
ASNs and may let us use them more liberally with some convincing. We also have 
the ASN from Princeton that could be used with cooperation from Princeton OIT 
(the Office of Information Technology) where we have several contracts. The 
problem is not the source of the ASNs but the network anomaly the announcement 
would cause. If we were to hijack the prefix of a cooperating organization, the 
PEERING ASes might have their announcements filtered because they are seemingly 
launching BGP attacks. This could be fixed with some communication with ISPs, 
but regardless there is a cost to launching such realistic attacks. Matthew 
Hardeman would probably know more detail about how this would be received by 
the community, but this is the general impression I have got from engaging with 
the people who run the PEERING framework.

So far we have not been working on such an attack very much because we are 
focusing our research more on countermeasures. We believe that the attack 
surface is large and there are countless BGP tricks an adversary could use to 
get the desired properties in an attack. We are focusing our research on simple 
and countermeasures CAs can implement to reduce this attack space. We also aim 
to use industry contacts to accurately asses the false positive rates of our 
countermeasures and develop example implementations.

If it appears that actually launching such a realistic attack would be valuable 
to the community, we certainty could look into it further.

> > As for further work, implementation of countermeasures into the CA and 
> > Browser forum Baseline Requirements is our eventual goal and we 

RE: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Jeremy Rowley via dev-security-policy
Each CA is required (under the BRs) to provide public information on how to
submit certificate problem reports, including mis-issued certificates. The
only way to properly notify the CA is through that mechanism as those are
monitored 24 hours. CAs participating on the list usually have a couple of
reps who monitor and participate, but not 24x7. I do agree there should be
penalties for missing the 24 hour requirement to give the BRs a bit more
teeth, but those penalties should be based on the proper notice process
being followed. 

I would also love to see a more standardized notice mechanism that is
universal to all CAs. Right now, notifying CAs is a pain as some have
different webforms, some use email, and some don't readily tell you how to
contact them about certificate problems.  

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Tuesday, July 25, 2017 10:58 AM
To: Alex Gaynor 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Miss-issuance: URI in dNSName SAN

Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.

In any event, here are some certificates, by CA, that have been mis-issued
and linked on this list many days ago at this point:

PSCProcert - https://crt.sh/?id=124094761 - dNSName is a URI PSCProcert -
https://crt.sh/?id=175466182 - dNSName is for a .local domain Camerfirma
AAPP II - 2014 - https://crt.sh/?id=42531587 - dNSName is a URI AC
CAMERFIRMA AAPP - https://crt.sh/?id=5129200 - dNSName is a URI StartCom
Class 2 Primary Intermediate Server CA -
https://crt.sh/?id=10714112 - incorrect wildcard "*g10.net-lab.net"
StartCom Class 3 OV Server CA - https://crt.sh/?id=17295812 - incorrect
wildcard "*dev02.calendar42.com"
StartCom Class 1 DV Server CA - https://crt.sh/?id=78248795 - invalid
dNSName "-1ccenter.777chao.com"
TI Trust Technologies Global CA - https://crt.sh/?id=48682944 - invalid
wildcard "*nuvolaitaliana.it"
UniCredit Subordinate External - https://crt.sh/?id=44997156 - invalid
wildcard "*.*.rnd.unicredit.it"
Swisscom Smaragd CA 2 - https://crt.sh/?id=5982951 - invalid wildcard "*.*.
int.swisscom.ch"
Swisscom Smaragd CA 2 - https://crt.sh/?id=175444569 - dNSName is for a
.local domain Verizon Public SureServer CA G14-SHA2 -
https://crt.sh/?id=33626750 - dNSName is for a .test domain Verizon Public
SureServer CA G14-SHA2 - https://crt.sh/?id=12344381 - dNSName is for a
.local domain CLASS 2 KEYNECTIS CA - https://crt.sh/?id=42475510 - dNSName
is for a .corp domain EC-SectorPublic - https://crt.sh/?id=98706307 -
dNSName is for a .local domain


Should there be some penalty for the failure of CAs to revoke within the
time period required by the BRs?

Alex

On Sat, Jul 22, 2017 at 10:11 AM, alex.gaynor--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It has now been several days, does Camerafirma intend to revoke these 
> certificates, as required by the BRs (within 24 hours of being notified)?
> ___
> 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


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: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Kurt Roeckx via dev-security-policy
On Tue, Jul 25, 2017 at 12:57:44PM -0400, Alex Gaynor via dev-security-policy 
wrote:
> Following up on this (and really several other threads). The BRs require
> mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
> are required to track m.d.s.p. per the Mozilla Root Policy, so really
> notifying this list _ought_ to qualify as notifying the CAs.

I think requests for revocation should be done using the contact
information they provided to do that.


Kurt

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


Re: Miss-issuance: URI in dNSName SAN

2017-07-25 Thread Alex Gaynor via dev-security-policy
Following up on this (and really several other threads). The BRs require
mis-issued certs to be revoked with 24 hours of the CA becoming aware. CAs
are required to track m.d.s.p. per the Mozilla Root Policy, so really
notifying this list _ought_ to qualify as notifying the CAs.

In any event, here are some certificates, by CA, that have been mis-issued
and linked on this list many days ago at this point:

PSCProcert - https://crt.sh/?id=124094761 - dNSName is a URI
PSCProcert - https://crt.sh/?id=175466182 - dNSName is for a .local domain
Camerfirma AAPP II - 2014 - https://crt.sh/?id=42531587 - dNSName is a URI
AC CAMERFIRMA AAPP - https://crt.sh/?id=5129200 - dNSName is a URI
StartCom Class 2 Primary Intermediate Server CA -
https://crt.sh/?id=10714112 - incorrect wildcard "*g10.net-lab.net"
StartCom Class 3 OV Server CA - https://crt.sh/?id=17295812 - incorrect
wildcard "*dev02.calendar42.com"
StartCom Class 1 DV Server CA - https://crt.sh/?id=78248795 - invalid
dNSName "-1ccenter.777chao.com"
TI Trust Technologies Global CA - https://crt.sh/?id=48682944 - invalid
wildcard "*nuvolaitaliana.it"
UniCredit Subordinate External - https://crt.sh/?id=44997156 - invalid
wildcard "*.*.rnd.unicredit.it"
Swisscom Smaragd CA 2 - https://crt.sh/?id=5982951 - invalid wildcard "*.*.
int.swisscom.ch"
Swisscom Smaragd CA 2 - https://crt.sh/?id=175444569 - dNSName is for a
.local domain
Verizon Public SureServer CA G14-SHA2 - https://crt.sh/?id=33626750 -
dNSName is for a .test domain
Verizon Public SureServer CA G14-SHA2 - https://crt.sh/?id=12344381 -
dNSName is for a .local domain
CLASS 2 KEYNECTIS CA - https://crt.sh/?id=42475510 - dNSName is for a .corp
domain
EC-SectorPublic - https://crt.sh/?id=98706307 - dNSName is for a .local
domain


Should there be some penalty for the failure of CAs to revoke within the
time period required by the BRs?

Alex

On Sat, Jul 22, 2017 at 10:11 AM, alex.gaynor--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It has now been several days, does Camerafirma intend to revoke these
> certificates, as required by the BRs (within 24 hours of being notified)?
> ___
> 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


Re: Private key corresponding to public key in trusted Cisco certificate embedded in executable

2017-07-25 Thread simon.waters--- via dev-security-policy
On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb  wrote:
> On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman  wrote:
> > The right balance is probably revoking when misuse is shown.
> 
> Plus education. Robin has stated that there _are_ suitable CA products for 
> this use case in existence today, but if I didn't know it stands to reason 
> that at least some of the engineers at Cisco didn't know either.
> 
> Knowing what the Right Thing is makes it easier to push back when somebody 
> proposes (as they clearly did here) the Wrong Thing. If, at the end of the 
> day, Cisco management signs off on the additional risk from doing the Wrong 
> Thing because it's cheaper, or faster, or whatever, that's on them. But if 
> nobody in their engineering teams is even aware of the alternative it becomes 
> a certainty.

I'm aware of another instance of this pattern in widely deployed software, 
discovered through security testing 3rd party applications (Thanks to Hanno 
discussing related issue on twitter).

The pattern "Using a certificate with DNS resolving to 127.0.0.1 to allow a 
browser page to communicate with a local web server".

Although it was done in an insecure fashion (not yet fully resolved, so 
disclosure would be unhelpful), I don't see a good alternative model for this 
vendor's use case.

I also looked when I first found the encrypted P12 file (and password hardcoded 
into the application), and found nothing useful online discussing this pattern, 
or alternatives. 

I only found that you could no longer register certificates for 127.0.0.1 (the 
world only needs one such).

The mass issuance of certificates described above doesn't seem any better, 
since there still needs to be a trust relationship with an unprotected 
appliance or application. Or is there some aspect of the certificates issuance 
that bind them to a particular implementation (I thought all such binding were 
basically broken in most TLS implementations).

What is the recommended practice here?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Machine- and human-readable format for root store information?

2017-07-25 Thread Belyavskiy Dmitry via dev-security-policy
Hello Kai, 

On Friday, June 30, 2017 at 7:38:59 PM UTC+3, Kai Engert wrote:
> Hello Gerv,
> 
> I think the new format should be as complete as possible, including both trust
> and distrust information, including EV and description of rules for partial
> distrust.
> 
> As of today, certdata.txt contains:
> - whitelisted root CAs (trusted for one or more purposes)
> - distrusted/blacklisted certificates (which can be either CAs, intermediate
>   CAs or end entity certificates), based on varying identification criteria
>   (sometimes we distrust all matches based on issuer/serial, 
>sometimes we are more specific and only distrust if the certificate also
>matches exactly a specific hash)
> 
> But it doesn't list the additional decisions that Mozilla has implemented in
> code:
> - additional domain name constraints
> - additional validity constraints for issued certificates
> - additional required whitelist matching

...

> We could define identifiers for each class of trust restrictions (CTR), e.g.:
> - permitted name constraint
> - excluded name constraints
> - restricted to serial/name whitelist
> - not valid for serial/name blacklist
> - restrict validity period of root CA
> - restrict allowed validity of issued EE or intermediates
> - require successful revocation checking
> - require successful Certificate Transparency lookup
> - ...
> 
> This list could be expanded in the future, so a list consumer that has
> implemented all of the older CTRs could decide to not trust new CAs that have
> unknown CTRs defined.


Let me introduce an IETF draft 
https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/

The draft is in initial phase. I made a presentation based on it during the 
SAAG meeting on IETF 99. It describes a possible format for such list of 
limitations applied to trusted certificates. The specification is designed to 
avoid as much limitations hard-coded in applications as possible.

So if there is any interest in improving in finalizing the draft, it will be 
great. I got at least some interest in it from the OpenSSL team.

--
Sincerely yours, Dmitry Belyavskiy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy