Closed Bug 1434300 Opened 2 years ago Closed 2 years ago

Distrust Symantec CAs affected by the distrust plan

Categories

(Core :: Security: PSM, defect, P1)

60 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla60
Tracking Status
firefox60 --- fixed

People

(Reporter: jcj, Assigned: jcj)

References

(Blocks 1 open bug)

Details

(Keywords: site-compat)

Attachments

(11 files)

59 bytes, text/x-review-board-request
keeler
: review+
franziskus
: review+
Details
59 bytes, text/x-review-board-request
keeler
: review+
franziskus
: review+
Details
59 bytes, text/x-review-board-request
keeler
: review+
franziskus
: review+
Details
59 bytes, text/x-review-board-request
keeler
: review+
franziskus
: review+
Details
59 bytes, text/x-review-board-request
keeler
: review+
Details
59 bytes, text/x-review-board-request
keeler
: review+
Details
7.48 KB, text/plain
Details
1.05 KB, text/plain
Details
3.74 MB, application/x-bzip2
Details
482.29 KB, text/plain
Details
379.26 KB, text/plain
Details
This bug is to complete the draft plan from M.D.S.P. [1]. 

Collected in here will be:

1) Adapt the tests from Bug 1409259 which verify the console warning to cover a fictitious CA rather than Symantec's CAs, preserving the warning code for future use

2) Move the Symantec distrust code so that it distrusts the certificates rather than printing a warning


[1] https://groups.google.com/d/topic/mozilla.dev.security.policy/FLHRT79e3XE/discussion
Do you consider the whitelisting for excluded subCAs part of this bug?
(In reply to Kai Engert (:kaie:) from comment #1)
> Do you consider the whitelisting for excluded subCAs part of this bug?

I assume the answer is yes. I see that you had already added whitelists as part of the earlier work that implemented the browser console warnings.
I'm looking at the various sources of information for the distrust plan, and I'd like to mention a few observations. (You might already be aware of these details, but maybe it can be helpful.)

(1)

This report:
  https://arkadiyt.com/2018/02/04/quantifying-untrusted-symantec-certificates/
claims that the initial phase of distrust will distrust certificates issued before 2016-06-01, and also certificates issued after 2017-12-01.

However, the console warning in the current implementation 
  https://hg.mozilla.org/integration/autoland/rev/595e27212723#l3.64
appears to check only for certs issued earlier than 2016-06-01,
but doesn't seem to check for certs issued after 2017-12-01.

Google's page
  https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
says:
  "December 1, 2017 ... Any certificates issued by Symantec’s old infrastructure 
   after this point will cease working in a future Chrome update."
but it doesn't cleary state when exactly they will no longer be accepted.

Would it make sense to update the Firefox implementation for warn for certificates issued after 2017-12-01, too, and might it be useful to update the warning code early, in a Firefox 58.x or Firefox 59 release?

Should the distrust implemented in this bug for Firefox 60 also distrust certificates that were issused after 2017-12-01?


(2)

The whitelist of intermediates might be incomplete, based on the most recent information.

A recent message on the newsgroup provided a link to this chromium code:
  https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec

In addition to intermediates from Apple and Google, which you had already added to Firefox, there are 4 intermediates from DigiCert.

Will Firefox whitelist those DigiCert subCAs, too?

Would it make sense to add the DigiCert subCAs to the whitelist in a release earlier than Firefox 60?

If Firefox 58/59 aren't aware of these subCAs, then Firefox 58/59 are probably giving false console warnings for the sites issued by the DigiCert subCAs?
One Google subCA has already expired and can probably be removed from the whitelist.

Firefox whitelists 7 Apple subCAs, and the newsgroup posting had mentioned 7 Apple subCAs, too.

However, the page 
  https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec
only lists 6 Apple subCAs.

It should probably be clarified if the Google page is incomplete, or if Firefox should remove one of the Apple subCAs.
Comment on attachment 8950470 [details]
Bug 1434300 - Update Imminent Distrust status for future Symantec sanctions

https://reviewboard.mozilla.org/r/219736/#review225456


Code analysis found 1 defect in this patch:
 - 1 defect found by mozlint

You can run this analysis locally with:
 - `./mach lint path/to/file` (JS/Python)


If you see a problem in this automated review, please report it here: http://bit.ly/2y9N9Vx


::: security/manager/tools/crtshToDNStruct/crtshToDNStruct.py:97
(Diff revision 1)
>      for crtshId in certshIds:
> +        # Try a local file first, then crt.sh
> +        try:
> +            with open(crtshId, "rb") as pemFile:
> +                blocks.append(print_block(pemFile.read(), None))
> +        except:

Error: Do not use bare except' [flake8: E722]
Comment on attachment 8950470 [details]
Bug 1434300 - Update Imminent Distrust status for future Symantec sanctions

https://reviewboard.mozilla.org/r/219736/#review225492

::: security/manager/ssl/tests/unit/xpcshell.ini:100
(Diff revision 2)
>  [test_hash_algorithms_wrap.js]
>  # bug 1124289 - run_test_in_child violates the sandbox on android
>  skip-if = toolkit == 'android'
>  [test_hmac.js]
>  [test_intermediate_basic_usage_constraints.js]
> +[test_imminent_distrust.js]

So this doesn't work on Android?

::: security/manager/tools/crtshToDNStruct/crtshToDNStruct.py:94
(Diff revision 2)
>      print("// Script from security/manager/tools/crtshToDNStruct/crtshToDNStruct.py")
>      print("// Invocation: {} {}".format(sys.argv[0], " ".join(certshIds)))
>      print()
>      for crtshId in certshIds:
> +        # Try a local file first, then crt.sh
> +        try:

You've seen the Code Review Bot comment :)
Attachment #8950470 - Flags: review?(franziskuskiefer) → review+
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review225500

::: security/certverifier/NSSCertDBTrustDomain.cpp:777
(Diff revision 2)
> +{
> +    // PRECONDITION: The rootCert is already verified as being one of the
> +    // affected Symantec roots
> +
> +    // Check the preference to see if this is enabled before proceeding.
> +    // TODO in Bug 1437754

Do you want to land that pref first? Or at the same time?

::: security/manager/ssl/nsNSSCertValidity.h:26
(Diff revision 2)
>    virtual ~nsX509CertValidity() {}
>  
>  private:
>    nsresult FormatTime(const PRTime& aTime,
>                        PRTimeParamFn aParamFn,
> -                      const nsTimeFormatSelector aTimeFormatSelector,
> +                      const mozilla::nsTimeFormatSelector aTimeFormatSelector,

Why?
Attachment #8950471 - Flags: review?(franziskuskiefer) → review+
Blocks: 1437826
Comment on attachment 8950470 [details]
Bug 1434300 - Update Imminent Distrust status for future Symantec sanctions

https://reviewboard.mozilla.org/r/219736/#review225492

Thanks for the review!

> So this doesn't work on Android?

It's not marked to skip on Android...?

> You've seen the Code Review Bot comment :)

....and it's already resolved with the `except FileNotFoundError`?
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review225500

> Do you want to land that pref first? Or at the same time?

I'll do it after this change. It needs an enum to be plumbed through all the methods of mozilla::pkix, since there's no way to get at preferences otherwise. All that boilerplate is such a PITA... and in an optimal world, I'd assign it to someone junior. But of course, that's me! :)

> Why?

This was necessary to get NSSCertDBTrustDomain.cpp
to compile when including this header. I presume other including files explicitly include the `mozilla` namespace, but mozpkix has its own namespace.
Comment on attachment 8950470 [details]
Bug 1434300 - Update Imminent Distrust status for future Symantec sanctions

https://reviewboard.mozilla.org/r/219736/#review225492

> It's not marked to skip on Android...?

my bad... I guess I should sleep more.

> ....and it's already resolved with the `except FileNotFoundError`?

:+1:
Comment on attachment 8950470 [details]
Bug 1434300 - Update Imminent Distrust status for future Symantec sanctions

https://reviewboard.mozilla.org/r/219736/#review225710

If you get errors like the test server can't find the new certificate you added when landing this, you might need to touch CLOBBER. Not sure, though. Anyway, lgtm.

::: security/manager/ssl/tests/unit/bad_certs/ee-imminently-distrusted.pem:21
(Diff revision 2)
> +2G8UlObIdzuym5FPDpvuiQIcDIZELUOQO9V+fjeK0CZ4luFnox+cIvnB39pLa5Xd
> +hHUyWMgsf9cW/T1yjjRAS2YX/HUYGjSH9MNhSriiAABers1fyJkn7fdVTav2pQTp
> +5yNdtwrFYkWjw1DG17uj/gtkll3ACw9oztjYTGj/okDI+ViLJqL4QeQb4G4Lpp77
> ++A8JfHGf/yFprXMMExy8FNN8FLIxdN2lX4WwBS5WHQ==
> +-----END CERTIFICATE-----
> +

Is this from the build system generating the file or from directly calling pycert.py? (I ask because I attempted to make it output files with only the one trailing newline, not two...)

::: security/manager/ssl/tests/unit/bad_certs/ee-imminently-distrusted.pem.certspec:4
(Diff revision 2)
> +issuer:Test CA
> +subject:printableString/C=US/CN=Imminently Distrusted End Entity
> +extension:subjectAlternativeName:localhost,imminently-distrusted.example.com
> +extension:authorityInformationAccess:http://localhost:8888/

Technically, not sure we need an OCSP URI here but whatevs.

::: security/manager/tools/crtshToDNStruct/crtshToDNStruct.py:72
(Diff revision 2)
>      print("// {dn}".format(dn=distinguished_name))
>      print("// SHA256 Fingerprint: " + ":".join(fingerprint[:16]))
>      print("//                     " + ":".join(fingerprint[16:]))
> +    if crtshId:
> -    print("// https://crt.sh/?id={crtsh} (crt.sh ID={crtsh})"
> +        print("// https://crt.sh/?id={crtsh} (crt.sh ID={crtsh})"
> -          .format(crtsh=crtshId))
> +              .format(crtsh=crtshId))

Did this just not work before?
Attachment #8950470 - Flags: review?(dkeeler) → review+
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review225722

LGTM with some more return value checks and changing the revoked error to unknown issuer.

::: security/certverifier/NSSCertDBTrustDomain.cpp:812
(Diff revision 2)
> +    // doesn't apply, so exit false before we do any iterating
> +    if (notBefore >= JUNE_1_2016) {
> +      return Success;
> +    }
> +
> +    // This algorithm only applies if either the serverAuth or anyAuth EKUs are

This comment seems out of place, since this function doesn't do any checking wrt eku.

::: security/certverifier/NSSCertDBTrustDomain.cpp:822
(Diff revision 2)
> +
> +    // Look for one of the intermediates to be in the whitelist
> +    bool foundInWhitelist = false;
> +    RefPtr<nsNSSCertList> intCertList = intCerts->GetCertList();
> +
> +    intCertList->ForEachCertificateInChain(

Need a return value check here.

::: security/certverifier/NSSCertDBTrustDomain.cpp:835
(Diff revision 2)
> +        }
> +        return NS_OK;
> +    });
> +
> +    if (!foundInWhitelist) {
> +      return Result::ERROR_REVOKED_CERTIFICATE;

As discussed in the meeting, let's use unknown issuer for now.

::: security/certverifier/NSSCertDBTrustDomain.cpp:930
(Diff revision 2)
>        return Result::ERROR_POLICY_VALIDATION_FAILED;
>      }
>  
>      bool foundRequiredIntermediate = false;
>      RefPtr<nsNSSCertList> intCertList = intCerts->GetCertList();
>      intCertList->ForEachCertificateInChain(

Might be nice to add a return value check here too.

::: security/manager/ssl/tests/unit/test_symantec_apple_google.js:40
(Diff revision 2)
>  add_connection_test("symantec-not-whitelisted-after-cutoff.example.com",
>                      PRErrorCodeSuccess, null, shouldBeImminentlyDistrusted);
>  
> -// Not whitelisted certs before the cutoff are to be distrusted
> +// Not whitelisted certs before the cutoff are to be revoked
>  add_connection_test("symantec-not-whitelisted-before-cutoff.example.com",
> -                    PRErrorCodeSuccess, null, shouldBeImminentlyDistrusted);
> +                    SEC_ERROR_REVOKED_CERTIFICATE, null, null);

Unknown issuer for now.
Attachment #8950471 - Flags: review?(dkeeler) → review+
Comment on attachment 8950470 [details]
Bug 1434300 - Update Imminent Distrust status for future Symantec sanctions

https://reviewboard.mozilla.org/r/219736/#review225710

Good to know.

> Is this from the build system generating the file or from directly calling pycert.py? (I ask because I attempted to make it output files with only the one trailing newline, not two...)

The build system generated this one; I forgot about directly using `pucert.py` until later... didn't figure there would be a difference. Want me to regenerate it?

> Did this just not work before?

It worked. It's just trying to make a one-off tool be slightly less ugly.
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review225722

> This comment seems out of place, since this function doesn't do any checking wrt eku.

Oops. Great catch, this needs EKU checks.
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review226050

lgtm, two nits.

::: security/certverifier/tests/gtest/TrustOverrideTest.cpp:112
(Diff revision 1)
> +
> +static mozilla::UniqueCERTCertificate
> +CertFromString(const char* aPem)
> +{
> +  nsCOMPtr<nsIX509Cert> cert;
> +  cert = nsNSSCertificate::ConstructFromDER(const_cast<char*>(aPem), strlen(aPem));

`ConstructFromDER` should probably take a `const char*`.

::: security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py:52
(Diff revision 1)
>          return "O"
>      if oid == NameOID.ORGANIZATIONAL_UNIT_NAME:
>          return "OU"
>      raise Exception("Unknown OID: {}".format(oid))
>  
> -def print_block(pemData, crtshId):
> +def print_block(pemData, identifierType="DN", crtshId=None):

Do you need the default for `identifierType`? I think you pass one in everyt time.
Attachment #8950817 - Flags: review?(franziskuskiefer)
Comment on attachment 8950818 [details]
Bug 1434300 - Change Symantec Distrust Algorithm's whitelist to SPKI-matching

https://reviewboard.mozilla.org/r/220068/#review226052

lgtm, I didn't check all the SPKIs though ;)
Attachment #8950818 - Flags: review?(franziskuskiefer) → review+
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review226142

Nice - looks good.

::: security/certverifier/TrustOverrideUtils.h:45
(Diff revision 1)
> +  MOZ_ASSERT(aCert);
> +  if (!aCert) {
> +    return false;
> +  }
> +
> +  for (auto &spki: aSpkiList) {

nit: & to the left

::: security/certverifier/tests/gtest/TrustOverrideTest.cpp:72
(Diff revision 1)
> +  0x30, 0x0D, 0x31, 0x0B, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x03, 0x0C, 0x02,
> +  0x63, 0x61,
> +};
> +
> +static const DataAndLength OverrideCaDNs[]= {
> +  { CAcaDN,

nit: seems like this could be one line, but not a big deal

::: security/certverifier/tests/gtest/TrustOverrideTest.cpp:104
(Diff revision 1)
> +  0x49, 0x23, 0xFA, 0x72, 0x51, 0xC4, 0x31, 0xD5, 0x03, 0xAC, 0xDA, 0x18, 0x0A,
> +  0x35, 0xED, 0x8D, 0x02, 0x03, 0x01, 0x00, 0x01,
> +};
> +
> +static const DataAndLength OverrideCaSPKIs[]= {
> +  { CAcaSPKI,

same idea here

::: security/certverifier/tests/gtest/TrustOverrideTest.cpp:111
(Diff revision 1)
> +};
> +
> +static mozilla::UniqueCERTCertificate
> +CertFromString(const char* aPem)
> +{
> +  nsCOMPtr<nsIX509Cert> cert;

nit: declaration/assignment on the same line? (probably will have to wrap anyway, but still)
Attachment #8950817 - Flags: review?(dkeeler) → review+
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review226050

> `ConstructFromDER` should probably take a `const char*`.

This seems to be a result of the NSS APIs we're using here (and that there's no such thing as a SECItem pointing to const data). Fixing this for real might be a bit involved (but would be nice in the long run).
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review226158

::: security/certverifier/NSSCertDBTrustDomain.cpp:771
(Diff revision 3)
>    return Success;
>  }
>  
> +// Implement the graduated Symantec distrust algorithm from Bug 1409257
> +static Result
> +CheckForSymantecDistrust(const RefPtr<nsNSSCertList>& certList)

er... so is this a duplicate of IsCertificateDistrustImminent in nsNSSCallbacks.cpp? We should see if we can share code here.
Comment on attachment 8950818 [details]
Bug 1434300 - Change Symantec Distrust Algorithm's whitelist to SPKI-matching

https://reviewboard.mozilla.org/r/220068/#review226154

LGTM.

::: commit-message-80351:9
(Diff revision 1)
> +needing to be whitelisted [1], and that those CAs are using an increasing number
> +of certificates all with different Subjects (but identical public keys) [2][3],
> +we will have to whitelist on SPKI rather than subject DN.
> +
> +This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
> +integration test much... shorter, as we can no longer test whitelist inclusion.

Can we find an existing chain that should be whitelisted and verify it at a time we know it will be valid?

::: security/certverifier/TrustOverride-AppleGoogleData.inc:206
(Diff revision 1)
> -  { CAAppleISTCA3G1DN,
> -    sizeof(CAAppleISTCA3G1DN) },
> -  { CAAppleISTCA6G1DN,
> -    sizeof(CAAppleISTCA6G1DN) },
> +};
> +
> +static const DataAndLength RootAppleAndGoogleSPKIs[]= {
> +  { CAGoogleInternetAuthorityG2SPKI,
> +    sizeof(CAGoogleInternetAuthorityG2SPKI) },
> +  { CAGoogleInternetAuthorityG2SPKI,

Duplicate entry?
Attachment #8950818 - Flags: review?(dkeeler) → review+
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review226050

> This seems to be a result of the NSS APIs we're using here (and that there's no such thing as a SECItem pointing to const data). Fixing this for real might be a bit involved (but would be nice in the long run).

Yeah, my point was to use `const` as long as possible. It has to go away before handing it to NSS but could be cast away at that point. Not a big deal for this patch though.
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review226158

> er... so is this a duplicate of IsCertificateDistrustImminent in nsNSSCallbacks.cpp? We should see if we can share code here.

It's not exactly, but you're right, I will parameterize this and put it into the Utils.
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review226142

> nit: seems like this could be one line, but not a big deal

Fixed in the script and the files. :)
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review226050

> Yeah, my point was to use `const` as long as possible. It has to go away before handing it to NSS but could be cast away at that point. Not a big deal for this patch though.

Totally fair. Dropping for now.

> Do you need the default for `identifierType`? I think you pass one in everyt time.

I do, but it's not hurting anything, and I'm not a fan of using `**kwargs` with so few options as it, to me, disguises what the function is doing. So I'm going to drop this one for style purposes, though I totally understand where you're coming from.
Comment on attachment 8950818 [details]
Bug 1434300 - Change Symantec Distrust Algorithm's whitelist to SPKI-matching

https://reviewboard.mozilla.org/r/220068/#review226154

> Can we find an existing chain that should be whitelisted and verify it at a time we know it will be valid?

Great idea! I'm adding such a test to `test_symantec_apple_google.js`.

> Duplicate entry?

Oops. Thanks :)
Comment on attachment 8950818 [details]
Bug 1434300 - Change Symantec Distrust Algorithm's whitelist to SPKI-matching

https://reviewboard.mozilla.org/r/220068/#review227014


Code analysis found 1 defect in this patch:
 - 1 defect found by mozlint

You can run this analysis locally with:
 - `./mach lint path/to/file` (JS/Python)


If you see a problem in this automated review, please report it here: http://bit.ly/2y9N9Vx


::: security/manager/ssl/tests/unit/test_symantec_apple_google.js:50
(Diff revision 2)
> +
> +  checkCertErrorGenericAtTime(certDB, whitelistedCert, PRErrorCodeSuccess,
> +                              certificateUsageSSLServer, VALIDATION_TIME);
> +
> +  run_next_test();
> +}

Error: Newline required at end of file but not found. [eslint: eol-last]
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review227128
Attachment #8950817 - Flags: review?(franziskuskiefer) → review+
Comment on attachment 8950818 [details]
Bug 1434300 - Change Symantec Distrust Algorithm's whitelist to SPKI-matching

https://reviewboard.mozilla.org/r/220068/#review227014

> Error: Newline required at end of file but not found. [eslint: eol-last]

Fixed.
Comment on attachment 8952157 [details]
Bug 1434300 - Disable the b-c imminent distrust test

https://reviewboard.mozilla.org/r/221402/#review227214


Code analysis found 1 defect in this patch:
 - 1 defect found by mozlint

You can run this analysis locally with:
 - `./mach lint path/to/file` (JS/Python)


If you see a problem in this automated review, please report it here: http://bit.ly/2y9N9Vx


::: devtools/client/webconsole/test/browser.ini:164
(Diff revision 1)
>  [browser_bug_869003_inspect_cross_domain_object.js]
>  [browser_bug_871156_ctrlw_close_tab.js]
>  [browser_cached_messages.js]
>  [browser_console.js]
>  [browser_console_addonsdk_loader_exception.js]
> -[browser_console_certificate_imminent_distrust.js]
> +#[browser_console_certificate_imminent_distrust.js] # bug 1439378 to re-enable

Error: Use 'disable=<reason>' to disable a test instead of a comment [no-comment-disable: None]
Comment on attachment 8952157 [details]
Bug 1434300 - Disable the b-c imminent distrust test

https://reviewboard.mozilla.org/r/221402/#review227214

> Error: Use 'disable=<reason>' to disable a test instead of a comment [no-comment-disable: None]

Ah, cool. I should... probably always run `mach lint` before pushing to review.
Comment on attachment 8950817 [details]
Bug 1434300 - Add a utility to match certificates based on SPKI

https://reviewboard.mozilla.org/r/220066/#review227612

::: commit-message-e9b06:10
(Diff revisions 1 - 4)
>  
>  This also regenerates the TrustOverride files to use the new script.
>  
>  MozReview-Commit-ID: BhMoJbYXs7Y
> +* * *
> +[mq]: fix_test

Looks like some extra stuff sneaked in here...

::: security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py:135
(Diff revisions 1 - 4)
>              r.raise_for_status()
>              blocks.append(print_block(r.content, crtshId=certId, identifierType=identifierType))
>  
>      print("static const DataAndLength " + args.listname + "[]= {")
>      for structName in blocks:
> +        if len(structName) < 33:

Ohhh, right - the struct data was auto-generated, not hand-written. Well, looks like you figured out a reasonable way to do this anyway.
Comment on attachment 8950818 [details]
Bug 1434300 - Change Symantec Distrust Algorithm's whitelist to SPKI-matching

https://reviewboard.mozilla.org/r/220068/#review227614

::: security/manager/ssl/tests/unit/test_symantec_apple_google.js:41
(Diff revisions 1 - 5)
> +  addCertFromFile(certDB, "test_symantec_apple_google/real-google-g2-intermediate.pem", ",,");
> +  let whitelistedCert = constructCertFromFile("test_symantec_apple_google/real-googlecom.pem");
> +
> +  // Since we don't want to actually try to fetch OCSP for this certificate,
> +  // (as an external fetch is bad in the tests), disable OCSP first.
> +  Services.prefs.setIntPref("security.OCSP.enabled", 0);

You can also pass FLAG_LOCAL_ONLY to the nsIX509CertDB function underlying this, but no big deal.
Comment on attachment 8952156 [details]
Bug 1434300 - Add the DigiCert whitelisted SPKIs

https://reviewboard.mozilla.org/r/221400/#review227618

::: commit-message-6e811:6
(Diff revision 3)
> +Bug 1434300 - Add the DigiCert whitelisted SPKIs r?keeler r?wthayer
> +
> +This adds the 4 digicert CAs to our whitelist as specified in Google's details
> +on the Chromium version of this plan [1].
> +
> +[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md

Should we link to a particular revision in case this gets removed in the future?
Attachment #8952156 - Flags: review?(dkeeler) → review+
Comment on attachment 8950471 [details]
Bug 1434300 - Implement the Symantec distrust plan from Bug 1409257

https://reviewboard.mozilla.org/r/219738/#review227636

::: security/certverifier/TrustOverrideUtils.h:61
(Diff revision 5)
> +static nsresult
> +CheckForSymantecDistrust(const nsCOMPtr<nsIX509CertList>& intCerts,
> +                         const nsCOMPtr<nsIX509Cert>& eeCert,
> +                         const PRTime& permitAfterDate,
> +                         const DataAndLength (&aWhitelist)[T],
> +                         /* out */ bool& isDistrusted)

Let's have a bit more formal and complete documentation of each of these parameters (e.g. describe how 'permitAfterDate` works)
Comment on attachment 8952157 [details]
Bug 1434300 - Disable the b-c imminent distrust test

https://reviewboard.mozilla.org/r/221402/#review227638
Attachment #8952157 - Flags: review?(dkeeler) → review+
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/603b92a0ebd5
Update Imminent Distrust status for future Symantec sanctions r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/d8517bfe9eb2
Implement the Symantec distrust plan from Bug 1409257 r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/ea372af453ef
Disable the b-c imminent distrust test r=keeler
https://hg.mozilla.org/integration/autoland/rev/61b168663a54
Add a utility to match certificates based on SPKI r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/73a952303cae
Change Symantec Distrust Algorithm's whitelist to SPKI-matching r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/23485791d3e1
Add the DigiCert whitelisted SPKIs r=keeler
Backed out for frequent GTest in AllocReplacement.malloc_check:

https://hg.mozilla.org/integration/autoland/rev/dece9cd799b531d92fb7afaca547bc7d5d73fcf6

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=23485791d3e188f55f1905e0fe95a33e0556cddd&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=163306393&repo=autoland

[task 2018-02-20T22:14:23.444Z] 22:14:23     INFO -  TEST-START | AllocReplacement.malloc_check
[task 2018-02-20T22:14:23.444Z] 22:14:23  WARNING -  TEST-UNEXPECTED-FAIL | AllocReplacement.malloc_check | Value of: (ValidateHookedAllocation([] { return malloc(kAllocAmount); }, free))
[task 2018-02-20T22:14:23.445Z] 22:14:23     INFO -    Actual: false
[task 2018-02-20T22:14:23.445Z] 22:14:23     INFO -  Expected: true @ /builds/worker/workspace/build/src/xpcom/tests/gtest/TestAllocReplacement.cpp:113
[task 2018-02-20T22:14:23.445Z] 22:14:23  WARNING -  TEST-UNEXPECTED-FAIL | AllocReplacement.malloc_check | test completed (time: 0ms)
[task 2018-02-20T22:14:23.446Z] 22:14:23     INFO -  TEST-START | AllocReplacement.calloc_check
[task 2018-02-20T22:14:23.447Z] 22:14:23  WARNING -  TEST-UNEXPECTED-FAIL | AllocReplacement.calloc_check | Value of: (ValidateHookedAllocation([] { return calloc(1, kAllocAmount); }, free))
[task 2018-02-20T22:14:23.447Z] 22:14:23     INFO -    Actual: false
[task 2018-02-20T22:14:23.447Z] 22:14:23     INFO -  Expected: true @ /builds/worker/workspace/build/src/xpcom/tests/gtest/TestAllocReplacement.cpp:120
[task 2018-02-20T22:14:23.447Z] 22:14:23  WARNING -  TEST-UNEXPECTED-FAIL | AllocReplacement.calloc_check | test completed (time: 0ms)
[task 2018-02-20T22:14:23.448Z] 22:14:23     INFO -  TEST-START | AllocReplacement.realloc_check
[task 2018-02-20T22:14:23.448Z] 22:14:23     INFO -  TEST-PASS | AllocReplacement.realloc_check | test completed (time: 0ms)
[task 2018-02-20T22:14:23.449Z] 22:14:23     INFO -  TEST-START | AllocReplacement.posix_memalign_check
[task 2018-02-20T22:14:23.449Z] 22:14:23  WARNING -  TEST-UNEXPECTED-FAIL | AllocReplacement.posix_memalign_check | Value of: (ValidateHookedAllocation([] { void* p = nullptr; int result = posix_memalign(&p, sizeof(void*), kAllocAmount); if (result != 0) { return static_cast<void*>(nullptr); } return p; }, free))
[task 2018-02-20T22:14:23.449Z] 22:14:23     INFO -    Actual: false
[task 2018-02-20T22:14:23.450Z] 22:14:23     INFO -  Expected: true @ /builds/worker/workspace/build/src/xpcom/tests/gtest/TestAllocReplacement.cpp:140
[task 2018-02-20T22:14:23.450Z] 22:14:23  WARNING -  TEST-UNEXPECTED-FAIL | AllocReplacement.posix_memalign_check | test completed (time: 0ms)
Flags: needinfo?(jjones)
Looks like this is similar to:

https://bugzilla.mozilla.org/show_bug.cgi?id=1433015#c6

I can reproduce it with a debug build locally, with only the first four patches applied. The new GTest runs before and messes the malloc stats up somehow. To reproduce:

mach gtest "*TrustOverride*:*AllocReplacement*"
The TrustOverrideTest is running afoul of Bug 1433015, so I'm going to move it into its own bug depending on 1433015 and we'll reland this.
Flags: needinfo?(jjones)
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/301e943a2b4d
Update Imminent Distrust status for future Symantec sanctions r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/23ad5230b111
Implement the Symantec distrust plan from Bug 1409257 r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/ae7617faf7f7
Disable the b-c imminent distrust test r=keeler
https://hg.mozilla.org/integration/autoland/rev/09e82ace662c
Add a utility to match certificates based on SPKI r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/1252e0f10727
Change Symantec Distrust Algorithm's whitelist to SPKI-matching r=fkiefer,keeler
https://hg.mozilla.org/integration/autoland/rev/df46a62ed521
Add the DigiCert whitelisted SPKIs r=keeler
Here's a list of SSL hosts broken in current Nightly, generated by running a TLS Canary regression scan against the first 10k SSL hosts in the Umbrella top list. The leading number is the hosts's Umbrella rank. That's 292/10000 hosts of Symantec fallout, so almost 3% at this point:

2,api-global.netflix.com
4,ichnaea.netflix.com
30,secure.netflix.com
55,customerevents.netflix.com
63,icloud.com
252,configuration.apple.com
295,spotxchange.com
296,search.spotxchange.com
312,dt.adsafeprotected.com
322,odr.mookie1.com
360,pixel.adsafeprotected.com
442,static.adsafeprotected.com
451,appsflyer.com
483,360yield.com
507,gspe35-ssl.ls.apple.com
536,fw.adsafeprotected.com
548,netmng.com
602,t.appsflyer.com
608,gspe1-ssl.ls.apple.com
632,t.mookie1.com
682,cl2.apple.com
692,tlg.mookie1.com
701,servedby.flashtalking.com
716,uiboot.netflix.com
807,stats.appsflyer.com
933,cl4.apple.com
1016,cl5.apple.com
1054,jivox.com
1262,events.appsflyer.com
1283,e.visualdna.com
1335,synch.optimatic.com
1581,mobileadtrading.com
1663,track-east.mobileadtrading.com
1762,sync.jivox.com
1839,pandora.com
1859,gfe.nvidia.com
1916,cl3.apple.com
2033,pl.yumenetworks.com
2094,pxl.jivox.com
2167,csm2waycm-atl.netmng.com
2286,gmtdmp.mookie1.com
2331,pubmatic2waycm-atl.netmng.com
2421,s.btstatic.com
2539,yume.com
2582,pool.admedo.com
2594,www.pandora.com
2620,delivery.optimatic.com
2851,vast.optimatic.com
2954,rb.adnxs.com
2980,rudy.adsnative.com
3031,lijit2waycm.netmng.com
3036,rtb.optimatic.com
3063,events.gfe.nvidia.com
3064,mediaserver-cont-sv5-1-v4v6.pandora.com
3065,tracking.optimatic.com
3082,mediaserver-cont-sv5-2-v4v6.pandora.com
3094,mediaserver-cont-ch1-1-v4v6.pandora.com
3100,mediaserver-cont-dc6-2-v4v6.pandora.com
3115,mediaserver-cont-dc6-1-v4v6.pandora.com
3119,mediaserver-cont-ch1-2-v4v6.pandora.com
3152,fdz.flashtalking.com
3225,mediaserver-cont-sv5-3-v4v6.pandora.com
3340,gspe21-ssl.ls.apple.com
3382,spotx.tv
3393,rc2waycm-atl.netmng.com
3408,opx2waycm-atl.netmng.com
3409,js.spotx.tv
3497,fwapi.adsafeprotected.com
3519,fm.flashtalking.com
3563,pool.adizio.com
3607,audio-sv5-t1-1-v4v6.pandora.com
3630,audio-sv5-t1-2-v4v6.pandora.com
3661,audio-dc6-t1-2-v4v6.pandora.com
3665,audio-ch1-t1-2-v4v6.pandora.com
3678,audio-ch1-t1-1-v4v6.pandora.com
3709,audio-dc6-t1-1-v4v6.pandora.com
3780,ntracking.optimatic.com
3831,adserver.pandora.com
3964,as.jivox.com
3985,mobile.adsafeprotected.com
4043,engine.4dsply.com
4050,api.adsnative.com
4088,myway.com
4170,tuner.pandora.com
4173,dc-storm.com
4364,search.namequery.com
4624,verizonwireless.com
4643,bluekai2waycm.netmng.com
4691,spixel.adsafeprotected.com
4827,app.appsflyer.com
4843,mobile-static.adsafeprotected.com
4856,argo.svcmot.com
4894,static.adsnative.com
4912,playercdn.jivox.com
5046,pixel.bilinmedia.net
5065,syncva.vzmessages.com
5102,pm.adsafeprotected.com
5212,cdn.adsafeprotected.com
5369,cdn.avazutracking.net
5518,buy.itunes.apple.com
5532,media0.giphy.com
5596,media1.giphy.com
5597,media3.giphy.com
5661,cdn.engine.4dsply.com
5678,media2.giphy.com
5945,mm.melia.com
5947,dts.ushareit.com
5982,p7-buy.itunes.apple.com
6069,zdbb.net
6091,j2waycm.netmng.com
6146,p17-buy.itunes.apple.com
6167,p3-buy.itunes.apple.com
6210,p19-buy.itunes.apple.com
6230,p12-buy.itunes.apple.com
6242,mbis.vzmessages.com
6245,evs.jivox.com
6248,eu-gmtdmp.gd1.mookie1.com
6279,p24-buy.itunes.apple.com
6317,audio-sv5-t2-1-v4v6.pandora.com
6323,p20-buy.itunes.apple.com
6411,p9-buy.itunes.apple.com
6436,audio-sv5-t2-2-v4v6.pandora.com
6456,p14-buy.itunes.apple.com
6466,glympse.com
6485,api.glympse.com
6548,p11-buy.itunes.apple.com
6549,eyeota2waycm.netmng.com
6553,sumologic.com
6568,p23-buy.itunes.apple.com
6580,p18-buy.itunes.apple.com
6583,nyt2.dc-storm.com
6587,p40-buy.itunes.apple.com
6592,p32-buy.itunes.apple.com
6601,p45-buy.itunes.apple.com
6620,track.appsflyer.com
6647,p22-buy.itunes.apple.com
6672,impression.appsflyer.com
6687,p8-buy.itunes.apple.com
6727,p26-buy.itunes.apple.com
6730,j2waycm-us-wdc.netmng.com
6734,p42-buy.itunes.apple.com
6801,p16-buy.itunes.apple.com
6839,p41-buy.itunes.apple.com
6859,sandbox.itunes.apple.com
6873,p10-buy.itunes.apple.com
6881,mediaforge.com
6884,p27-buy.itunes.apple.com
6957,p21-buy.itunes.apple.com
6976,audio-dc6-t2-1-v4v6.pandora.com
6997,p35-buy.itunes.apple.com
7000,p25-buy.itunes.apple.com
7003,audio-dc6-t2-2-v4v6.pandora.com
7009,p2-buy.itunes.apple.com
7027,bevo-us-east-1.adsnative.com
7056,p6-buy.itunes.apple.com
7119,p50-buy.itunes.apple.com
7140,p46-buy.itunes.apple.com
7177,api-v.vzmessages.com
7190,p49-buy.itunes.apple.com
7192,intljs.rmtag.com
7196,p15-buy.itunes.apple.com
7198,embed.ly
7217,p44-buy.itunes.apple.com
7242,p48-buy.itunes.apple.com
7253,wondershare.com
7336,p36-buy.itunes.apple.com
7345,p33-buy.itunes.apple.com
7401,audio-ch1-t2-2-v4v6.pandora.com
7411,audio-ch1-t2-1-v4v6.pandora.com
7413,cdn.jivox.com
7414,p47-buy.itunes.apple.com
7484,p43-buy.itunes.apple.com
7485,geistm.com
7574,spectrum.com
7621,us-gmtdmp.mookie1.com
7656,clashofclans.com
7672,p29-buy.itunes.apple.com
7681,espn.com.br
7701,p38-buy.itunes.apple.com
7725,p55-buy.itunes.apple.com
7772,p30-buy.itunes.apple.com
7829,cm.ushareit.com
7860,p28-buy.itunes.apple.com
7895,endpoint2.collection.sumologic.com
7907,p53-buy.itunes.apple.com
7916,p52-buy.itunes.apple.com
7944,p31-buy.itunes.apple.com
7994,p71-buy.itunes.apple.com
8051,imsns.cequintvzwidml.com
8220,app.box.com
8338,cl1.apple.com
8366,w.visualdna.com
8486,p37-buy.itunes.apple.com
8604,p54-buy.itunes.apple.com
8682,ev.visualdna.com
8704,p70-buy.itunes.apple.com
8775,p56-buy.itunes.apple.com
8789,messaging-notifications.api.nytimes.com
8941,one.pandora.com
9008,alooma.com
9030,p51-buy.itunes.apple.com
9306,p34-buy.itunes.apple.com
9336,p58-buy.itunes.apple.com
9369,assetscdn.jivox.com
9524,p59-buy.itunes.apple.com
9566,mail.globo.com
9619,cf.ushareit.com
9637,peakgames.net
9651,p73-buy.itunes.apple.com
9665,p57-buy.itunes.apple.com
9680,query.hicloud.com
9684,elb.flashtalking.com
9728,p60-buy.itunes.apple.com
9903,lemonpi.io
9908,pixel.ad
9992,tremor2waycm-atl.netmng.com
10032,p72-buy.itunes.apple.com
10037,logicnow.us
10054,d.lemonpi.io
10110,insight.ucweb.com
10156,presentationtracking.netflix.com
10163,track-west.mobileadtrading.com
10177,ox-d.justpremium.com
10222,liveramp2waycm-atl.netmng.com
10224,centro.pixel.ad
10320,3gimg.qq.com
10342,api-cache.adsnative.com
10364,fsr.lenovomm.com
10414,res.wx.qq.com
10415,tagcommander.com
10503,api.peakgames.net
10572,inputs.alooma.com
10608,register.appsflyer.com
10774,mediaiqdigital.com
11023,gb-gmtdmp.mookie1.com
11083,nypi.dc-storm.com
11089,p39-buy.itunes.apple.com
11390,internet.sony.tv
11464,api.embed.ly
11793,rec.api.nytimes.com
11798,tags.mediaforge.com
11800,stats.mediaforge.com
11813,samsungresources.visionobjects.com
11820,adups.com
11828,vivo.com.cn
11834,mg-bid.optimatic.com
11913,dc3-vault.myvzw.com
11927,metro.co.uk
12144,s.zkcdn.net
12206,j2waycm-us-sjc.netmng.com
12298,m.qpic.cn
12339,ios.bugly.qq.com
12480,connect.qq.com
12586,cdn.adsnative.com
12974,bl.ecbsn.com
12981,cdn.embed.ly
13064,nan.netmng.com
13357,tracking.freckleinc.com
13516,goal.com
13687,myharmony.com
13699,polyvore.com
13865,gcm.netmng.com
13915,tbapi.search.ask.com
14005,bevo-eu-west-1.adsnative.com
14027,inbox.clashofclans.com
14047,geoip.newsdev.nytimes.com
14077,fdzcf.flashtalking.com
14122,la4-c2-chi.salesforceliveagent.com
14127,reading-list.api.nytimes.com
14161,cdn.alooma.com
14364,mx-gmtdmp.mookie1.com
14547,a-us-sjc.netmng.com
14551,avery-us-west-2-svc.logicnow.us
14571,markets.on.nytimes.com
14617,d.la4-c2-chi.salesforceliveagent.com
14638,syncor.vzmessages.com
14683,youdao.com
14749,it-gmtdmp.mookie1.com
14853,content.api.nytimes.com
14905,na.gmtdmp.com
14908,cdn01.boxcdn.net
14958,dispatcher.360in.com
14981,svcs.myharmony.com
15082,www.polyvore.com
15134,pgdt.gtimg.cn
15265,hertz.com
15340,hyprmx.com
15610,de-gmtdmp.mookie1.com
15665,exp.360in.com
15691,ucus.ucweb.com
15696,api.appsflyer.com
15837,i.gtimg.cn
15839,m.spotx.tv
15967,www.metro.co.uk
16027,abs.vzmessages.com
16185,luxup.ru
16464,mediabrix.com
The fallout list broken down to affected domains:

360in.com
360yield.com
4dsply.com
adizio.com
admedo.com
adnxs.com
adsafeprotected.com
adsnative.com
adups.com
alooma.com
apple.com
appsflyer.com
ask.com
avazutracking.net
bilinmedia.net
box.com
boxcdn.net
btstatic.com
cequintvzwidml.com
clashofclans.com
dc-storm.com
embed.ly
espn.com.br
flashtalking.com
freckleinc.com
geistm.com
giphy.com
globo.com
glympse.com
gmtdmp.com
goal.com
gtimg.cn
hertz.com
hicloud.com
hyprmx.com
icloud.com
jivox.com
justpremium.com
lemonpi.io
lenovomm.com
logicnow.us
luxup.ru
mediabrix.com
mediaforge.com
mediaiqdigital.com
melia.com
metro.co.uk
mobileadtrading.com
mookie1.com
myharmony.com
myvzw.com
myway.com
namequery.com
netflix.com
netmng.com
nvidia.com
nytimes.com
optimatic.com
pandora.com
peakgames.net
pixel.ad
polyvore.com
qpic.cn
qq.com
rmtag.com
salesforceliveagent.com
sony.tv
spectrum.com
spotx.tv
spotxchange.com
sumologic.com
svcmot.com
tagcommander.com
ucweb.com
ushareit.com
verizonwireless.com
visionobjects.com
visualdna.com
vivo.com.cn
vzmessages.com
wondershare.com
youdao.com
yume.com
yumenetworks.com
zdbb.net
zkcdn.net
(In reply to Christiane Ruetten [:cr] from comment #82)
> The fallout list broken down to affected domains:

Thanks for the list, :cr. Could you transform the list into an attachment to this bug? Easier for others to consume/download.
Attached list of affected hosts among the top 10k SSL Umbrella list.
Attached list of affected domains among the top 10k SSL Umbrella list.
We'll be running a regression scan against the full 1M Umbrella list tonight. The list will be waaay longer and slightly noisier.
(In reply to Christiane Ruetten [:cr] from comment #86)
> We'll be running a regression scan against the full 1M Umbrella list
> tonight. The list will be waaay longer and slightly noisier.

I'm doing that now. You just beat me to it. ;)
CR and I have been running scans simultaneously. My 10k host scan is here:

https://tlscanary.mozilla.org/runs/2018-02-23-11-56-37

She will likely finish her complete run before I do, so we can wait for her results. Spoiler alert: web is broken. ;)
Depends on: 1440839
The full regression against 496833 hosts run yielded 8434 SEC_ERROR_UNKNOWN_ISSUER regressions. The affected roots and their frequencies are (among a few seemingly self-signed roots in the error set that require further investigation):

4846,GeoTrust Global CA
1794,VeriSign Class 3 Public Primary Certification Authority - G5
881,thawte Primary Root CA
443,GeoTrust Primary Certification Authority - G3
207,thawte Primary Root CA - G3
101,GeoTrust Primary Certification Authority
83,VeriSign Universal Root Certification Authority
11,VeriSign Class 3 Public Primary Certification Authority - G3
Depends on: 1440957
I'm getting SEC_ERROR_UNKNOWN_ISSUER for evite.com on nightly.
GeoTrust Global CA -> GeoTrust SSL CA - G3 -> *.evite.com
Some other domains with GeoTrust certs are also affected. Personally I hit mojeid.cz (informing them now).
Depends on: 1440586
Before reporting affected roots, or individual domains or hosts, please check whether they are already covered by comment 91 or comment 90.
Depends on: 1441132
See Also: → 1436062
(In reply to Christiane Ruetten [:cr] from comment #94)
> Before reporting affected roots, or individual domains or hosts, please
> check whether they are already covered by comment 91 or comment 90.

In case of mojeid.cz it's GeoTrust Extended Validation SHA256 SSL CA. According to the SSL Labs test results here (https://www.ssllabs.com/ssltest/analyze.html?d=mojeid.cz&s=217.31.205.60&hideResults=on&latest) it actually is a certificate that will become invalid.
"www.mojeid.cz" is issued by "GeoTrust Extended Validation SHA256 SSL CA" which is issued by "GeoTrust Primary Certification Authority - G3" which is already on our list. No surprise there.

When a root cert is distrusted, naturally all its intermediates are distrusted as well, and that list can easily be extracted from the run log in comment 89, so no need to report all affected intermediates individually.

Or am I missing your point?
Depends on: 1441515
See Also: → 1441515
In addition to :cr's TLS Canary run, I'm scanning the top1m for symantec distrust in the TLS Observatory. It's slower, but has more details.
Current status is posted here, which I'll update as the scan progresses: https://gist.github.com/jvehent/0fbfb71bae06e48163f276592417079a
Depends on: 1441511
Note: it seems this bug's effects are now preffed off on trunk, via bug 1437754.  If you want to get the strictness back, you can set about:config pref security.pki.distrust_ca_policy to 1.
The strictness will come back in bug 1442075
Here's a visualization of the Internet's healing process: http://ec2-34-218-48-154.us-west-2.compute.amazonaws.com:8000/ . We'll probably be running regular TLS Canary scans there for the next few weeks, but after that the link will go away.
Somehow Amazon (at least .com, .ca and .co.jp) uses VeriSign Class 3 Public Primary Certification Authority - G5 instead of their own root but it's not included in the 1M list or even 10K list. Are we probably missing more?
Keywords: site-compat
The changes in Firefox 60 only affect Symantec certificates issued after 1-June 2016. The certificates I see on amazon.com and amazon.ca were issued in 2017 and will need to be replaced before Firefox 63 is released in October.
Depends on: 1443497
TLS Observatory stats from this week, mostly confirming TLS Canary's data and projecting to Fx 63:

Sample size: 542,112 sites from Cisco Umbrella top1m (the rest doesn't support TLS)

Distrusted in Firefox 60: 9,421
               but 2,930 of those certs expire before 60 is released
               so only 6,491 need action (1.19% of TLS sites, 0.64% of all sites)

Distrusted in Firefox 63: 88,537
               but 45,768 of those certs expire before 63 is released
               so only 42,770 need action (7.88% of TLS sites, 4.27% of all sites)

Domains impacted, once subdomains are removed: 17,508
Depends on: 1444687
Depends on: 1444876
Unfortunately last week someone shut down the EC2 instance responsible for scanning and plotting, and it now has a new IP address. You need to use http://ec2-54-244-28-222.us-west-2.compute.amazonaws.com:8000/ from now on.
The instance was shut down again. New address is http://ec2-52-88-196-97.us-west-2.compute.amazonaws.com:8000/ .
The scanning/plotting instance was shut down again. New address is http://ec2-52-36-248-35.us-west-2.compute.amazonaws.com:8000/ .
Interestingly https://ftp.isc.org/ is also broken due to this, whereas https://www.isc.org/ isn't.  Maybe they should be notified... :)
The scanning/plotting instance was shut down again. If you still like to follow along the development, its new address is http://ec2-35-167-193-121.us-west-2.compute.amazonaws.com:8000/ .
I moved the TLS Observatory stats to a spreadsheet where the weekly scans will be progressively added. The chart there also shows the downward trend. https://docs.google.com/spreadsheets/d/1bHc6902vPspec-uzdlHFi9AupCnZcvqYLHnz89Hyh24/edit#gid=0
Depends on: 1488875
You need to log in before you can comment on or make changes to this bug.