Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Friday, March 15, 2019 at 12:53:15 PM UTC-7, Daymion Reynolds wrote:
> On Friday, March 15, 2019 at 12:45:39 PM UTC-7, Ryan Sleevi wrote:
> > On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > 
> > > > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds 
> > > > wrote:
> > > >
> > > > > In accordance with our conversations to date, prior to 3/7 6:30pm AZ
> > > we utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > > checks. This new understanding of the rules calls for us to modify our
> > > original disclosure to 0 affected certificates.
> > >
> > > Please read through earlier posts discussing this.
> > >
> > 
> > Daymion,
> > 
> > I was hoping you could respond more. I think based on the discussion on the
> > list to date, it's actually not clear that GoDaddy was compliant (as noted
> > in [1]), and Adam's response seems to support that.
> > 
> > A filtering algorithm that "returns 64 random bits from a CSPRNG with at
> > least one bit in the highest byte set to 1" is fairly ambiguous. If you're
> > returning 64 random bits AND a byte with at least one bit set to one,
> > that's different than returning 64 random bits and discarding values which
> > don't have a bit in the high byte set to one.
> > 
> > [1]
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/ydp17Nz7BgAJ
> > 
> > [2]
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ
> 
> 
> I am investigating as it does not match my understanding.

The timeline does match expectation. 
When the 64bit issue was escalated, GoDaddy decided to apply a fix on 3/7 to 
meet our BR interpretation of certificate must be “containing at least 64 bits 
of OUTPUT”. The fastest change was to set a minimum value. This is the source 
of the most significant bit you are referencing.
https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/F8AS4MNVCAAJ
 

On 3/12 we discussed what 64bits meant[1], had agreement from Ryan Sleevi[2] 
any most significant bit would be acceptable. We made the change later that 
same day to the described configuration. 
[1=https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ
 
[2]https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/HeCLu1rzBgAJ
 

Lastly, it was identified\discussed since we were STARTING with 64bits it was 
acceptable. Therefore, GoDaddy was in compliance prior to 3/7.  After this 
discussion we changed back to the pre 3/7 configuration on 3/13.
https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/vqt_XWX6CgAJ
 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Friday, March 15, 2019 at 12:45:39 PM UTC-7, Ryan Sleevi wrote:
> On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> > >
> > > > In accordance with our conversations to date, prior to 3/7 6:30pm AZ
> > we utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > checks. This new understanding of the rules calls for us to modify our
> > original disclosure to 0 affected certificates.
> >
> > Please read through earlier posts discussing this.
> >
> 
> Daymion,
> 
> I was hoping you could respond more. I think based on the discussion on the
> list to date, it's actually not clear that GoDaddy was compliant (as noted
> in [1]), and Adam's response seems to support that.
> 
> A filtering algorithm that "returns 64 random bits from a CSPRNG with at
> least one bit in the highest byte set to 1" is fairly ambiguous. If you're
> returning 64 random bits AND a byte with at least one bit set to one,
> that's different than returning 64 random bits and discarding values which
> don't have a bit in the high byte set to one.
> 
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/ydp17Nz7BgAJ
> 
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ


I am investigating as it does not match my understanding.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Friday, March 15, 2019 at 12:35:47 PM UTC-7, Daymion Reynolds wrote:
> On Friday, March 15, 2019 at 12:25:37 PM UTC-7, ad...@adamcaudill.com wrote:
> > Daymion,
> > 
> > (Apologies in advance if I've missed something that led to these results. 
> > These results rely on the crt.sh database, which I will admit to being less 
> > familiar with than I would like.)
> > 
> > While recently looking at some randomly selected recent certificates from 
> > this CA: https://crt.sh/?CAID=904, I noticed that it seemed that all had 
> > serial numbers with the high bit set. This being unlikely, I took advantage 
> > of the fact that crt.sh allows direct database access to get some more data 
> > - and it looks like for several days, the certificates logged did indeed 
> > have the high bit set in the serial number.
> > 
> > For certificates with a notBefore of 2019-03-07 22:52:51 to 2019-03-13 
> > 02:01:15, it appears that all certificates had a serial number with the 
> > high bit set; there are a little under 100,000 entries in the crt.sh 
> > database with notBefore between those dates, all appear to be encoded to 9 
> > bytes and with the high bit set.
> > 
> > For certificates with notBefore of 2019-03-13 02:01:16 and later, it 
> > appears that the distribution returns to what would be expected based on 
> > the selection criteria described.
> > 
> > The odds of this happening by random chance being extremely remote - this 
> > seems to indicate that there may have been an issue (and a loss of entropy).
> > 
> > The data was pulled from the public crt.sh database, one day at a time, 
> > using the following query:
> > 
> > select
> >   c.id,
> >   x509_notBefore(c.CERTIFICATE),
> >   x509_serialNumber(c.CERTIFICATE)
> > from certificate c
> > where
> >   c.issuer_ca_id = 904
> >   and x509_notBefore(c.CERTIFICATE) between '2019-03-08'::date and 
> > '2019-03-09'::date
> > limit 10;
> > 
> > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> > 
> > > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we 
> > > utilized raw 64 bit output from CSPRING, with uniqueness and non zero 
> > > checks. This new understanding of the rules calls for us to modify our 
> > > original disclosure to 0 affected certificates.
> 
> Please read through earlier posts discussing this.

I believe I hit reply to soon, as you are referencing something else. Will look 
into this.

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Friday, March 15, 2019 at 12:25:37 PM UTC-7, ad...@adamcaudill.com wrote:
> Daymion,
> 
> (Apologies in advance if I've missed something that led to these results. 
> These results rely on the crt.sh database, which I will admit to being less 
> familiar with than I would like.)
> 
> While recently looking at some randomly selected recent certificates from 
> this CA: https://crt.sh/?CAID=904, I noticed that it seemed that all had 
> serial numbers with the high bit set. This being unlikely, I took advantage 
> of the fact that crt.sh allows direct database access to get some more data - 
> and it looks like for several days, the certificates logged did indeed have 
> the high bit set in the serial number.
> 
> For certificates with a notBefore of 2019-03-07 22:52:51 to 2019-03-13 
> 02:01:15, it appears that all certificates had a serial number with the high 
> bit set; there are a little under 100,000 entries in the crt.sh database with 
> notBefore between those dates, all appear to be encoded to 9 bytes and with 
> the high bit set.
> 
> For certificates with notBefore of 2019-03-13 02:01:16 and later, it appears 
> that the distribution returns to what would be expected based on the 
> selection criteria described.
> 
> The odds of this happening by random chance being extremely remote - this 
> seems to indicate that there may have been an issue (and a loss of entropy).
> 
> The data was pulled from the public crt.sh database, one day at a time, using 
> the following query:
> 
> select
>   c.id,
>   x509_notBefore(c.CERTIFICATE),
>   x509_serialNumber(c.CERTIFICATE)
> from certificate c
> where
>   c.issuer_ca_id = 904
>   and x509_notBefore(c.CERTIFICATE) between '2019-03-08'::date and 
> '2019-03-09'::date
> limit 10;
> 
> On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> 
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we 
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero 
> > checks. This new understanding of the rules calls for us to modify our 
> > original disclosure to 0 affected certificates.

Please read through earlier posts discussing this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Thursday, March 14, 2019 at 3:13:51 PM UTC-7, Jaime Hablutzel wrote:
> > 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a
> > CSPRNG with at least one bit in the highest byte set to 1
> > 
> > is, strictly speaking, not true. The best possible implementation for
> > GetRandom64Bits(), as described, only returns 63.994353 bits of entropy,
> > not 64.
> > 
> 
> Can you share how did you get the previous 63.994353?.
> 
> I'm trying the following and I'm getting a different value:
> 
> a = 2^64 = 18446744073709551616
> b = 0x80 = 36028797018963968
> 
> (a - b) / a * 64 = 63.875
> 
> Maybe I'm misunderstanding something.

That post was for after 3/7. We were fine all along.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Thursday, March 7, 2019 at 7:01:41 PM UTC-7, Daymion Reynolds wrote:
> As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate 
> Serial Number issue. We have identified a significant quantity of 
> certificates (> 1.8million) not meeting the 64bit serial number requirement. 
> We are still performing accounting so certificate quantity is expected to 
> change before we finalize the report. 
>  
> 1.How your CA first became aware of the problem (e.g. via a problem 
> report submitted to your Problem Reporting Mechanism, a discussion in 
> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
> time and date.
>  
> 9pm 3/6/2019 AZ Time, due to reviewing a discussion in 
> mozilla.dev.security.policy.
>  
> 2.A timeline of the actions your CA took in response. A timeline is a 
> date-and-time-stamped sequence of all relevant events. This may include 
> events before the incident was reported, such as when a particular 
> requirement became applicable, or a document changed, or a bug was 
> introduced, or an audit was done.
>  
> 9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in Mozilla 
> group. 
> 10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified 
> root cause.
> 6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial 
> number issue.
> We are still quantifying and classifying the certificate scope of impact. 
>  
> 3.Whether your CA has stopped, or has not yet stopped, issuing 
> certificates with the problem. A statement that you have will be considered a 
> pledge to the community; a statement that you have not requires an 
> explanation.
>  
> We have deployed a fix to the issue, and are no longer issuing certificates 
> with the defect. 
>  
> 4.A summary of the problematic certificates. For each problem: number of 
> certs, and the date the first and last certs with that problem were issued.
>  
> Issue was introduced with a change in 2016. Impacted certificates still being 
> aggregated. Will update with information and timeline on issue closure.
>  
> 5.The complete certificate data for the problematic certificates. The 
> recommended way to provide this is to ensure each certificate is logged to CT 
> and then list the fingerprints or crt.sh IDs, either in the report or as an 
> attached spreadsheet, with one list per distinct problem.
>  
> Still being aggregated. Will update with certificate information on issue 
> closure.
>  
> 6.Explanation about how and why the mistakes were made or bugs 
> introduced, and how they avoided detection until now.
>  
> Ambiguity in language led to different interpretations of BR 7.1. It was 
> believed a unsigned 64bit integer was sufficient to satisfy the new 
> requirement. Additionally, industry tools like CABLint/ZLint were not 
> catching this issue, which provided a false sense of compliance. We are 
> submitting CABLint/Zlint updates as part of the fix. 
>  
> 7.List of steps your CA is taking to resolve the situation and ensure 
> such issuance will not be repeated in the future, accompanied with a timeline 
> of when your CA expects to accomplish these things.
>  
> Defect has been resolved, we are also updating linting tools (CABLint/Zlint) 
> and upstreaming to patch for other peoples usage.

In accordance with our conversations to date, prior to 3/7 6:30pm AZ we 
utilized raw 64 bit output from CSPRING, with uniqueness and non zero checks. 
This new understanding of the rules calls for us to modify our original 
disclosure to 0 affected certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Tuesday, March 12, 2019 at 11:32:38 AM UTC-7, Ryan Sleevi wrote:
> On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > The crux of the difference is in the DER format interpretation. The fact
> > prefix (0)s do count for entropy, provided none of the bits are fixed and
> > you have a minimum of 8 bytes in the serial. We discuss this in the Mozilla
> > post on 3/11/2019.
> >
> > For the DER format the first two (0)s of the value is the positive sign of
> > the integer. In our case if the un-signed integer value is 64bit and the
> > most significant bit is set, two additional (0)s will be prepended to
> > demonstrate a positive sign. In this case it will be 9bytes instead of
> > 8bytes. Always a minimum of 8bytes (64bits) of entropy. You do still have
> > to manage zero compression for integer values less than 72057594037927936,
> > which will result in 7bytes instead of 8bytes.
> >
> 
> Just making sure I've got the right message - this is
> https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/9OKbI4xyCQAJ
> correct?
> 
> If viewing through groups' interface, you can click the arrow for "More
> Message Actions" to copy link.
> 
> To make sure I understand correctly, the statement is that GoDaddy
> generated 64 bits of entropy prior to DER encoding. This resulted in some
> serials that are exactly 8 octets (or even less, depending on leading zeros
> and minimal encoding) and some serials that are 9 or more octets.
> 
> The reduction from >1.8M certificates to 12K certificates is a statement
> that only those 12K certificates lacked a 64-bit entropy contribution? And
> possibly 273K certificates which GoDaddy does not consider issued, but
> otherwise made committments to issue (such as logging a pre-cert)?
> 
> To provide greater clarity about this incident, could you more fully
> describe your serial number generation algorithm (potentially including
> code or pseudo-code) that can help demonstrate how this system was
> compliant?

It is an accurate statement to say that GoDaddy generates 64 full bits of 
entropy prior to the DER encoding.  When these 64 bits are DER encoded, the 
result is either 8 or 9 octets written into the cert, depending on whether or 
not the most significant bit is a 0 (8 octets) or 1 (9 octets).  In the case of 
9 octets being written, the first octet is always “00” signifying the integer 
value is positive.  It is worth noting:  whether that extra “00” octet is 
present or not, there are always 64 randomly generated bits providing the 
needed entropy. 

RS - The reduction from >1.8M certificates to 12K certificates is a statement 
that only those 12K certificates lacked a 64-bit entropy contribution? 
DR – Yes, the 12k certs are only 7bytes or less and therefor do not meet the 
BRs. 

RS - possibly 273K certificates which GoDaddy does not consider issued, but 
otherwise made commitments to issue (such as logging a pre-cert)?
DR - Yes, in most cases we logged a pre-cert prior to final issuance and 
turnover to the requested. We want to start revoking these certificates as they 
should be disposed of if not fully issued. 


64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a CSPRNG 
with at least one bit in the highest byte set to 1
CheckForDuplicate(64bits_entropy)//Verifies the serial is unique, otherwise 
repeat GetRandom64Bits()
Cert.SetSerialNumber(64bits_entropy) //The ANS.1 encoding will either write 
this number as 8 or 9 octets.  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

On Tuesday, March 12, 2019 at 9:54:56 AM UTC-7, ad...@adamcaudill.com wrote:
> Daymion,
> 
> You linked to a thread in m.d.s.p and cited it as confirming a specific 
> interpretation of 7.1 - as that's a long thread (with some possible 
> questionable information), could you possibly share what criteria you used to 
> determine what certificates were impacted by this issue and which ones were 
> not? Seeing a reduction from >1.8M to 12k is a substantial difference, and 
> thus is bound to make participants curious.
> 
> I think that would be very helpful to ensure that everyone is on the same 
> page about what is and isn't compliant with 7.1.
> 
> Thanks
> 
> On Tuesday, March 12, 2019 at 12:28:11 PM UTC-4, Daymion Reynolds wrote:
> > As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate 
> > Serial Number issue. Due to a m.d.s.p.[1] discussion validating an 
> > interpretation of BR 7.1 our revised count is approximately 12,152 live 
> > certificates not meeting the 64bit serial number requirement.  
> > Additionally, we have identified 273,784 “orphaned” certificates meeting 
> > the initial interpretation of BR 7.1. Orphaned certificates are certs, 
> > which were stopped mid-issuance due to a variety of reasons like requestor 
> > cancellation, system errors etc. These certs are most often 
> > pre-certificates, but some are leaf-certificates, which were logged to CT, 
> > but never received by the certificate requestor. 
> > ...
> > [1] 
> > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/7WuWS_20758


The crux of the difference is in the DER format interpretation. The fact prefix 
(0)s do count for entropy, provided none of the bits are fixed and you have a 
minimum of 8 bytes in the serial. We discuss this in the Mozilla post on 
3/11/2019.

For the DER format the first two (0)s of the value is the positive sign of the 
integer. In our case if the un-signed integer value is 64bit and the most 
significant bit is set, two additional (0)s will be prepended to demonstrate a 
positive sign. In this case it will be 9bytes instead of 8bytes. Always a 
minimum of 8bytes (64bits) of entropy. You do still have to manage zero 
compression for integer values less than 72057594037927936, which will result 
in 7bytes instead of 8bytes.

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

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate 
Serial Number issue. Due to a m.d.s.p.[1] discussion validating an 
interpretation of BR 7.1 our revised count is approximately 12,152 live 
certificates not meeting the 64bit serial number requirement.  Additionally, we 
have identified 273,784 “orphaned” certificates meeting the initial 
interpretation of BR 7.1. Orphaned certificates are certs, which were stopped 
mid-issuance due to a variety of reasons like requestor cancellation, system 
errors etc. These certs are most often pre-certificates, but some are 
leaf-certificates, which were logged to CT, but never received by the 
certificate requestor. 

The initial report stated >1.8 million certificates were impacted. For our 
initial investigation we checked certs against the first bit being set, which 
seemed to be the industry interpretation at the time. This lead to more 
aggressive criteria than necessary. As we started revocations of orphan 
certificates we continued researching the criteria defined by BR7.1 After 
re-evaluating the criteria, per m.d.s.p.[1], we adjusted our certificate scope. 
  
1.How your CA first became aware of the problem (e.g. via a problem 
report submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date. 
  
9pm 3/6/2019 AZ Time, due to reviewing a discussion in 
mozilla.dev.security.policy. 
  
2.A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done. 
  
9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in Mozilla 
group. 
10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified root 
cause. 
6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial 
number issue.
2pm 3/9/2019 AZ Time, we revoked 273,784 orphaned, pre-certs and leaf 
certificates which met the initial criteria. These certificates were low\no 
risk as they were never distributed.
11pm 3/11/2019 AZ Time, defined resolution as stated in m.d.s.p., further 
research revised the quantity of impacted certificates.
3/12 – 3/16 – We will be revoking the before mentioned 12,152 live certificates.
Once the revocation is complete we will update this timeline.
  
3.Whether your CA has stopped, or has not yet stopped, issuing 
certificates with the problem. A statement that you have will be considered a 
pledge to the community; a statement that you have not requires an explanation. 
  
We have deployed a fix to the issue on 3/7/2019, and are no longer issuing 
certificates with the defect. 
  
4.A summary of the problematic certificates. For each problem: number 
of certs, and the date the first and last certs with that problem were issued. 
  
12,134 certificates were affected.  
Revoking as a precaution, certificates issued on 9/29/2016 
9/29/2016 2:41 66269447367104810
9/29/2016 7:44 35092532380173749
9/29/2016 9:46 43324527254073466
9/29/2016 14:16 53640950198707040
9/29/2016 14:31 36562688867169546

The first affected certificate was issued on 9/30/2016 1:29 
https://crt.sh/?id=290271291 
The last affected certificate was issued on 3/7/2019 15:32 
https://crt.sh/?id=1262876175 


  
5.The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem. 
  
Spreadsheet attached to defect.  Older certificates may not yet be CT logged, 
as the majority of the certs are DV. 
  
6.Explanation about how and why the mistakes were made or bugs 
introduced, and how they avoided detection until now. 
  
Ambiguity in language led to different interpretations of BR 7.1 in 2016. It 
was believed an unsigned 64bit integer was sufficient to satisfy the new 
requirement. Additionally, industry tools like CABLint/ZLint were not catching 
this issue, which provided a false sense of compliance. We are submitting 
CABLint/Zlint updates as part of the fix. 
  
7.List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things. 
  
Defect has been resolved, we are also updating linting tools (CABLint/Zlint) 
and upstreaming to patch for other peoples usage.
Additionally, we are looking to scope and roadmap upgrading our certificate 
serial number to a minimum of 128-bit, or the max possible. 
[1] 
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/7WuWS_20758

Re: EJBCA defaulting to 63 bit serial numbers

[Daymion Reynolds via dev-security-policy]

On Monday, March 11, 2019 at 8:57:27 AM UTC-7, Ryan Sleevi wrote:
> I don’t think there’s anything inherently wrong with an approach that uses
> a fixed prefix, whether of one bit or more, provided that there is at least
> 64 bits of entropy included in the serial prior to encoding to DER.
> 
> This means a scheme with guarantees a positive INTEGER will generate
> *encoded* serials in the range of one bit to sixty five bits, of the goal
> is to use the smallest possible amount of entropy.
> 
> However, as you note, this issue only arises when one uses the absolute
> minimum. A robust solution is to use 159 bits, the maximum allowed. This
> helps ensure that, even when encoded, it will not exceed 20 bytes, this
> avoiding any client interpretation issues regarding whether the 20 bytes
> mentioned in 5280 are pre-encoding (the intent) or post-encoding (as a few
> embedded libraries implemented).
> 
> Note, however, even with 159 bits of entropy, it’s still possible to have a
> compressed encoding of one byte, due to zero folding. Using a one bit
> prefix in addition to the sign bit (thus, two fixed bits in the serial) can
> help ensure that a leading run of zero bits are not folded when encoding.

Glad you agree 64bit serial numbers can have no fixed bits, as a fixed bit in a 
64 bit serial number would result in less than 64 bits of entropy.  If you are 
going to fix a significant bit it must be beyond the 64th bit.  If your 64 bit 
serial number does not contain 1's in the significant byte, as long as you 
still write 64 full bits of data to the cert with 0's left padded, then the 
desired entropy is achieved and is valid. CAs should keep this in mind while 
building their revocation lists.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: EJBCA defaulting to 63 bit serial numbers

[Daymion Reynolds via dev-security-policy]

On Saturday, March 9, 2019 at 5:15:50 PM UTC-7, Wayne Thayer wrote:
> On Sat, Mar 9, 2019 at 12:49 PM Dimitris Zacharopoulos via
> dev-security-policy  wrote:
> 
> >
> > The question I'm having trouble answering, and I would appreciate if
> > this was answered by the Mozilla CA Certificate Policy Module Owner, is
> >
> > "does Mozilla treat this finding as a violation of the current language
> > of section 7.1 of the CA/B Forum Baseline Requirements"?
> >
> >
> Speaking as the CA Certificate Policy Module Owner, and being aware of the
> discussions that led to the current wording, I believe the intent of the BR
> language is for serial numbers to contain 64-bits of entropy. I certainly
> agree that the language could be improved, but I think the meaning is clear
> enough and yes I do expect CAs to treat serial numbers that do not actually
> consist of 64-bits of entropy as a BR and a Mozilla policy section 5.2
> violation.
> 
> I believe answering this question would bring some clarity to the
> > participating CAs.
> >
> > Thank you for pointing this out Dimitris. While it seems obvious to me, I
> can understand if there is some uncertainty resulting from the opposing
> arguments.
> 
> - Wayne

When it comes entropy how does the industry feel about preceding zeros? There 
have been a few online and offline discussions around the requirement for the 
most significant bit to be set to (1). 

For example:
1000        which 
results in an integer of 9223372036854775808.

In my opinion, to achieve a full 64bits of serial number entropy we should not 
fix any of the bits. What are the thoughts on this?

This following value also has 64bits but does not have the most significant bit 
set yet seems to meet the section 7.1 baseline requirements. 

0001        which 
results in an integer of 72057594037927936.

In both cases the certificate field header lists the length of the serial 
number as 64bits. 

For GoDaddy, we will be moving to 128bit serial numbers to resolve this 
permanently.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

Our goal is to reissue all the certificates within the next 30 days. We have 
started the revocation process. We have a significant number of customers that 
use manual methods for managing their certificates, so being agile for them is 
difficult. We want to keep our customers using https through the entire 
revocation period. Due to the large number of certificates and the benign 
nature of the issue, our plan is to revoke in a responsible way.

Once this is completed, I think we need to get together and have a serious 
discussion around how to handle potential incidents like this in the future. 
Having a discussion about if this is right or wrong in the middle of an 
incident doesn’t help anyone.



On Thursday, March 7, 2019 at 7:01:41 PM UTC-7, Daymion Reynolds wrote:
> As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate 
> Serial Number issue. We have identified a significant quantity of 
> certificates (> 1.8million) not meeting the 64bit serial number requirement. 
> We are still performing accounting so certificate quantity is expected to 
> change before we finalize the report. 
>  
> 1.How your CA first became aware of the problem (e.g. via a problem 
> report submitted to your Problem Reporting Mechanism, a discussion in 
> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
> time and date.
>  
> 9pm 3/6/2019 AZ Time, due to reviewing a discussion in 
> mozilla.dev.security.policy.
>  
> 2.A timeline of the actions your CA took in response. A timeline is a 
> date-and-time-stamped sequence of all relevant events. This may include 
> events before the incident was reported, such as when a particular 
> requirement became applicable, or a document changed, or a bug was 
> introduced, or an audit was done.
>  
> 9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in Mozilla 
> group. 
> 10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified 
> root cause.
> 6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial 
> number issue.
> We are still quantifying and classifying the certificate scope of impact. 
>  
> 3.Whether your CA has stopped, or has not yet stopped, issuing 
> certificates with the problem. A statement that you have will be considered a 
> pledge to the community; a statement that you have not requires an 
> explanation.
>  
> We have deployed a fix to the issue, and are no longer issuing certificates 
> with the defect. 
>  
> 4.A summary of the problematic certificates. For each problem: number of 
> certs, and the date the first and last certs with that problem were issued.
>  
> Issue was introduced with a change in 2016. Impacted certificates still being 
> aggregated. Will update with information and timeline on issue closure.
>  
> 5.The complete certificate data for the problematic certificates. The 
> recommended way to provide this is to ensure each certificate is logged to CT 
> and then list the fingerprints or crt.sh IDs, either in the report or as an 
> attached spreadsheet, with one list per distinct problem.
>  
> Still being aggregated. Will update with certificate information on issue 
> closure.
>  
> 6.Explanation about how and why the mistakes were made or bugs 
> introduced, and how they avoided detection until now.
>  
> Ambiguity in language led to different interpretations of BR 7.1. It was 
> believed a unsigned 64bit integer was sufficient to satisfy the new 
> requirement. Additionally, industry tools like CABLint/ZLint were not 
> catching this issue, which provided a false sense of compliance. We are 
> submitting CABLint/Zlint updates as part of the fix. 
>  
> 7.List of steps your CA is taking to resolve the situation and ensure 
> such issuance will not be repeated in the future, accompanied with a timeline 
> of when your CA expects to accomplish these things.
>  
> Defect has been resolved, we are also updating linting tools (CABLint/Zlint) 
> and upstreaming to patch for other peoples usage.

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

Pre-Incident Report - GoDaddy Serial Number Entropy

[Daymion Reynolds via dev-security-policy]

As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate 
Serial Number issue. We have identified a significant quantity of certificates 
(> 1.8million) not meeting the 64bit serial number requirement. We are still 
performing accounting so certificate quantity is expected to change before we 
finalize the report. 
 
1.  How your CA first became aware of the problem (e.g. via a problem 
report submitted to your Problem Reporting Mechanism, a discussion in 
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the 
time and date.
 
9pm 3/6/2019 AZ Time, due to reviewing a discussion in 
mozilla.dev.security.policy.
 
2.  A timeline of the actions your CA took in response. A timeline is a 
date-and-time-stamped sequence of all relevant events. This may include events 
before the incident was reported, such as when a particular requirement became 
applicable, or a document changed, or a bug was introduced, or an audit was 
done.
 
9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in Mozilla 
group. 
10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified root 
cause.
6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial 
number issue.
We are still quantifying and classifying the certificate scope of impact. 
 
3.  Whether your CA has stopped, or has not yet stopped, issuing 
certificates with the problem. A statement that you have will be considered a 
pledge to the community; a statement that you have not requires an explanation.
 
We have deployed a fix to the issue, and are no longer issuing certificates 
with the defect. 
 
4.  A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.
 
Issue was introduced with a change in 2016. Impacted certificates still being 
aggregated. Will update with information and timeline on issue closure.
 
5.  The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.
 
Still being aggregated. Will update with certificate information on issue 
closure.
 
6.  Explanation about how and why the mistakes were made or bugs 
introduced, and how they avoided detection until now.
 
Ambiguity in language led to different interpretations of BR 7.1. It was 
believed a unsigned 64bit integer was sufficient to satisfy the new 
requirement. Additionally, industry tools like CABLint/ZLint were not catching 
this issue, which provided a false sense of compliance. We are submitting 
CABLint/Zlint updates as part of the fix. 
 
7.  List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future, accompanied with a timeline 
of when your CA expects to accomplish these things.
 
Defect has been resolved, we are also updating linting tools (CABLint/Zlint) 
and upstreaming to patch for other peoples usage. 

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

Re: GoDaddy Revocation Disclosure

[Daymion Reynolds via dev-security-policy]

On Monday, August 20, 2018 at 10:40:15 AM UTC-7, Wayne Thayer wrote:
> Thank you for the disclosure Daymion. I have created bug 1484766 to track
> this issue. I've requested an incident report to help the community better
> understand what happened and what can and is being done to prevent similar
> problems in the future, as described in the last two topics [1]:
> 
> 6. Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now.
> 7. List of steps your CA is taking to resolve the situation and ensure such
> issuance will not be repeated in the future, accompanied with a timeline of
> when your CA expects to accomplish these things.
> 
> - Wayne
> 
> [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
> 
> On Mon, Aug 20, 2018 at 9:26 AM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Saturday, August 18, 2018 at 2:27:05 PM UTC-7, Ben Laurie wrote:
> > > On Fri, 17 Aug 2018 at 18:22, Daymion Reynolds via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > Revoke Disclosure
> > > >
> > > > GoDaddy has been proactively performing self-audits. As part of this
> > > > process, we identified a vulnerability in our code that would allow our
> > > > validation controls to be bypassed. This bug would allow for a Random
> > Value
> > > > that was generated for intended use with Method 3.2.2.4.6 and
> > 3.2.2.4.7 and
> > > > was validated using Method 3.2.2.4.2 by persons who were not confirmed
> > as
> > > > the domain contact. This bug was introduced November 2014 and was
> > leveraged
> > > > to issue a total of 865 certificates. The bug was closed hours after
> > > > identification, and in parallel we started the scope and revocation
> > > > activities.
> > > >
> > > > In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued
> > > > certificates were revoked within 24 hours of identification.
> > > >
> > > > A timeline of the Events for Revocation are as follows:
> > > >
> > > > 8/13 9:30am – Exploit issue surfaced as possible revocation event.
> > > > 8/13 9:30-4pm – Issue scope identification (at this point it was
> > unknown),
> > > > gathering certificate list
> > > > 8/13 4pm – Certificate list finalized for revoke total 825 certs,
> > Revoke
> > > > notification sent to cert owners.
> > > >
> > >
> > > I presume you mean domain owners?
> > >
> > > Do we know if any of these certs were used? If so, how?
> > >
> > >
> > > > 8/14 1:30pm – All certificates revoked.
> > > >
> > > > Further research identified 40 certificates which contained re-use of
> > > > suspect validation information.
> > > > 8/15 – 2pm – Additional certificates identified due to re-use.
> > > > 8/15 – 2:30pm – Customers notified of pending revoke.
> > > > 8/16 – 12:30pm – All certificated revoked.
> > > >
> > > > We stand ready to answer any questions or concerns.
> > > > Daymion
> > > >
> >
> > Yes, domain owners.
> >
> > Yes, some of the certs were being used as typical server certs. We have
> > not detected any nefarious activities.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

Wayne, I have found the bug. Will add information to it soon. -Daymion
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: GoDaddy Revocation Disclosure

[Daymion Reynolds via dev-security-policy]

On Saturday, August 18, 2018 at 2:27:05 PM UTC-7, Ben Laurie wrote:
> On Fri, 17 Aug 2018 at 18:22, Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Revoke Disclosure
> >
> > GoDaddy has been proactively performing self-audits. As part of this
> > process, we identified a vulnerability in our code that would allow our
> > validation controls to be bypassed. This bug would allow for a Random Value
> > that was generated for intended use with Method 3.2.2.4.6 and 3.2.2.4.7 and
> > was validated using Method 3.2.2.4.2 by persons who were not confirmed as
> > the domain contact. This bug was introduced November 2014 and was leveraged
> > to issue a total of 865 certificates. The bug was closed hours after
> > identification, and in parallel we started the scope and revocation
> > activities.
> >
> > In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued
> > certificates were revoked within 24 hours of identification.
> >
> > A timeline of the Events for Revocation are as follows:
> >
> > 8/13 9:30am – Exploit issue surfaced as possible revocation event.
> > 8/13 9:30-4pm – Issue scope identification (at this point it was unknown),
> > gathering certificate list
> > 8/13 4pm – Certificate list finalized for revoke total 825 certs, Revoke
> > notification sent to cert owners.
> >
> 
> I presume you mean domain owners?
> 
> Do we know if any of these certs were used? If so, how?
> 
> 
> > 8/14 1:30pm – All certificates revoked.
> >
> > Further research identified 40 certificates which contained re-use of
> > suspect validation information.
> > 8/15 – 2pm – Additional certificates identified due to re-use.
> > 8/15 – 2:30pm – Customers notified of pending revoke.
> > 8/16 – 12:30pm – All certificated revoked.
> >
> > We stand ready to answer any questions or concerns.
> > Daymion
> >

Yes, domain owners.

Yes, some of the certs were being used as typical server certs. We have not 
detected any nefarious activities.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

GoDaddy Revocation Disclosure

[Daymion Reynolds via dev-security-policy]

Revoke Disclosure

GoDaddy has been proactively performing self-audits. As part of this process, 
we identified a vulnerability in our code that would allow our validation 
controls to be bypassed. This bug would allow for a Random Value that was 
generated for intended use with Method 3.2.2.4.6 and 3.2.2.4.7 and was 
validated using Method 3.2.2.4.2 by persons who were not confirmed as the 
domain contact. This bug was introduced November 2014 and was leveraged to 
issue a total of 865 certificates. The bug was closed hours after 
identification, and in parallel we started the scope and revocation activities.

In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued certificates 
were revoked within 24 hours of identification. 

A timeline of the Events for Revocation are as follows: 

8/13 9:30am – Exploit issue surfaced as possible revocation event.
8/13 9:30-4pm – Issue scope identification (at this point it was unknown), 
gathering certificate list
8/13 4pm – Certificate list finalized for revoke total 825 certs, Revoke 
notification sent to cert owners.
8/14 1:30pm – All certificates revoked.

Further research identified 40 certificates which contained re-use of suspect 
validation information.
8/15 – 2pm – Additional certificates identified due to re-use.
8/15 – 2:30pm – Customers notified of pending revoke.
8/16 – 12:30pm – All certificated revoked.

We stand ready to answer any questions or concerns. 
Daymion

Certificate list which can be found in CRT.sh:

Domain,CRT.sh link
www.makancoaching.co.uk,https://crt.sh/?id=486518293
www.superguttervac.co.uk,https://crt.sh/?id=484345622
www.aloftimaging.co.uk,https://crt.sh/?id=486443992
www.inverroycrisismanagement.com,https://crt.sh/?id=505471354
*.lumeter.co.uk,https://crt.sh/?id=575952063
theredstartprimaryschool.co.uk,https://crt.sh/?id=448982417
www.glscoatings.co.uk,https://crt.sh/?id=471607541
www.thelittlecakekitchen.co.uk,https://crt.sh/?id=622887520
bri-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445612142
mel-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445611906
syd-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445589055
www.photislight.co.uk,https://crt.sh/?id=627260711
sportsandplayconsulting.co.uk,https://crt.sh/?id=432887146
*.mca.uk.net,https://crt.sh/?id=476788955
www.underdogcoffee.co.uk,https://crt.sh/?id=445809844
www.kiyoraspa.co.uk,https://crt.sh/?id=448128056
www.kinesisclinic.co.uk,https://crt.sh/?id=444013056
www.homegenies.co.uk,https://crt.sh/?id=490198693
activemountaineering.co.uk,https://crt.sh/?id=452604481
www.brightonshellfish.co.uk,https://crt.sh/?id=48433
www.electroquip.co.uk,https://crt.sh/?id=454680891
www.melbournederbyshire.co.uk,https://crt.sh/?id=459144464
iih.org.uk,https://crt.sh/?id=452613519
*.growhub.co.uk,https://crt.sh/?id=445804391
www.weaversguesthouse.co.uk,https://crt.sh/?id=516764585
*.ctc-solutions.co.uk,https://crt.sh/?id=508837605
thothmail.saqqara.co.uk,https://crt.sh/?id=627917932
www.ringwoodhallhotel.com,https://crt.sh/?id=456471228
remote.yachtingpages.com,https://crt.sh/?id=453013515
www.waynesecigsupplies.co.uk,https://crt.sh/?id=484348665
www.thoth.saqqara.co.uk,https://crt.sh/?id=477514633
remote.mara.uk.com,https://crt.sh/?id=491400207
www.needfulthings.uk.com,https://crt.sh/?id=458812648
www.sensoryapphouse.com,https://crt.sh/?id=460684499
www.youcanbecome.co.uk,https://crt.sh/?id=486521955
*.speechbuilder.co.uk,https://crt.sh/?id=465020837
www.somerville-house.co.uk,https://crt.sh/?id=513011072
www.cameoclassics.co.uk,https://crt.sh/?id=627503851
praxis-godesberger-allee.de,https://crt.sh/?id=491408016
www.hydra-te.co.uk,https://crt.sh/?id=505470107
*.mca.uk.net,https://crt.sh/?id=476788955
*.mhsserver5.com,https://crt.sh/?id=575963842
www.dormagen-anwalt.de,https://crt.sh/?id=487910728
rosenbaumgruppe.eu,https://crt.sh/?id=484075777
remote.micheloud.net,https://crt.sh/?id=491387626
webmail.janssensmarket.com,https://crt.sh/?id=527896643
www.collegeinabox.co.uk,https://crt.sh/?id=500425581
www.lepetitcapelier.com,https://crt.sh/?id=497736247
www.total-michel.com,https://crt.sh/?id=486035156
www.thetoolbox.uk.com,https://crt.sh/?id=486038438
www.theinformer.org.uk,https://crt.sh/?id=488179681
outlook.comprovide.de,https://crt.sh/?id=575914237
www.vellastar.com,https://crt.sh/?id=493898204
mail.iarg.com.au,https://crt.sh/?id=501369255
www.iplacenotes.com,https://crt.sh/?id=487635287
isiportalorders.com,https://crt.sh/?id=496718880
www.ostsee-grundbesitz.de,https://crt.sh/?id=518520334
invia-koeln.de,https://crt.sh/?id=489938629
www.nikkihalliwell.com,https://crt.sh/?id=510581809
www.mckennaxmedia.co.uk,https://crt.sh/?id=513220692
www.indigoplumbingandheating.co.uk,https://crt.sh/?id=553607579
essentialtwenty.co.uk,https://crt.sh/?id=488171957
www.topthornarena.co.uk,https://crt.sh/?id=497039944
www.marstallwache.de,https://crt.sh/?id=512736683
www.feuerwehr-heinrichsheim.de,https://crt.sh/?id=551287541
kaizenlaw.co.uk,https://crt.sh/?id=492950320

Re: GoDaddy Revocations Due to a Variety of Issues

[Daymion Reynolds via dev-security-policy]

Once we have the CertLint change pull requests done we will submit them to this 
thread. They were much more involved, and many times more numerous. It is worth 
a write up on where they overlap and diverge. 

Daymion

On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote:
> On Fri, Jul 20, 2018 at 6:39 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > The certificates were identified by analyzing results from both zlint and
> > certlint. We also verified all lint findings against current and past BRs.
> > We discovered multiple defects with the linters, and submitted pull
> > requests to correct them. See below.
> >
> > CertLint PRs to correct issues:
> >
> > In Progress, will publish if requested.
> >
> 
> Yes, I would very much like to have either PRs or just a list of issues.
> 
> 
> > | e_dnsname_not_valid_tld,  |
> >  |
> > |e_subject_common_name_not_from_san,|
> >  |
> > |e_dnsname_bad_character_in_label   |4
> >   |*7/5/18 11:48  |
> >
> > 
> > | e_subject_common_name_not_from_san,   |   |
> >  |
> > |e_dnsname_bad_character_in_label   |28
> >  |*7/9/18 21:12  |
> >
> > 
> > *Total of 17 certificates issued in 2018 were revoked due to invalid
> > extended ascii characters.  CertLint was not catching these issues, which
> > would have prevented issuance. We have since remediated these problems, and
> > are adding zLint to our certificate issuance process as a second check.
> > Issued in 2018 certificate serial numbers 4329668077199547083,
> > 8815069853166416488, 8835430332440327484, 13229652153750393997,
> > 12375089233389451640, 11484792606267277228, 11919098489171585007,
> > 9486648889515633287, 14583473664717830410, 7612308405142602244,
> > 4011153125742917275, 6919066797946454186, 15449193186990222652,
> > 14380872970193550115, 1792501994142248245, 12601193235728728125,
> > 10465762057746987360
> > Cert.sh was unavailable when this was crafted else I would provide links
> > to the 4 certs which were CT logged.
> 
> 
>  https://crt.sh/?id=294808610=zlint,cablint is one of the
> certificates.  It is not clear to me that there is an error here.  The DNS
> names in the SAN are correctly encoded and the Common Name in the subject
> has one of the names found in the SAN.  The Common Name contains a DNS name
> that is the U-label form of one of the SAN entries.
> 
> It is currently undefined if this is acceptable or unacceptable for
> certificates covered by the BRs.  I put a CA/Browser Forum ballot forward a
> while ago to try to clarify it was not acceptable, but it did not pass as
> several CAs felt it was not only acceptable but is needed and desirable.
> 
> If Mozilla (or another browser) puts forward a policy on this, I'm happy to
> update certlint to reflect the poicy.
> 
> Thanks,
> Peter

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

GoDaddy Revocations Due to a Variety of Issues

[Daymion Reynolds via dev-security-policy]

Revoke Notification

GoDaddy has been proactively auditing certificates under management.  We have 
identified 1000 certificates having one or more of the 6 issues defined below. 
The majority of these certs are 3yrs old or older. Most are from 2013 or 
before.  

The certificates were identified by analyzing results from both zlint and 
certlint. We also verified all lint findings against current and past BRs. We 
discovered multiple defects with the linters, and submitted pull requests to 
correct them. See below.

Zlint PR to correct these issues:
https://github.com/zmap/zlint/pull/232 
https://github.com/zmap/zlint/commit/12b8dc0338e6261fb4ad6a623c0a4c1bc99b3dfe

CertLint PRs to correct issues:

In Progress, will publish if requested.

Once we had confirmation of the lint issues we then proceeded to incrementally 
notify and revoke. See timeline is below.

Timeline of Events for Revocation:
6/26/2018 – 7/10/2018 – Test runs and bug fixes for Zlint/CertLint
7/11/2018 9:45am – First round list of certs identified to revoke. 

| Error | Quantity of 
Certs | Last Occurrence   |

|BR certificates must be 39 months in validity or less  |27 
|4/1/15 13:07   |
-
|BR certificates must be 60 months in validity or less  |84 
|8/7/13 16:48   |
-
|BR certificates with organizationName must include countryName |6  
|1/17/13 14:51  |
-
| e_dnsname_not_valid_tld,  |   
|
|e_subject_common_name_not_from_san,|   
|
|e_dnsname_bad_character_in_label   |4  
|*7/5/18 11:48  |

| e_subject_common_name_not_from_san,   |   |   
|
|e_dnsname_bad_character_in_label   |28 
|*7/9/18 21:12  |

| RSA subject key modulus must be at least 2048 bits|638
|10/5/09 8:25   |

*Total of 17 certificates issued in 2018 were revoked due to invalid extended 
ascii characters.  CertLint was not catching these issues, which would have 
prevented issuance. We have since remediated these problems, and are adding 
zLint to our certificate issuance process as a second check. 
Issued in 2018 certificate serial numbers 4329668077199547083, 
8815069853166416488, 8835430332440327484, 13229652153750393997, 
12375089233389451640, 11484792606267277228, 11919098489171585007, 
9486648889515633287, 14583473664717830410, 7612308405142602244, 
4011153125742917275, 6919066797946454186, 15449193186990222652, 
14380872970193550115, 1792501994142248245, 12601193235728728125, 
10465762057746987360
Cert.sh was unavailable when this was crafted else I would provide links to the 
4 certs which were CT logged.
7/11/2018 10:30am – Certificate revocation process started, with emails sent to 
certificate owners.
7/12/2018 9am – All first-round certificates revoked.
7/13/2018 11:30am - Second round of certs identified.

| Error | Quantity of 
Certs | Last Occurrence   |

| RSA subject key modulus must be at least 2048 bits|213
|7/30/09 13:52  |
-
7/13/2018 1:30pm- Final round of cert revocations completed.
Please let us know of any questions or concerns.
Daymion Reynolds

Malformed Certificate Revocation - Godaddy

[Daymion Reynolds via dev-security-policy]

CA first become aware:  

We first became aware of the malformed certificates 
https://crt.sh/?id=250008707=cablint,x509lint,zlint,ocsp & 
https://crt.sh/?id=49843724=zlint,cablint,x509lint,ocsp  via a Bugzilla bug 
report on 5/18 and an email to practices@.

Timeline of the actions: 

5/18 1am UTC: Upon reviewing, and verifying the certs did indeed have a defect 
we started our revocation and rekey process by contacting the certificate 
owners. The owners were not immediately reachable, and/or needed time to 
perform the certificate swap.
5/19 10pm UTC: Certificates were revoked, after owner contact. Well within the 
24hr required period. 

CA has stopped issuing defect: 

The identified certificates were defective due to a bug, which dated back to 
pre-2015. This defect rarely occurred.  February 2018 the issue reoccurred, but 
was caught/prevented by the linter. We corrected the defect on 2/8/2018.
Summary of the problematic certificates & complete certificate data:
The printable string defect was found in the following certificates:

This bug:

https://crt.sh/?id=250008707=cablint,x509lint,zlint,ocsp
https://crt.sh/?id=49843724=zlint,cablint,x509lint,ocsp

Additionally, upon scanning our certificate store we identified:

https://crt.sh/?id=167970618=cablint,zlint
https://crt.sh/?id=246757501=cablint,x509lint,zlint 

All certificates with the defect were revoked within 24hrs following 
identification.

Explanation about how and why the mistakes were made or bugs introduced:

The defect occurred by improper handling of extended Unicode character. 

List of steps your CA is taking to resolve the situation:

Certificates were revoked, rekeyed. Linting was added to the provisioning 
pipeline to prevent future occurrences in November 2017.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Discovering unlogged certificates in internet-wide scans

[Daymion Reynolds via dev-security-policy]

As an FYI only:

We did review the one cert cited below for term length. The certificate was 
issued in 2013 before the current max term duration was defined.  This cert is 
grandfathered in and does not require revocation. In May of this year it 
expires.

regards,
Daymion

On Sunday, April 1, 2018 at 10:25:16 PM UTC-7, Eric Mill wrote:
> Did you submit the ~25K unexpired unlogged certs to CT?
> 
> On Sat, Mar 31, 2018 at 6:14 PM, Tim Smith via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Hi MDSP,
> >
> > I went looking for corpuses of certificates that may not have been
> > previously logged to CT and found some in the Rapid7 "More SSL" dataset,
> > which captures certificates from their scans of non-HTTPS ports for
> > TLS-speaking services.
> >
> > I wrote up some findings at
> > http://blog.tim-smith.us/2018/03/moressl-spelunking/.
> >
> > A few highlights include:
> > - of the ~10 million certificates in the corpus, about 20% had valid
> > signatures and chained to roots included in the Mozilla trust store
> > - about 50,000 of the 2 million trusted certificates had not previously
> > been logged
> > - about half of the novel certificates were unexpired
> >
> > There were interesting examples of unexpired, non-compliant, trusted
> > certificates chaining to issuers including GoDaddy, NetLock, Logius, and
> > Entrust. (I have not taken any action to inform issuers of these findings,
> > other than this message and by publishing the certificates to CT logs.)
> >
> > I welcome any feedback or questions about the value of the approach and the
> > findings.
> >
> > Thanks,
> > Tim
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> 
> 
> 
> -- 
> konklone.com | @konklone 

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

Incident Report : GoDaddy certificates with ROCA Fingerprint

[Daymion Reynolds via dev-security-policy]

Godaddy LLC first became aware of possible ROCA vulnerability exposure on 
Monday October 16th 2017 at 9:30am. The following are the steps we took for 
detection, revocation, and the permanent fix of certificate provisioning:

•   Monday October 16th 2017 AZ, first became aware of the ROCA 
vulnerability.  We downloaded and modified the open source detection tool to 
audit 100% of the non-revoked and non-expired certs we had issued.  
•   Early am Wednesday October 18th AZ we had our complete list of 7 certs 
with the ROCA defect. We verified the results and proceeded to start the 
revocation process. While cert revocation was in progress we started 
researching the long-term detection and prevention of the weak CSR 
vulnerability. 
•   Early am Wednesday October 18th Rob Stradling released a list of certs 
with the vulnerability. 2/7 we revoked were on the list. 
https://misissued.com/batch/28/ 
•   Thursday October 19th by 2:02am AZ, we completed the 7 cert 
revocations. Revocations included customer outreach to advise the customer of 
the vulnerability.
•   Thursday October 19th AZ, two CSRs were submitted for commonNames 
“scada2.emsglobal.net” & “scada.emsglobal.net” and were issued. Each request 
had used the vulnerable keys for CSR generation.  We revoked the certs again on 
Thursday October 19th AZ. During this period, we reached out to the customer to 
educate them regarding the vulnerability and informing them they needed to 
generate a new keypair from an unimpacted device.  Customer was unreachable. 
Friday October 20thAZ,  another cert was issued for commonName 
“scada.emsglobal.net” using a CSR generated with a weak key. We then took 
measures to prevent future certs from being issued to the same common name and 
revoked the cert on October 20th 2017 AZ. 
commonName   crt.sh-link
scada.emsglobal.net  https://crt.sh/?id=3084867 

scada.emsglobal.net  https://crt.sh/?id=238721704   

scada.emsglobal.net  https://crt.sh/?id=238721807

scada2.emsglobal.net https://crt.sh/?id=238720969

scada2.emsglobal.net https://crt.sh/?id=238721559

•   Saturday October 21st 2017 AZ & Sunday October 22nd 2017 AZ, we scanned 
our cert store and identified 0 vulnerable certs. 
•   Monday October 23, 2017 AZ, we have deployed a permanent fix to prevent 
future CSRs generated using weak keys from being submitted. Post scanning of 
the environment concluded 0 certificates at risk. 
 
Below is a complete list of certs under GoDaddy management impacted by this 
vulnerability. 

Alias  crt.sh-link
alarms.realtimeautomation.net  https://crt.sh/?id=33966207 

scada.emsglobal.nethttps://crt.sh/?id=3084867
   https://crt.sh/?id=238721704   
   https://crt.sh/?id=238721807 

www.essicorp-scada.com https://crt.sh/?id=238720405 

marlboro.bonavistaenergy.com   https://crt.sh/?id=238720743 

scada2.emsglobal.net   https://crt.sh/?id=238720969
   https://crt.sh/?id=238721559 

www.jointboardclearscada.com   https://crt.sh/?id=238721242 

*.forgenergy.com   https://crt.sh/?id=238721435 

 
Regards,
Daymion Reynolds
GoDaddy PKI
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy