RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Hi Cynthia, 

We've figured out what happened with your certificate but are still looking at 
whether other certificates were issued using the same process. I don't have 
enough information to file an incident report yet, but I wanted to give you the 
update I promised earlier. 

Basically, here's what happened:
1. A validation agent took an email address provided during a chat session with 
you and set that email as a WHOIS admin email address. This email qualified as 
a constructed email (admin@domain)
2. The system marked the WHOIS as unavailable for automated parsing (generally, 
this happens if we are being throttled or the WHOIS info is behind a CAPTCHA), 
which allows a validation agent to manually upload a WHOIS document
3. The WHOIS document uploaded was a screen capture of WHOIS information that 
did not match the domain being requested but was close enough that the 
mis-match went unnoticed. 
4. The validation agent specified the approval scope as id-addr.arpa which is 
normal for a domain approved by the admin listed in WHOIS. As a constructed 
email, the approval scope should have been limited to the scope set by the 
constructed address.
5. The validation agent specified that the email address listed in WHOIS 
matched the email address provided by you (admin@domain) and sent the email to 
authorize the legit cert
6 . When the validation completed successfully, the validation authorized your 
account for all certificates with the in-addr.arpa domain. This was because the 
scope was improperly set based on the validation agent's improper specification 
of the source of the email address. 
7. During the review, no one noticed that the WHOIS document did not match the 
verification email nor did anyone notice that the email used for verification 
was actually a constructed email instead of the WHOIS admin email.
8. The mis-issued certificate essentially "piggy-backed" on the previous 
verification because of the erroneous approval scope set by the validation 
staff.

Make sense? 

We shut down manual WHOIS verification while we figure out how to improve the 
process and eliminate validation mistakes like this. We'll post another update 
after we figure out how to improve the process and after the data review is 
complete.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman 
Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the 
email it had an option along the lines of "Authorize in-addr.arpa for all 
orders on account #123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com, I could get a cert for google.com if this 
is a systemic issue and not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:
> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
> rarely has anything other than PTR and NS records defined.
>
> Here this was clearly achieved by creating a CNAME record for 
> 69.168.110.79.in-addr.arpa pointed to cynthia.re .
>
> I've never seen any software or documentation anywhere attempting to 
> utilize a reverse-IP formatted in-addr.arpa address as though it were 
> a normal host name for resolution.  I wonder whether this isn't a case 
> that should just be treated as an invalid domain for purposes of SAN 
> dnsName (like .local).
>
> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>  > wrote:
>
> Thanks Cynthia. We are investigating and will report back shortly.
> 
> From: dev-security-policy
>  > on behalf
> of Cynthia Revström via dev-security-policy
>  >
> Sent: Tuesday, February 26, 2019 12:02:20 PM
> To: dev-security-policy@lists.mozilla.org
> 
> Cc: b...@benjojo.co.uk 
> Subject: Possible DigiCert in-addr.arpa Mis-issuance
>
> Hello dev.security.policy
>
>
> Apologies if I have made any mistakes in how I post, this is my first
> time posting here. Anyway:
>
>
> I have managed to issue a certificate with a FQDN in the SAN that I do
> not have control of via Digicert.

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

While I was going to respond to the below, Nick Lamb has beaten me to it.
I concur in full with the remarks in that reply.

We should not be picking national favorites as a root program.  There's a
whole world out there which must be supported.

What we should be doing is ensuring that we know the parties involved, have
mechanisms for monitoring their compliance, and have mechanisms for
untrusting parties who misissue.

On Wed, Feb 27, 2019 at 8:30 AM Alex Gaynor  wrote:

> (Writing in my personal capacity)
>
> I don't think this is well reasoned. There's several things going on here.
> First, the United States government's sovereign jurisdiction has nothing to
> do with any of these companies' business relationship with it. All would be
> subject to various administrative and judicial procedures in any event.
> Probably most relevantly, the All Writs Act (see; Apple vs FBI) -- although
> it's not at all clear that it would extend to a court being able to compel
> a CA to misissue. (Before someone jumps in to say "National Security
> Letter", you should probably know that an NSL is an administrative subpoena
> for a few specific pieces of a non-content metadata, not a magic catch all.
> https://www.law.cornell.edu/uscode/text/18/2709). Again, none of which is
> impacted by these company's being government contractors.
>
> Finally, I think there's a point that is very much being stepped around
> here. The United States Government, including its intelligence services,
> operate under the rule of law, it is governed by both domestic and
> international law, and various oversight functions. It is ultimately
> accountable to elected political leadership, who are accountable to a
> democracy. The same cannot be said of the UAE, which is an autocratic
> monarchy. Its intelligence services are not constrained by the rule of law,
> and I think you see this reflected in the targetting of surveillance
> described in the Reuters article: journalists, human rights activists,
> political rivals.
>
> While it can be very tempting to lump all governments, and particularly
> all intelligence services, into one bucket, I think it's important we
> consider the variety of different ways such services can function.
>
> Alex
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Matthew Hardeman via dev-security-policy]

On Wed, Feb 27, 2019 at 9:04 AM Nick Lamb  wrote:

>
> It does feel as though ARPA should consider adding a CAA record to
> in-addr.arpa and similar hierarchies that don't want certificates,
> denying all CAs, as a defence in depth measure.
>

Unless I significantly misunderstand CAA, this mechanism would not
necessarily be effective.

The normal mode of operation is that at the in-addr.arpa zone delegates sub
zones, for example 199.in-addr.arpa to the relevant RIR via an NS record.
Further, the relevant RIR would delegate sub zones of that zone via NS
records to an IP space holder, for example 88.99.199.in-addr.arpa would
have NS records configured on the RIR name servers which would refer to the
authoritative DNS servers serving the IP space holder for 199.99.88.0/24.

As such, superseding CAA records which would allow issuance could be added
back into those hierarchies by the DNS admins of those zones.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Nick Lamb via dev-security-policy]

On Wed, 27 Feb 2019 09:30:45 -0500
Alex Gaynor via dev-security-policy
 wrote:

> Finally, I think there's a point that is very much being stepped
> around here. The United States Government, including its intelligence
> services, operate under the rule of law, it is governed by both
> domestic and international law, and various oversight functions. It
> is ultimately accountable to elected political leadership, who are
> accountable to a democracy.

So, on my bookshelf I have a large book with the title "The Senate
Intelligence Committee Report On Torture".

That book is pretty clear that US government employees, under the
direction of US government officials and with the knowledge of the
government's executive tortured and murdered people, to no useful
purpose whatsoever. For the avoidance of doubt, those are international
crimes.

Are those employees, officials and executives now... in prison? Did
they face trial, maybe in an international court explicitly created for
the purpose of trying such people?

Er, no, they are honoured members of US society, and in some cases
continue to have powerful US government jobs. The US is committed to
using any measures, legal or not, to ensure none of them see justice.


Sure, there are lots of places where there wouldn't even be a book
published saying "Here are these terrible things we did". But that's a
very low bar. For the purposes of m.d.s.policy we definitely have to
assume that the United States of America very much may choose to
disregard the "rule of law" if it suits those in power to do so.

I don't think the insistence that the UAE is definitively worse than
the US helps this discussion at all. We're not here to publish books
about awful things done by governments years after the fact, we're here
to protect Relying Parties. It is clear they will need protecting from
the US Government _and_ the United Arab Emirates.

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

Re: Request to Include Hongkong Post Root CA 3

[Wayne Thayer via dev-security-policy]

Having received no further comments, I am recommending approval of Hongkong
Post's inclusion request.

As Matt suggested earlier in this thread, I would not typically approve a
request for a CA with an open compliance bug, but in this case the bug is
open awaiting implementation of pre-issuance linting, something that is not
required by our policy. Hongkong Post states that they have implemented
post-issuance linting and expect their CA system vendor to support
pre-issuance linting within a few months.

- Wayne

On Fri, Feb 15, 2019 at 11:35 AM Wayne Thayer  wrote:

> I have confirmed that the problems identified with the CPS have been
> corrected. [1]
>
> Regarding the comments from Ian on the BR violations in 2016 that resulted
> in adding an intermediate to OneCRL [2], this appears to have been the
> result of the belief that was held by many CAs at that time that only
> certificates "intended" to be used for serverAuth were subject to BR
> requirements. That doesn't excuse the very serious threat that was posed by
> Hongkong Post's issuance of SHA-1 certificates with sequential serial
> numbers that were valid for serverAuth.
>
> Hongkong Post has provided an incident report and answered follow-up
> questions in the bug [3] documenting the failure to report misissued
> certificates. Hongkong Post states that they are currently performing
> post-issuance linting on a monthly basis. They plan to implement
> pre-issuance linting as soon as their CA software vendor supports it. The
> bug will remain open until that is completed.
>
> I would like to make a decision next week on how to proceed with this
> request. Please post any additional comments or concerns by Wednesday
> 20-February.
>
> - Wayne
>
> [1] https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en4.pdf
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1520299
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Well yes, assuming the validation person overrides the safeguards and randomly 
changes the scope of the domain validation to something other than what the 
system specifies. We're still looking into how this happened and if the 
validation agent did this in any other case. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Wednesday, February 27, 2019 8:45 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

Okay that seems like an issue as to me that says that this could have happened 
to any domain and not just in-addr.arpa?

- Cynthia

On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote:
>  From our side, a validation agent weirdly scoped the domain, saying that the 
> domain was approved using an email to ad...@in-addr.arpa. However, the email 
> clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how 
> did the validation staff override the domain approval scope and 2) did anyone 
> in validation ever do this before. Once we complete that search, we'll be 
> able to file a bug report and give you more information on what exactly went 
> wrong.
>
> .arpa is in IANA's root zone per https://www.iana.org/domains/root/db.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
>  On Behalf Of Cynthia 
> Revström via dev-security-policy
> Sent: Tuesday, February 26, 2019 4:17 PM
> To: Matthew Hardeman 
> Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
> Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance
>
> I am not so sure that is proper to have .arpa domains in the SANs.
>
> But I think the larger issue I think is that this might allow for non 
> in-addr.arpa domains to be used as well.
>
> It was just that I just tried to get a cert for my domain for a test to see 
> if that would be issued.
>
> And upon verifying the domain via email, I saw that on the page linked in the 
> email it had an option along the lines of "Authorize in-addr.arpa for all 
> orders on account #123456" (not that exact text but the same meaning).
>
> Now I am not sure if this would work, but I suspect if for example I got DNS 
> control over cynthia.site.google.com, I could get a cert for google.com if 
> this is a systemic issue and not just a one off.
>
> - Cynthia
>
> On 2019-02-27 00:10, Matthew Hardeman wrote:
>> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>>
>> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
>> rarely has anything other than PTR and NS records defined.
>>
>> Here this was clearly achieved by creating a CNAME record for 
>> 69.168.110.79.in-addr.arpa pointed to cynthia.re .
>>
>> I've never seen any software or documentation anywhere attempting to 
>> utilize a reverse-IP formatted in-addr.arpa address as though it were 
>> a normal host name for resolution.  I wonder whether this isn't a 
>> case that should just be treated as an invalid domain for purposes of 
>> SAN dnsName (like .local).
>>
>> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>> > > wrote:
>>
>>  Thanks Cynthia. We are investigating and will report back shortly.
>>  
>>  From: dev-security-policy
>>  >  > on behalf
>>  of Cynthia Revström via dev-security-policy
>>  >  >
>>  Sent: Tuesday, February 26, 2019 12:02:20 PM
>>  To: dev-security-policy@lists.mozilla.org
>>  
>>  Cc: b...@benjojo.co.uk 
>>  Subject: Possible DigiCert in-addr.arpa Mis-issuance
>>
>>  Hello dev.security.policy
>>
>>
>>  Apologies if I have made any mistakes in how I post, this is my first
>>  time posting here. Anyway:
>>
>>
>>  I have managed to issue a certificate with a FQDN in the SAN that I do
>>  not have control of via Digicert.
>>
>>
>>  The precert is here: https://crt.sh/?id=1231411316
>>
>>  SHA256:
>>  651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1
>>
>>
>>  I have notified Digicert who responded back with a generic response
>>  followed by the certificate being revoked through OCSP. However I
>>  believe that this should be wider investigated, since this cert was
>>  issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
>>  that I do control though reverse DNS.
>>
>>
>>  When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
>>  that the whole of in-addr.arpa became validated on my account, instead
>>  of just my small section of it (168.110.79.in-addr.arpa at best).
>>
>>
>>  To test if digicert had just in fact mis-validated a FQDN, I
>>  tested with
>>  the reverse DNS 

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

Okay that seems like an issue as to me that says that this could have 
happened to any domain and not just in-addr.arpa?


- Cynthia

On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote:

 From our side, a validation agent weirdly scoped the domain, saying that the 
domain was approved using an email to ad...@in-addr.arpa. However, the email 
clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how 
did the validation staff override the domain approval scope and 2) did anyone 
in validation ever do this before. Once we complete that search, we'll be able 
to file a bug report and give you more information on what exactly went wrong.

.arpa is in IANA's root zone per https://www.iana.org/domains/root/db.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman 
Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the email it 
had an option along the lines of "Authorize in-addr.arpa for all orders on account 
#123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com, I could get a cert for google.com if this 
is a systemic issue and not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:

Is it even proper to have a SAN dnsName in in-addr.arpa ever?

While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
rarely has anything other than PTR and NS records defined.

Here this was clearly achieved by creating a CNAME record for
69.168.110.79.in-addr.arpa pointed to cynthia.re .

I've never seen any software or documentation anywhere attempting to
utilize a reverse-IP formatted in-addr.arpa address as though it were
a normal host name for resolution.  I wonder whether this isn't a case
that should just be treated as an invalid domain for purposes of SAN
dnsName (like .local).

On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>> wrote:

 Thanks Cynthia. We are investigating and will report back shortly.
 
 From: dev-security-policy
 mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
 of Cynthia Revström via dev-security-policy
 mailto:dev-security-policy@lists.mozilla.org>>
 Sent: Tuesday, February 26, 2019 12:02:20 PM
 To: dev-security-policy@lists.mozilla.org
 
 Cc: b...@benjojo.co.uk 
 Subject: Possible DigiCert in-addr.arpa Mis-issuance

 Hello dev.security.policy


 Apologies if I have made any mistakes in how I post, this is my first
 time posting here. Anyway:


 I have managed to issue a certificate with a FQDN in the SAN that I do
 not have control of via Digicert.


 The precert is here: https://crt.sh/?id=1231411316

 SHA256:
 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


 I have notified Digicert who responded back with a generic response
 followed by the certificate being revoked through OCSP. However I
 believe that this should be wider investigated, since this cert was
 issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
 that I do control though reverse DNS.


 When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
 that the whole of in-addr.arpa became validated on my account, instead
 of just my small section of it (168.110.79.in-addr.arpa at best).


 To test if digicert had just in fact mis-validated a FQDN, I
 tested with
 the reverse DNS address of 192.168.1.1, and it worked and Digicert
 issued me a certificate with 1.1.168.192.in-addr.arpa on it.


 Is there anything else dev.security.policy needs to do with this? This
 seems like a clear case of mis issuance. It's also not clear if
 in-addr.arpa should even be issuable.


 I would like to take a moment to thank Ben Cartwright-Cox and
 igloo5
 in pointing out this violation.


 Regards

 Cynthia Revström

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

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Tim Hollebeek via dev-security-policy]

> On 27/02/2019 00:10, Matthew Hardeman wrote:
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
> >
> > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
> > rarely has anything other than PTR and NS records defined.
> >
>
> While there is no current use, and the test below was obviously somewhat
> contrived (and seems to have triggered a different issue), one cannot rule 
> out
> the possibility of a need appearing in the future.

At least the last time this came up a few years ago, there were actually a 
significant number of webservers running under in-addr.arpa, with Comodo and 
LE certificates (as well as a handful of others).  I believe Corey posted a 
list.

Exactly what they were doing there is an open question, and when I asked, no 
one responded.  I'm still very curious as to why some people seem to actually 
be running servers there, or if it's just a side-effect of misconfigured 
CNAMEs causing them to appear to be there, or similar.

-Tim


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: T-Systems invalid SANs

[Jakob Bohm via dev-security-policy]

On 27/02/2019 09:54, michel.lebihan2...@gmail.com wrote:

I also found that certificates that were issued very recently have duplicate 
SANs:
https://crt.sh/?id=1231853308=cablint,x509lint,zlint
https://crt.sh/?id=1226557113=cablint,x509lint,zlint
https://crt.sh/?id=1225737388=cablint,x509lint,zlint



Are duplicate SANs forbidden by any standard? (it's obviously
wasteful, but RFC3280 seems to implicitly allow it).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Ryan Sleevi via dev-security-policy]

On Wed, Feb 27, 2019 at 8:04 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, 26 Feb 2019 17:10:49 -0600
> Matthew Hardeman via dev-security-policy
>  wrote:
>
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> It does feel as though ARPA should consider adding a CAA record to
> in-addr.arpa and similar hierarchies that don't want certificates,
> denying all CAs, as a defence in depth measure.


Alternatively, and perhaps more comprehensively, it may be better to ensure
that those Special Use Domains that are either delegated to or reserved by
IANA or the IESG can only have certificates issued by those respective
organizations.

These are enumerated prosaically at
https://www.iana.org/domains/reserved for those reserved by policy, and
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
is a registry of those reserved by relevant standards.

This approach is already taken with regards to IP addresses, and more
comprehensively avoids ambiguity. It has the benefit of defaulting secure -
by not requiring a domain holder (including IANA) to somehow take special
action to protect existing practice. Should concrete use cases present
themselves - of which BGP is not one (see BGPsec for more details) - then
those can be relaxed on a case by case basis. The .onion Domain is an
example of a pre-existing relaxation.

This would still permit .arpa certificates - specific language would be
needed (and should be done) to either prohibit or apply the same
consistency to as IP certificates - but would otherwise close a class of
“obvious” errors. The suggestion was intentionally not a blanket ban, as
IANA/ICANN does and has obtained legitimate certificates for the example
domains in the past.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: T-Systems invalid SANs

[michel.lebihan2000--- via dev-security-policy]

I also found that certificates that were issued very recently have duplicate 
SANs:
https://crt.sh/?id=1231853308=cablint,x509lint,zlint
https://crt.sh/?id=1226557113=cablint,x509lint,zlint
https://crt.sh/?id=1225737388=cablint,x509lint,zlint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CFCA certificate with invalid domain

[michel.lebihan2000--- via dev-security-policy]

Hello,

I noticed this certificate 
https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an invalid 
domain `mail.xinhua08.con` in SANs. This looks like a typo and 
`mail.xinhua08.com` is present in other certificates. Such an issue makes me 
wonder about the quality of their validation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA ownership checking [DarkMatter Concerns]

[Jakob Bohm via dev-security-policy]

On 27/02/2019 01:31, Matthew Hardeman wrote:
> I'd like to take a moment to point out that determination of the beneficial
> ownership of business of various sorts (including CAs) can, in quite a
> number of jurisdictions, be difficult to impossible (short of initiating
> adverse legal proceedings) to determine.
> 
> What does this mean for Mozilla's trusted root program or any other root
> program for that matter?  I submit that it means that anyone rarely knows
> to a certainty the nature and extent of ownership and control over a given
> business to a high degree of confidence.  This is especially true when you
> start divorcing equity interest from right of control.  (Famous example,
> Zuckerberg's overall ownership of Facebook is noted at less than 30% of the
> company, yet he ultimately has personal control of more than 70% of voting
> rights over the company, the end result is that he ultimately can control
> the company and its operations in virtually any respect.)
> 
> A number of jurisdictions allow for creating of trusts, etc, for which the
> ownership and control information is not made public.  Several of those, in
> turn, can each be owners of an otherwise normal looking LLC in an innocuous
> jurisdiction elsewhere, each holding say, 10% equity and voting rights.
> Say there are 6 of those.  Well, all six of them can ultimately be proxies
> for the same hidden partner or entity.  And that partner/entity would
> secretly be in full control.  Without insider help, it would be very
> difficult to determine who that hidden party is.
> 

While the ability to adversely extract such information for random 
companies is indeed limited by various concerns (including the privacy 
of charity activists and small business owners), the ability to get 
this information willingly as audited facts is very common, and is 
something that (non-technical) auditors are well accustomed to doing.

Thus root programs could easily request that information about 
beneficial ownership etc. be included as fully audited facts in future 
audit summary letters.  Subject to an appropriate launch date so CAs and 
auditors can include the needed billable work in their WebTrust audit 
pricing, and actually perform this work (typically by sending relevant 
people from their business auditing sister operations to do this properly).

> Having said all of this, I do have a point relevant to the current case.
> Any entity already operating a WebPKI trusted root signed SubCA should be
> presumed to have all the access to the professionals and capital needed to
> create a new CA operation with cleverly obscured ownership and corporate
> governance.  You probably can not "fix" this via any mechanism.
> 
> In a sense, that DarkMatter isn't trying to create a new CA out of the
> blue, operated and controlled by them or their ultimate ownership but
> rather is being transparent about who they are is interesting.
> 
> One presumes they would expect to get caught at misissuance.  The record of
> noncompliance and misissuance bugs created, investigated, and resolved one
> way or another demonstrates quite clearly that over the history of the
> program a non-compliant CA has never been more likely to get caught and
> dealt with than they are today.
> 

- - - -

> I believe the root programs should require a list of human names with
> verifiable identities and corresponding signed declarations of all
> management and technical staff with privileged access to keys or ability to
> process signing transactions outside the normal flow.  Each of those people
> should agree to a life-long ban from trusted CAs should they be shown to
> take intentional action to produce certificates which would violate the
> rules, lead to MITM, etc.  Those people should get a free pass if they
> whistle blow immediately upon being forced, or ideally immediately
> beforehand as they hand privilege and control to someone else.
> 
> While it is unreasonable to expect to be able to track beneficial
> ownership, formal commitments from the entity and the individuals involved
> in day to day management and operations would lead to a strong assertion of
> accountable individuals whose cooperation would be required in order to
> create/provide a bad certificate.  And those individuals could have "skin
> in the game" -- the threat of never again being able to work for any CA
> that wants to remain in the trusted root programs.
> 

This proposal is disastrously bad and needs to be publicly dispelled 
by the root program administrators as quickly as possible for the 
following reasons:

1. Punishing all CA operations experts that worked at a failed CA by 
  making them essentially unemployable for the failures of their 
  (former) boss is unjust in principle.

2. If there is even a hint that such a policy may be imposed, every 
  key holding CA employee at every CA will be under duress (by the 
  root programs) to hide all problems at their CA and defend every 
  bad decision 

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Nick Lamb via dev-security-policy]

On Tue, 26 Feb 2019 17:10:49 -0600
Matthew Hardeman via dev-security-policy
 wrote:

> Is it even proper to have a SAN dnsName in in-addr.arpa ever?

It does feel as though ARPA should consider adding a CAA record to
in-addr.arpa and similar hierarchies that don't want certificates,
denying all CAs, as a defence in depth measure.

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

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Jakob Bohm via dev-security-policy]

On 27/02/2019 00:10, Matthew Hardeman wrote:

Is it even proper to have a SAN dnsName in in-addr.arpa ever?

While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it rarely
has anything other than PTR and NS records defined.



While there is no current use, and the test below was obviously
somewhat contrived (and seems to have triggered a different issue),
one cannot rule out the possibility of a need appearing in the
future.

One hypothetical use would be to secure BGP traffic, as certificates
with IpAddress SANs are less commonly supported.



Here this was clearly achieved by creating a CNAME record for
69.168.110.79.in-addr.arpa pointed to cynthia.re.

I've never seen any software or documentation anywhere attempting to
utilize a reverse-IP formatted in-addr.arpa address as though it were a
normal host name for resolution.  I wonder whether this isn't a case that
should just be treated as an invalid domain for purposes of SAN dnsName
(like .local).

On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Thanks Cynthia. We are investigating and will report back shortly.

From: dev-security-policy 
on behalf of Cynthia Revström via dev-security-policy <
dev-security-policy@lists.mozilla.org>
Sent: Tuesday, February 26, 2019 12:02:20 PM
To: dev-security-policy@lists.mozilla.org
Cc: b...@benjojo.co.uk
Subject: Possible DigiCert in-addr.arpa Mis-issuance

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first
time posting here. Anyway:


I have managed to issue a certificate with a FQDN in the SAN that I do
not have control of via Digicert.


The precert is here: https://crt.sh/?id=1231411316

SHA256: 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response
followed by the certificate being revoked through OCSP. However I
believe that this should be wider investigated, since this cert was
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
that I do control though reverse DNS.


When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
that the whole of in-addr.arpa became validated on my account, instead
of just my small section of it (168.110.79.in-addr.arpa at best).


To test if digicert had just in fact mis-validated a FQDN, I tested with
the reverse DNS address of 192.168.1.1, and it worked and Digicert
issued me a certificate with 1.1.168.192.in-addr.arpa on it.


Is there anything else dev.security.policy needs to do with this? This
seems like a clear case of mis issuance. It's also not clear if
in-addr.arpa should even be issuable.


I would like to take a moment to thank Ben Cartwright-Cox and igloo5
in pointing out this violation.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Alex Gaynor via dev-security-policy]

(Writing in my personal capacity)

On Tue, Feb 26, 2019 at 7:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
[...]

> All of Google, Amazon, and Microsoft are in the program.  All of these have
> or had significant business with at least the US DOD and have a significant
> core of managing executives as well as operations staff and assets in the
> United States.  As such, it is beyond dispute that each of these is
> subordinate to the laws and demands of the US Government.  Still, none of
> these stand accused of using their publicly trusted root CAs to issue
> certificates to a nefarious end.  It seems that no one can demonstrate that
> DarkMatter has or would either.  If so, no one has provided any evidence of
> that here.
>
>
>
I don't think this is well reasoned. There's several things going on here.
First, the United States government's sovereign jurisdiction has nothing to
do with any of these companies' business relationship with it. All would be
subject to various administrative and judicial procedures in any event.
Probably most relevantly, the All Writs Act (see; Apple vs FBI) -- although
it's not at all clear that it would extend to a court being able to compel
a CA to misissue. (Before someone jumps in to say "National Security
Letter", you should probably know that an NSL is an administrative subpoena
for a few specific pieces of a non-content metadata, not a magic catch all.
https://www.law.cornell.edu/uscode/text/18/2709). Again, none of which is
impacted by these company's being government contractors.

Finally, I think there's a point that is very much being stepped around
here. The United States Government, including its intelligence services,
operate under the rule of law, it is governed by both domestic and
international law, and various oversight functions. It is ultimately
accountable to elected political leadership, who are accountable to a
democracy. The same cannot be said of the UAE, which is an autocratic
monarchy. Its intelligence services are not constrained by the rule of law,
and I think you see this reflected in the targetting of surveillance
described in the Reuters article: journalists, human rights activists,
political rivals.

While it can be very tempting to lump all governments, and particularly all
intelligence services, into one bucket, I think it's important we consider
the variety of different ways such services can function.

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

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Folks,
 
I want to thank Ryan for sharing the relevant discussion history regarding the 
change that precipitated the current language for serialNumber entropy in the 
BRs. Based on this background, it is clear to DM what is required for expected 
compliance with this control and that this was unilaterally applied across all 
CAs. (I will save the discussion for when we should take the BRs at face value 
and when we must delve into the history of each specific ballot precipitating a 
change to another time – this is a potentially difficult challenge for newly 
applying members who do not have the benefit of a history of participation to 
fall back on).
 
DM has already committed to updating our platform with double the required 
entropy for serialNumber as soon as practically possible. We have determined 
that with the help of our vendor, we can achieve this within the next 24 hours.
DM has currently stopped issuance of any public trust TLS certificates until 
the serialNumber entropy is updated. DM has compiled a list of all certificates 
issued that are still valid and have a 64-bit serialNumber. We have begun 
contacting each certificate owner to advise them that their certificate will be 
revoked within 24 hrs, and that DM will provide a replacement cert for them.
A challenge we face is that it is end of day Wednesday here, and Thursday is 
the end of the Work Week in UAE. It may not be possible to contact all 
certificate admins in the next 24 hours, and scheduling emergency updates in 
infrastructures at short notice may have a low probability of success. Since 
the vulnerability associated with the entropy of serialNumber I believe should 
only manifest during issuance and not for operation of the certificates, we may 
potentially hold off revoking the affected certificate until the appropriate 
admin can be reached so as to minimize risk to our customers and their 
services. We expect the majority of active certificates to be replaced within 
24 hours as required, and will inform the Group if there are any outstanding 
revocations that do not meet this timeline.
 
In terms of our Root submission to Mozilla (and other browsers) we will need to 
re-engage our WebTrust Auditors to be present before replacement hierarchies 
can be established. This may take up to a couple of weeks. Updated hierarchies 
will be resubmitted to the root inclusion process once they are available.

Further, we will post a bug report to capture these actions and subsequent 
updates.


Regards,
 

-- 

Scott Rea

On 2/27/19, 11:55 AM, "dev-security-policy on behalf of Ryan Sleevi via 
dev-security-policy"  wrote:

As Matthew highlights, this is not a new or novel interpretation.

It was introduced in Ballot 164 -
https://cabforum.org/2016/03/31/ballot-164/

The first discussion of this in the CA/B Forum as a Ballot was
https://cabforum.org/pipermail/public/2016-February/006893.html . This
discussion continues through June of that year, when it went to a vote.

During those discussions, there were concerns raised regarding entropy -
which, admittedly, I raised initially, but you can see others sharing
similar concerns. You can also see, however, in the discussions of GUIDs
how those concerns turned out to be well-founded.

Indeed, if you go to April,
https://cabforum.org/pipermail/public/2016-April/007245.html , you can find
discussion about how the maximum legally possible entropy was 159 bits,
precisely for the reason we’re discussing.

While Scott’s proposed language (“entropy”) has problems that the Forum
discussed rather extensively, as to why it would be problematic, the
question of the high but was also discussed during the ballot process. I
believe the conclusion from that discussion was that it would be unlikely
for CAs to rest on exactly 64-bit serials, as they would be able to avoid
any ambiguity or confusion by simply increasing the serial number space
(say, to 65 bits).

Following this ballot, subsequent discussion was had regarding some CAs
that included serials of exactly 64 bits, and how those could not be
compliant.

https://groups.google.com/forum/m/#!msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
is such an example.

On Wed, Feb 27, 2019 at 12:15 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The issue I see with that interpretation is that the very same matter has
> previously been discussed on this list and resolved quite vocally in the
> favor of the other position: that making careful choices about the CSPRNG
> output to conform it to mask out the high order bit makes the output of at
> least that bit not truly the output of the CSPRNG but rather the output of
> the mask.
>
> Pedantically speaking, I actually favor your analysis.  But that probably
> will do you 

Re: DarkMatter Concerns

[tomasshredder--- via dev-security-policy]

> (Sorry for continuing this off-topic thread.)
> 
> Hello Tomas,
> 
> I hope this is indeed not your current implementation and that it wasn’t in 
> use anymore when ballot 164 became effective, because that’s not safe:

I tried to say so in my original post, but I see I was not very clear.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Peter Gutmann via dev-security-policy]

tomasshredder--- via dev-security-policy 
 writes:

>We still get asked by customers to implement sequential serial numbers from
>time to time, but it's getting more and more rare.

Another reason for using random data, from the point of view of a software
toolkit provider, is that it's the only thing you can guarantee is unique in a
cert since there's no coordination between users over namespace use.  A user
can configure their software or CA to have any name they like, and for small-
scale use that's often the case, "Web CA" or something similar.  By providing
an unlikely-to-be-duplicated random value as the serial number, you don't run
into problems with Web CA #1's certs clashing with Web CA #2's certs.

In terms of sequential numbers, if for some reason the current serial number
isn't written to permanent storage correctly, or there's a system failure and
when things are restored the record of the last-used serial number is lost or
corrupted, you're in trouble.  So overall it just made more sense to use
random values.

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

Re: DarkMatter Concerns

[Thijs Alkemade via dev-security-policy]

On 27 Feb 2019, at 09:07, tomasshredder--- via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
Mike Kushner via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 writes:

EJBCA was possible the first (certainly one of the first) CA products to use
random serial numbers.

Random serial numbers have been in use for a long, long time, principally to
hide the number of certs a CA was (or wasn't) issuing.  Here's the first one
that came up in my collection, from twenty-five years ago:

Thanks Peter, you have an impressive collection (no irony, it is really cool!).
We still get asked by customers to implement sequential serial numbers from 
time to time, but it's getting more and more rare.


RFC 3280 (2002) explicitly added handling for random data as serial numbers:

Ha, we were way before RFC3280 :-). Just being geeky, here is the code from 
EJBCA 1.0 (2001-12-05). CSPRNG, although it was seeded differently at that time 
(setSeed complements not replaces self-seeding in SecureRandom).

 random = SecureRandom.getInstance("SHA1PRNG");
 random.setSeed((long)(new Date().getTime()));
 byte[] serno = new byte[8];
 random.nextBytes(serno);

(https://sourceforge.net/projects/ejbca/files/ejbca1/ejbca-1_0/)

(Sorry for continuing this off-topic thread.)

Hello Tomas,

I hope this is indeed not your current implementation and that it wasn’t in use 
anymore when ballot 164 became effective, because that’s not safe:

https://stackoverflow.com/a/27301156
https://android-developers.googleblog.com/2016/06/security-crypto-provider-deprecated-in.html

> You should never call setSeed before retrieving data from the "SHA1PRNG" in 
> the SUN provider as that will make your RNG (Random Number Generator) into a 
> Deterministic RNG - it will only use the given seed instead of adding the 
> seed to the state. In other words, it will always generate the same stream of 
> pseudo random bits or values.

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

Re: DarkMatter Concerns

[tomasshredder--- via dev-security-policy]

On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
> Mike Kushner via dev-security-policy  
> writes:
> 
> >EJBCA was possible the first (certainly one of the first) CA products to use
> >random serial numbers.
> 
> Random serial numbers have been in use for a long, long time, principally to
> hide the number of certs a CA was (or wasn't) issuing.  Here's the first one
> that came up in my collection, from twenty-five years ago:

Thanks Peter, you have an impressive collection (no irony, it is really cool!).
We still get asked by customers to implement sequential serial numbers from 
time to time, but it's getting more and more rare.

> 
> RFC 3280 (2002) explicitly added handling for random data as serial numbers:

Ha, we were way before RFC3280 :-). Just being geeky, here is the code from 
EJBCA 1.0 (2001-12-05). CSPRNG, although it was seeded differently at that time 
(setSeed complements not replaces self-seeding in SecureRandom).

  random = SecureRandom.getInstance("SHA1PRNG");
  random.setSeed((long)(new Date().getTime()));
  byte[] serno = new byte[8];
  random.nextBytes(serno);

(https://sourceforge.net/projects/ejbca/files/ejbca1/ejbca-1_0/)

>Given the uniqueness requirements above, serial numbers can be
>expected to contain long integers.  Certificate users MUST be able to
>handle serialNumber values up to 20 octets. 

I know it's rare, but we've had clients with devices that can not handle more 
than 32 bits. Not WebPKI of course... Your X509 Style Guide is still a classic 
read btw.
 
> (20 bytes being a SHA-1 hash, which was the fashion at the time).

You make a good point there. The mere size of the serial number doesn't say 
much about the entropy. The auditor has to dig into the details.

Cheers,
Tomas

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