This site uses a Symantec cert

[intr0]

Attacched is a screenshot of the warning that first appeared in Mozilla’s Observatory ~2 weeks ago. I’ve been checking evry so often to see if this happened to be a hiccup on Mozilla’s end, but apparently it’s not. The thing is, Firefox is @ 68 already; I’m not sure of where Chromium is at but likely it’s also passed the dates detailed in what essentially appears to be an ominous warning. If anyone with knowlege of just how Clouflare will deal with this issue as it’s an issue which is fairly important, to state it mildly.

Thank-you.

[_az]

Fake news! Let’s dig into what is actually happening.

The observatory site farms work out to the Mozilla TLS Observatory project.

In there we can locate the scanner that is responsible for producing the Symantec distrust warning.

After calculating the SKI/AKI of the root and intermediate, we cannot find it in the blocklist (or the whitelits, for that matter).

Huh? If we look at the actual JSON response from that scanner, we get the following result:

path uses a root not trusted by Mozilla: C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root (id=16)

Not sure what that means. There’s some helpful comments, though:

mozilla/tls-observatory/blob/a3c1b6cfecfd7a0cf8f64c6bdc2b1e1d6a87e06c/worker/symantecDistrust/symantecDistrust.go#L251-L261

The tool thinks that Mozilla does not trust this root. But that’s not actually true.

The root is listed on https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport and Censys.io agrees that Mozilla trusts that root.

The conclusion seems to be that the TLS Observatory tool needs to update its trust stores, and that the discontinuity between “Mozilla doesn’t trust this root” and “This is a Symantec certificate!11!” needs to be fixed.

[intr0]

I do appreciate your reply, though you’re forgetting Chromium. Also, I see nothing of why this is a recent phenomenon. So, hiccup it is. It happens. No need to get all Trumped out about it. Peace.

[sdayman]

I’ve seen that warning before, felt it was a glitch, then moved on and forgot about it. Just checked again and it’s (still) there. Cloudflare doesn’t even use Symantec certificates. I don’t think they ever did.

p.s. Kudos for your A+, and a 130/100 score. You’re doing a stellar job of locking down your policies. You’ve beat my high score of 125.

[intr0]

And you’ve hit the nail on the head - Symantec? Hence my question, as the warning is odd. Either I was missing an unseen cert (not at all likely) or it was a hiccup. I think it’s of value to get these quirks that may very well be seen as what (this one) appears to be on its surface - a glaring red WARNING sign for all Cloudflare customers - by those who simply see the red warning and take it at face value. This way the issue is right here, in the open, for all the public to see if they take the time to search terms such as - Cloudflare Symantec Cert Warning Mozilla Firefox Chrome. That way they’ll hopefully be directed here to see the discussion regarding the ghost in the cert machine.

And congrats on your 125/100. Adding a SameSite tag to Set-Cookie will give you the additional five points.

Edit: regarding the cert warning, check out this Google Security posting in the Google Security Blog - Chrome’s Plan to Distrust Symantec Certificates - from Sep 2017. It also sheds light on the situation as Symantec sold cert issue.

Starting with Chrome 66, Chrome will remove trust in Symantec-issued certificates issued prior to June 1, 2016. Chrome 66 is currently scheduled to be released to Chrome Beta users on March 15, 2018 and to Chrome Stable users around April 17, 2018.

If you are a site operator with a certificate issued by a Symantec CA prior to June 1, 2016, then prior to the release of Chrome 66, you will need to replace the existing certificate with a new certificate from any Certificate Authority trusted by Chrome.

Additionally, by December 1, 2017, Symantec will transition issuance and operation of publicly-trusted certificates to DigiCert infrastructure, and certificates issued from the old Symantec infrastructure after this date will not be trusted in Chrome.

Around the week of October 23, 2018, Chrome 70 will be released, which will fully remove trust in Symantec’s old infrastructure and all of the certificates it has issued. This will affect any certificate chaining to Symantec roots, except for the small number issued by the independently-operated and audited subordinate CAs previously disclosed to Google.

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements. During the subsequent investigation, it was revealed that Symantec had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight, and had been aware of security deficiencies at these organizations for some time.

This incident, while distinct from a previous incident in 2015, was part of a continuing pattern of issues over the past several years that has caused the Chrome team to lose confidence in the trustworthiness of Symantec’s infrastructure, and as a result, the certificates that have been or will be issued from it.

After our agreed-upon proposal was circulated, Symantec announced the selection of DigiCert to run this independently-operated Managed Partner Infrastructure, as well as their intention to sell their PKI business to DigiCert in lieu of building a new trusted infrastructure.

Site operators that need to obtain certificates from Symantec’s existing root and intermediate certificates may do so from the old infrastructure until December 1, 2017, although these certificates will need to be replaced again prior to Chrome 70. Additionally, certificates issued using validation information from Symantec’s infrastructure will have their validity limited to 13 months. Alternatively, site operators may obtain replacement certificates from any other Certificate Authority currently trusted by Chrome, which are unaffected by this distrust or validity period limit.

[sdayman]

@intr0

Adding a SameSite tag to Set-Cookie will give you the additional five points.

I noticed that…how did you pull that off? The only cookie I have is cfuid, and I don’t have control over that.

[intr0]

Workers.

EDIT 1:
@sdayman If you’d like to raise your score to 135/100 from 130/100, then take advantage of Subresource Integrity via the require-sri-for style script Content-Security-Policy header. However - and here’s the catch - it must be used for at least one script and must be used for all that you do use. Example: for my redesigned site, one script I do use with it is the following:

<script src="https://cdnjs.Cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js" integrity="sha384-ZOED+d9HxogEQwD+jFvux96iGQR9TxfJO+mPF2ZS0TuKH6eWrmvPsDpO6I0OWdiX" crossorigin="anonymous"></script>

It may seem odd that using javascript on your site is better than not using any javascript, insofar as your site’s security is concerned; however, the security of any javascript used through Subresource Integrity sufficiently ensures that any javascript used cannot be tampered with. But if you’d like those last 5 points, then you’ve got to do it. And it is admittedly quite enjoyable using Workers to achieve 135/100.

EDIT 2:
__Secure-Max-Age=0; path=/; domain=.intr0.com; HttpOnly; Secure; SameSite=Strict

The above is what I set for my domain. And it does not interfere with Cloudflare’s cfuid cookie.

EDIT 3:
newHeaders.set("Set-Cookie", "__Secure-Max-Age=0; path=/; domain=.example.com; HttpOnly; Secure; SameSite=Strict");

Note that the prefix __Secure- prefix must use the double underline __ not a single underline _ and the dash - is necessary as a suffix for the __Secure- prefix for the Set-Cookie header.

—-—-—-—-

where Max-Age=0 ended up resulting in my cookie being named Max-Age, which is fine.^(1) Experimentation will enable you to use what you will for cookie-name=cookie-value; Max-Age=n. Though Max-Age=0 is not explicitly disallowed by web browser engines, it is discouraged, though for what reason I’m unaware since it’s not depreciated and still in use.

Edit: also, if one were to use the actual Max-Age of 0, it would require setting browser cache expiration to respect existing headers, turning off Always Online, and bypassing the cache in (a) page rule(s).

Edit: The changes to the Cloudflare cache directives using the dashboard only effect Cache-Control header. I.e., if one wishes to have a Cache-Control header of private, max-age=0 the changes as outlined in the initial edit should be followed.

(1) Applied to pre-edited information; left in place for historical purposes.

[sdayman]

That’s weird. If I don’t have a cookie for my site, I get a 125. But if I add a cookie with Samesite, I can get a 130. And the Cloudflare cookie hasn’t changed.

[intr0]

It’s the SameSite flag that does it. CSRF protection.

But, yeah, weird. And that’s not the only site that shows only your cookie. There’s a useful app on iOS

that will also show only the cookie you set via workers, rather I should say incorporate SameSite as an actual flag, as well they should. Hardenize.com does as well as most security focused sites.

[_az]

@intr0

you’re forgetting Chromium

Chromium is irrelevant to this. The warning you experience is due to the specific bug in TLS Observatory’s logic that I described.

@intr0

Also, I see nothing of why this is a recent phenomenon. So, hiccup it is. It happens

I … wow.

The reason you believe it is a “recent phenomenon” is because Cloudflare uses a mix of CAs to issue certificates for your domain, and this changes day-to-day.

For much of the time you’ve been using Cloudflare, your domain has been signed by Comodo roots (which are unaffected by the TLS Observatory bug). Since May 17 2019, you’ve been using the Cybertrust root.

So whether you encounter the (incorrect) warning or not basically depends on the root selection strategy used by Cloudflare at any instant in time. Your certificate gets re-issued often, since Cloudflare only uses 3 month validity periods. If the SAN mix changes, it might get re-issued even more often than that.

[intr0]

Sorry, CHROME. If it’s not related, why the posting in Google’s security blog? Please don’t answer; it’s rhetorical. I’d hate for this to devolve any further.

[intr0]

• Set-Cookie__cfduid=d950de6e9a2b1be44869f0ee8d0e9b0b81563676404; expires=Mon, 20-Jul-20 02:33:24 GMT; path=/; domain=.intr0.com; HttpOnly; Secure

• Set-Cookiemax-age=0; path=/; domain=.intr0.com; HttpOnly; Secure; SameSite

From: https://httpstatus.io/

It’s the only tool I’ve used yet that reveals both cookies.

[intr0]

https://www.digicert.com/replace-your-symantec-ssl-tls-certificates/

DigiCert owns and operates the CyberTrust root cert ecosystem. So, some more evidence, this time coming directly from the SSL certificate issuer.

I was satiated with Cloudflare doesn’t use Symantec certs, and technically it doesn’t, since CyberTrust is owned by DigiCert who acquired Symantec’s web security business in 2017. This is where the catch-22 comes in, which it is. But no major vendor is clear on this point, except Microsoft, who lists the exact certs that they are working with DigiCert to depreciate. So, essentially, Symantec dumped their problems onto DigiCert and its ecosphere of CAs. Even still, it’s an issue because it’s an issue that will be taken at face value by many, many people due to what Google, Mozilla, & DigiCert say.

@cloonan @Judge @cs-cf

[cs-cf]

This distrust of certificates happened last year. As you mentioned your browser version is well past the alert version posted on that website.

@_az

The conclusion seems to be that the TLS Observatory tool needs to update its trust stores, and that the discontinuity between “Mozilla doesn’t trust this root” and “This is a Symantec certificate!11!” needs to be fixed.

I’d tend to agree.

[edit] By I ‘tend to agree’ I mean your analysis was spot on. This is a problem with the code being run by a 3rd party. There’s lots of poor code that checks for problems with websites out there (If I have not answer another question about mxtoolbox and our NS serial format…). So nothing for Cloudflare to deal with as @_az demonstrated it is an issue with the tool not Cloudflare’s certificates.

[intr0]

As well as Google and DigiCert, via their respective writings that are currently online; the Google Security Blog & DigiCert’s main site are where each is located. I’d be interested in your thoughts on each. The Google posting discovered after the alert listed Chrome as well as Firefox, which is not past the stated version for those using an older (though still supported) ESR release, such as is used by Debian (I believe it’s 60.x ESR, which is a standard practice for Debian. Debian had too many problems in its previous release (9, code name Stretch), however 10 code named Buster has been greatly improved, reintroducing the stability Debian is famous for (over 1300 devs worldwide helped in its recreation), so I expect it to at least regain ~50% of its user base that abandoned it during the lifetime of Debian 9. This is relevant for more than those who use Debian as their OS, as there are many other operating systems which use an ESR release of Firefox that’s yet to reach the stated version that will mistrust the certificates. And again, Mozilla is not the only source of this information; in fact it the final schedule was created by a collaboration between Mozilla & Google, who together created the “calendar”, for lack of a better word at the moment, due to information that came directly from the source - DigiCert. Hence the “on or after” and “before” issuance dates. The Firefox & Chrome release schedules was also a collaborative effort between Mozilla & Google to allow those with the mistrusted DigiTrust (and its ecosphere of CAs it allows to issue root trust certs such as GeoTrust (who Let’s Encrypt chains its root to until a date in the near future when it will become its own CA after many years of relying on GeoTrust to be trusted by browsers) as well as CyberTrust. This is where the problem arises, or I should state as I did in my original posting the hiccup, as Cloudflare’s use of CyberTrust, a DigiCert CA, for its root certificate issuance, is the cause of the “hiccup”. And whereas Mozilla’s Observatory, as well as its Certsplainer site which shows the CyberTrust root as not trusted by the Companies and one non-profit web browser suppliers and (2 or 3? engine creators now that Microsoft abandoned its in-house web engine development and is using Google’s Chromium engine as its base for Edge; i’m unsure of Apple though I think it’s Safari browsers are developed in-house. Apple is too controlling of its ecosphere to not do so and Safari is a whole other creature relative to Firefox and Chrome when it comes to features, design, etc., for better or worse). If the attached screenshot is delivered in this reply, one may visually see the red X’s, if not then the certificate in question is https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=16 or 16 if simply using the search function. However, the certsplainer decoding function is a useful tool, except, apparently, in this case. Point being is that considering the mass numbers of users Cloudflare serves, I would personally think it in the best interest of Cloudflare’s public / corporate image to take some sort of action, perhaps simply a blog posting in order to clarify the statements of Google, DigiCertm and Mozilla. Thank-you for your time. I do hope Cloudflare acts on this, regardless of where the fault in this matter lies, as Cloudflare is now publicly tangled up in this due to the root certs if issues to its user base. It can only help to not scare off potential and / or current paying customers.

(Attachment publicKey - {pii redacted} - dbd0a5f5e3cc2e74e9570c13d574c382305cd5fe.asc is missing)

[mnordhoff]

@intr0

DigiTrust

Symantec?

@intr0

GeoTrust (who Let’s Encrypt chains its root to until a date in the near future when it will become its own CA after many years of relying on GeoTrust to be trusted by browsers)

Let’s Encrypt uses IdenTrust, a CA unrelated to Symantec or DigiCert.

@intr0

CyberTrust, a DigiCert CA

DigiCert in general, and the CyberTrust roots they previously acquired from Verizon, are not part of the Symantec distrust.

---

You’re right that this bug may alarm Cloudflare customers, but anyone can contact Mozilla about it.

[intr0]

IdentTrust, you’re correct. My mind is elsewhere as this is becoming old. Everyone is focusing on Mozilla when this was a collaboration between Google and Mozilla using information from DigiCert themselves. Yes, DigiCert acquired Symantec’s SSL business in 2017.

Anyone can contact Mozilla about it.

• As well as Google and DigiCert.
• So essentially what you’re saying is every Cloudflare customer must contact outside sources instead of having a resource easily accessible directly from Cloudflare. Instead of a simple blog post educating customers about this “issue”, you’s have everyone who is concerned due to the Google Security Blog, the DigiCert website, and Mozilla’s TLS observatory essentially warning every Cloudflare customer who has an SSL cert purchased a dedicated cert or who has a free cert go through the hassle of contacting a non-profit or one of two corporations rather than reading what would be a short blog posting within Cloudflare itself? As a former business owner and current FOSS dev & volunteer, I can tell you with certainty, from nearly 2 decades of running a business, that what you are suggesting is not good business practice. It’s quite obviously not good business practice, in fact. Moreover, I would prefer to hear from an actual Cloudflare employee or better yet see a blog posting go up from a Cloudflare employee regarding this “issue”. Peace.
• intr0

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

(Attachment publickey - {pii redacted} - 0xDBD0A5F5.asc is missing)

[mnordhoff]

No, I’m saying one person – Cloudflare customer or not – can report the issue to the TLS Observatory developers or operators, so it can be fixed.

[intr0]

This community has really devolved since I first joined. Doubt I’ll be back. I don’t need the hostility, open or of the passive aggressive type. It was a mistake to even post anything again, actually. Who knew i’d be attacked like this and like _az. Just for posting. For posting. Really, what’s wrong with people? Is there no such thing as civility anymore?

(Attachment publicKey - {pii redacted} - dbd0a5f5e3cc2e74e9570c13d574c382305cd5fe.asc is missing)