Distrust of Symantec TLS Certificates | Hacker News Reader

Distrust of Symantec TLS Certificates

blog.mozilla.org

307 pointsasymmetric118 comments

There's been downvoted comments below that, to me, seem to complain of Mozilla unfairly blindsiding domain owners.

I disagree, based on my own personal experience. This has been coming for a while, with plenty of forewarning.

My employer uses certificates from one of Symantec's brands. Last year, we began to get notices that Chrome et. al. would be distrusting the certificates issued from the old Symantec root this year, and that we would need to claim our free replacements issued from the new trust root that is replacing Symantec's. And it's not been just one notice, we've been getting them regularly. And in addition to the automatic form emails, the sales rep assigned our account personally reached out to us to make sure we were getting this taken care of. We are not a large company, either; we have less than 100 employees. DigiCert is taking this transition seriously.

So IMO, if someone gets blindsided by their website breaking because of the Symantec root distrust, then they have only laziness and/or incompetence to blame, whether it's their own, or that of their website operator. Those who's job it is to make sure that doesn't happen have been warning about it for nearly a year now.

This is factually wrong. There wasn't plenty of warnings and google ignored their own roadmap.

Google announced in October 2017 that they will block Symantec certificates in October 2018. Leaving a year to upgrade, fairly reasonable considering most certificates must be renewed early.

However, Chrome blacklisted Symantec since April 2018, 6 months early. Taking a lot of people by surprise.

You mean this roadmap? https://security.googleblog.com/2017/09/chromes-plan-to-dist...

That plan clearly states that all Symantec-issued certificates with a not-before date before June 1, 2016 would be distrusted in April. Is that not what happened?

Yes, this roadmap. It was not followed. All certificates were blacklisted in April, irrelevant of their date.

Are you sure? Paypal.com's Symantec-issued certificate still works in Chrome, at least on my PC: https://www.paypal.com/

I couldn't be more sure. My company had hundreds of certificates issued from Symantec, who was our main supplier. Basically, all our websites broke the day Chrome was updated. It was hell.

If it were actually allowed, I would upload some of the certificates and write a blog post to show you.

Paypal has an EV, I don't have EV. Maybe these were not blacklisted. The rest was.

When I visit paypal and open up the console I see the following warning :

The SSL certificate used to load resources from https://www.paypalobjects.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.

Can confirm here PayPal's Symantec Class 3 EV SSL CA - G3 signed certificate validates in Chrome 68 and 69 but returns NET::ERR_CERT_SYMANTEC_LEGACY on Chrome 70

They really need to update their certificate soon

Is it possible that you’re using a canary version of Chrome? Check chrome://version/, for me I see version 69 and I can go to https://www.paypal.com/ and see that the Symantec EV cert is still valid, which was issued in 2017. In particular, if you see version 70, I would expect you to get errors visiting PayPal, just like the roadmap says.

Personally I think it’s bad practice to have a cert last more than a year in the first place, due to a number of both operational concerns and security concerns, but that is neither here nor there.

This is not my experience -- can you show an example of a site with a cert that has been untrusted early from chrome? They specifically call out the types of certs and their sign dates in the timeline and everything I have seen has matched this timeline. They have, however, had very verbose logging warning in console that the cert on a given site _will be_ distrusted well ahead of time.

https://www.republicservices.com/ is a site with a non-EV Symantec-branded certificate from August 2017 and it still works in Chrome 69 (and is blocked in Chrome 70 with a NET::ERR_CERT_SYMANTEC_LEGACY error).

www.McDonalds.com is another site with a non-EV certificate that will be blocked by Chrome 70, albeit with the GeoTrust brand instead of Symantec directly. Surely McDonalds has a large enough IT division to have noticed and updated by now if Chrome had been blocking their site since April.

Uh, we used to use them, and switched in June. Our certificates behaved normally. I have no idea what was going on with yours, but clearly "all certificates" were not.

We also received I don't know how many notifications of the impending changes. They were plentiful enough that it got annoying. Assuming one actually has valid email addresses to which attention is paid for these communications.

I’m not sure what’s the point of posting this conjecture 20 times without providing any pointers for people to check if it is actually true.

Nobody on the Internet appears to have noticed but you.

http://www.googblogs.com/distrust-of-the-symantec-pki-immedi... The timeline of alpha and beta releases may have confused you.

This is a good point, and to add to this, some companies don’t take communication channels between the company and their certificate provider seriously. Sometimes the CA is left with the email address and phone number for someone who left the company over a year ago, and if you don’t have a good technical contact, you can spend a lot of time calling around until you find somebody who knows what’s going on with SSL.

That said, anyone who doesn’t have a big enough IT department to properly manage a certificate should be paying someone else to do it, it’s just that there are a lot of ways that contact information goes stale and documentation gets lost.

Well, a specific example that's going to bite _plenty_ of medium to large sized corporations is that you have a pattern like this:

Big Corp's Division Z need a cert for their new web site https://www.division-z.example/ and so Bob buys it with his corporate credit card, and gives as contact details bob@bigcorp.example. He buys, let's say, a Verisign SSL certificate.

Six months later Bob leaves to work at some other company. Bob's email is probably now blackholes, or maybe it's going into a never read "Bob's emails" folder of Bob's previous manager.

DigiCert, being conscientious, send email to bob@bigcorp.example warning that Verisign certs were a Symantec product (Symantec bought the brand and CA keys from VeriSign, or maybe from some other operator which in turn bought them from VeriSign, long ago)

But that email will either get delivered and silently go unread, or it'll bounce, but leaving no sign it needs to go to anybody else in particular instead of Bob.

Months later the cert stops working, as scheduled, and Steve, who is now responsible for this site, thinks DigiCert is somehow at fault. How were DigiCert supposed to guess that they needed to contact Steve?

Role accounts are the Right Thing™ so that the email goes to the person whose job is to care about the subject, not to some random individual who may not even work there any more. But they aren't enough, you also need mechanisms in place that ensure it's somebody's job to care, otherwise the role account emails just go in a folder and are never read.

So, sure, "incompetence" and not DigiCert's fault, nor Mozilla's but it's very widespread and you should be astonished if you work somewhere that does NOT have this problem in some form (maybe you have SSL certs locked down, but it turns out nobody is making sure you pay the electricity bills for outlying offices, or there's not actually anybody in charge of making sure payroll happens...)

Returning to SSL/TLS certificates though, any medium sized or larger organisation ought to be paying attention to the Certificate Transparency system. To do this properly you need to know all the eTLD+1s your organisation controls (this may be a non-starter in really sprawling organisations, but that's already a problem that needs fixing) but then you can know exactly what certificates exist for your names, who issued them, and why.

In most cases you don't _want_ Bob buying certificates on the company credit card anyway. Not just because it's cost inefficient (ignoring Let's Encrypt bigger organisations can get a commercial CA to cut them a deal for a fixed price or a steep discount per cert in exchange for doing one big Purchase Order rather than hundreds of credit card payments) but because it's organisationally a problem, it has security consequences, and it's another asset you're probably not tracking properly as a business.

Oh I know that it's widespread, it happened here; the guy who's job it was to care left and didn't pass on knowledge when he did. It is because there was a a role account assigned to comms about TLS certs that the notices were, well, noticed. I've worked in large orgs where comms are even worse.

But my point was that this is not some reckless sudden move by the browsers or DigiCert. In my observation, they have been earnestly and diligently working in good faith so people don't get bit by the transition.

Question: with such big news going on for such a long time, how does not even one person -- whether manager or otherwise -- just take 5 seconds to ask if they are prepared for it? It's not like the reporting on this was just in some dark corners of the internet... /some/ people in a given company should have at least heard something was going to happen to Symantec certificates.

Because there are tickets to close before the whistle.

I will add that in many "bigger orgs" they rely on external services/audits to identify certs signed outside of their process and use tools of the trade (like CAA records) to restrict certs being generated willy-nilly. If you are in a large org that does not do this -- raise it to the CSO. The fact that there are rogue certs in an org that may fail because of this CA removal action is the least of the orgs concerns.

Exactly. Just about every organization I've worked for has gone through a consolidation phase where DNS registration and certificate issuance is consolidated and formalized.

You don't have to get very big before these issues surface and cause tons of problems and toil.

Didn't Hotmail have some problem where microsoft took over and forgot to pay for the domain name [0]?

[0] https://whoapi.com/blog/5-all-time-domain-expirations-in-int...

I was a technical lead for a project involving a) governments and b) lots of income from taxpayers, and I noticed this warning about Symantec certs a while ago from a Qualys scan I ran on the third-party payment website. I told my manager and our client about this several times before being laid off, and I would bet they never did anything about it. I'm wondering how this is affecting them.

When it actually /breaks/ something they'll divert resources to fixing it.

Also, there is a warning in Chrome dev tools console.

I've received those emails as well. The emails came from our domain registrar. We don't buy certificates from our domain registrar. Adding to the confusion the email refers to Symantec certificates of which we don't have any, I even double checked the certificate chain and Symantec wasn't involved.

So, for the longest time I assumed the emails were a phishing scam and disregarded them. Only today when I tried testing with Firefox did I realize that several certificate brands were handled by Symantec and that YES I was affected.

So, yes there has been plenty of forewarning, but yet was surprised today.

I'm curious if you received the same emails I did. We got ours from our cert vendor, so I suppose that's as about as direct as it can get. If your domain registar was crafting their own, then I could see how you might have gotten blindsided. There's always a risk of information loss when the game of telephone comes into play.

When I first started looking at this myself, I was surprised at just how many TLS cert brands Symantec held: damn near half of them.

I understand the rationale behind all of this, but I would get pissed off if Google sent me an email that basically says "do what we tell you to do or we will take your website offline"

That would be bad. It's not what's happening.

What's happening is "update your security on the thing that you have already got security on, or else at least two of the most popular browsers will mark it as insecure; also, you will lose points in our search engine".

They are getting close to a monopoly in the browser market and a monopoly in the search market, so yes, this is exactly what's happening. You can pretend it's not a big deal because now they are using their power for good (I guess), but you don't know what they may do next.

I don't disagree with their existence being a near monopoly at this point.

That said, slippery slopes aren't usually the strongest places from which to wage an argument. We're not talking about what they might do next. We're talking about this specific instance.

Wow, I didn't realise how many non-conformances there were with Symantec. It certainly looks like they had enough chances to get their houses in order and didn't!

I wonder what the root problem was? They didn't care, they didn't think anyone would do anything or they are just a large sloppy corporate who can't run a group properly?

I've wondered the same. Certificate trust was absolutely crucial to their business. The only thing I can think is that the leadership was oblivious to this. Maybe they didn't understand how certificates work.

Sell more certificates, make more money. Anything which gets in the way of making more money (like security) should be reduced or eliminated, with the right touch you can get bonuses / promotions for meeting fiscal goals and leave your successor to deal with the aftermath.

They might understand how certificates work but that doesn’t mean they know how to set up an organization with the right incentives to do it correctly.

Interestingly, I looked up the symantec CEO. He was previously the ceo of Blue Coat. Blue Coat is a maker of man in the middle proxy appliances for businesses to spy on their employees. They controversially got root certificate authority. Which could of course be used to mitm SSL sites (which they promised and crossed their heart they would never do).

https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/

Didn't someone at the Tor Project analyse these Blue Coat MiTM boxes and find a cross-signed intermediate signing certificate preloaded, with the option to load your own signing cert so one could MiTM with ease? This was more than a few years back...

Symantec told us that there was a clear separation between the Blue Coat interception business and the CA business. Now, whether we should believe that having distrusted Symantec is a reasonable question, but of course distrusting the Symantec CA function also makes the question rather academic.

For users with Certificate Transparency checking (basically, Chrome) any dubious MITM certificates would have to be logged to show up as trusted public certificates. So there would not only be a smoking gun in the sense of the MITM cert being sent to all browsers that connected, it would be permanently preserved.

In addition Mozilla has an ongoing programme of trying to discover all the intermediate CAs that actually exist, partly because this occasions them to find various intermediates that probably _shouldn't_ exist and get them blacklisted. So this means if a intermediate exists and then you say you didn't realise it was being abused, you have the problem of explaining why you didn't report that it exists. If you say it's because you didn't know, it makes things worse - like if you say you didn't tell the IRS about the money because you got it when committing an armed robbery you weren't previously in the frame for - because that means your CA root was used to sign things you don't have a record of, and so obviously we can't trust your root any more...

My impression: For years it was common practice that when CAs messed something up it would cause some complains, but no real consequences. The large CAs thought they were "too big to fail". They thought it would just go on like that. They (and many others in the industry) didn't believe that Google was serious when they threatened with browser removal. When they realized Google was serious it was too late to change their course.

It also probably helped that the CA business wasn't Symantec's bread-and-butter.

Corporate leadership at the board room level is often resistant to the idea that oversight is their job, even though it is literally their only job. (Insert "You Had One Job" meme image). In many cases these people are paid (especially on a per hour basis) more than anybody else in the entire organisation, they ought to be working _very hard_ to deserve this money, and at most corporates they do little or nothing.

Did Symantec's shareholders get the board responsible for this... replaced? Did they at least get a big cut in their wages given that they're apparently no good at their jobs? Nope.

The Web PKI in my not at all humble opinion is doing a better job of handling this problem today than, for example, many actual bona fide regulators. When Symantec kept trying to offer up little bits and pieces (e.g. let's wind up this lucrative Korean partnership programme we've secretly been running for years that had no effective oversight...) they were told it wasn't enough.

In the end this distrust that you're seeing now was mandatory but it was not intended as a "death sentence" for the Symantec CA function pe se. Symantec were told to go find somebody whose leadership we could trust, and let the trustworthy outfit physically run the CA (with Symantec's brands) while Symantec got their shit together and tried again in a year or two. In the process of negotiating such a deal with DigiCert Symantec instead sold their entire CA business to them, which everybody seems to have (in some cases grudgingly) accepted is a good enough outcome.

DigiCert did a better than might be expected job of this from a technical point of view, and I hope that it works for them commercially as a result.

[Edited for clarity]

Chrome doing likewise: https://security.googleblog.com/2018/03/distrust-of-symantec...

Chrome did this first, so any wide effect (in yall's organsiations) should already have been noticed by now, due to this.

As I understand it, Chrome and Firefox are both operating under the same policies with about the same timetables. Full distrust doesn't come until Firefox 63 / Chrome 70 - neither of which are stable releases yet.

The limited distrust (for older certs issued prior to June 2016) was activated in Firefox 60 and Chrome 66 much earlier this year.

That's factually incorrect.

Google blacklisted ALL Symantec certificates since Chrome 66, in April. The roadmap announced the change for October but they did it 6 months earlier, ignoring their own roadmap.

As the OP says, organizations using Symantec have already been hit very hard, by surprise.

Do you have a source for that? Google's KB articles still reference Chrome 70 [1], and I can't find another reference to this anywhere else.

Paypal.com is still operating with a Symantec signed cert - issued by "Symantec Class 3 EV SSL CA - G3". Works fine in Chrome 68. (and not in Firefox with the security.pki.distrust_ca_policy override set)

[1] https://support.google.com/chrome/a/answer/7662561?hl=en

I worked at a large company whose sole supplier was Symantec. Everything has been blacklisted since April.

Similar environment except for the blacklisting didn’t happen to us. Any chance some wires were crossed and someone pushed out a policy explicitly distrusting the CA?

I think a source implies an authoritative source and not an anecdotal source.

Yeah. Not true. I visit many sites with Symantec certs in Chrome 69 that don't work in Chrome 70

This isn't true. Chrome itself proves this when loading a site affected by wave 2 of the distrust:

"The SSL certificate used to load resources from https://(domain) will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information."

Everything was being done in 2 waves. First wave was Chrome 66, second wave is Chrome 70. See Google's link above for the specifics.

Source: Chrome's own warnings and that I work for a business that deals heavily in SSL sales.

Apple¹ and Mircosoft² are doing the same. Additionally anything that uses Chromium's trustlists (Vivaldi, Electron, etc) will also distrust old Symantec & co's certs.

1: https://support.apple.com/en-us/HT208860 2: https://knowledge.digicert.com/alerts/ALERT2562.html

EDIT: Its also worth mentioning that this isn't just limited Symantec certs but also will include GeoTrust, thawte, & VeriSign certs. Symantec's cert business has now been taken over by DigiCert so there is a means for valid reassurance.

EDIT2: Also it will effect RapidSSL. Totally forgot about them.

You can enable this now in Firefox 62 (latest stable)

> In advance of removing all trust for Symantec-issued certificates in Firefox 63, a preference was added that allows users to distrust certificates issued by Symantec. To use this preference, go to about:config in the address bar and set the preference "security.pki.distrust_ca_policy" to 2.

It's been obvious to me for quite a while that EV etc only really tells you "this person paid $$$ to get a cert" rather than anything about the site being trustworthy or being who it says it is. I wouldn't bat an eye if 10 years from now major browsers distrusted everything but letsencrypt. Once the letsencrypt project comes out with a comparable solution for code signing, there is really no more reason for paid cert companies to exist. They don't check shit and it's super easy to get fraudulent certs so the value of what they provide is $0.

I would bat an eye because it's never good to rely on a single point of failure.

Imagine, for instance, that at some point, LE is the only trusted CA for code-signing. If its root key gets compromised for some reason, how are we supposed to move to a new CA if the auto-updaters cannot trust the old CA anymore?

True. They should maybe consider breaking up their operation into 20 or so root certs.

As much as I'm tempted to agree, decentralization perhaps risks even more. Opsec compromise is only one SPOF for a signing service; the state might coerce the CA into handing over the keys or issuing an intermediate for MitM.

Do you shard across 20 nations? If so, you have to contend with 20 intelligence agencies. It might make more sense to keep all the eggs in one basket, and have new baskets ready to go if a canary triggers.

I strongly agree to the conclusion but not the logic. It is an entirely possible situation that while EV indeed is a CV's scheme to earn more $$$ users do care and as a result the user security does improve (most possibly, only a bit though). My own conclusion results from the observation that, well, users don't; see an account [1] from Troy Hunt (of the HaveIBeenPwned fame) for example.

[1] https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...

Have you ever actually bought an EV certificate? I work for a company that sells them and therefore I have to deal with the process and there are a lot of checks. "They don't check shit" is complete nonsense.

It would be nice to have the date reflected in the title of this post (March 2018). It's relevant and a nice reminder because the full-distrust is coming soon, but there isn't anything new here AFAICT.

Right, nothing new here. I was confused when I read the title, thinking "it was already distrusted, is there some further amount of distrust possible or is it groundhog day?"

This is huge as it affects GeoTrust, RapidSSL, Thawte, and VeriSign.

I was aware of the Symantec issue and checked my own certs and didn't see their name, but skimming the article I noticed RapidSSL and thought I'd double check and sure enough my certs are about to become bogus.

When such an error (see article) is presented, it’s a teachable moment not only for the user surfing the site, but also for the owner of the site who is going to field questions about the error message from users.

It would be great if Mozilla would include some wording that instills alarm in site owners about how the site’s information, not just the user’s, is at risk.

For example, most non-malicious site owners probably would not want maliciously altered content served from or made to appear as though it came from their site. Yet most of them are, I suspect, unaware that this is a danger when their site does not use TLS.

It would be great to see Mozilla take this chance to highlight this danger so that the people most in a position to make changes would become aware of this additional good reason to do so.

> It would be great if Mozilla would include some wording that instills alarm in site owners about how the site’s information, not just the user’s, is at risk.

I'd expect the reseller to inform the buyer about the distrust of these certificates. The SSL reseller we use informed us before April this year.

I’m not talking about the distrust though. I’m talking about how to convince sites why they should give a care about the distrust. Many of them have no cares to give because they are missing this part of the picture.

The CA trust model is totally broken! We pay certificate of authority CA companies a lot of money for certificates that are not fully confirmed to be authentic.

Here is a better model. You normally register your company with the local government corporate registration authority. The local government knows who this company is, who the corporate registrars are.

One should use a digital ID card to apply to register a company. The founders sign the registration of the company with their personal digital ID. The company is then registered. To apply for a domain name for a company should be digitally signed. The registration government authority should handle certificate of authentic not foreign CA registrars.

All corporations should use Government CAs all other types of certificates can then be issued by Lets Encrypt having proper DNS validation in place should help there too.

All else is broken security by design.

> One should use a digital ID card to apply to register a company. The founders sign the registration of the company with their personal digital ID. The company is then registered. To apply for a domain name for a company should be digitally signed. The registration government authority should handle certificate of authentic not foreign CA registrars.

You must be from Estonia. Or on crack. I'm guessing Estonia.

A lifetime of experience has convinced me that we will have hoverboards, hell, self-flying hoverboards, before such a scheme becomes the universal norm.

Apple is also distrusting Symantec CAs which started in Aug 2018 - fully by Fall 2018

https://support.apple.com/en-us/HT208860

It's just insane that they haven't been able fix this issue and get back into good standing with 6 months warning.

They've already sold the division. They don't care and probably never did.

Sold and DigiCert has been reissuing new certs. Unfortunately they can’t change them for you. Poor operators won’t know until the rug is finally pulled from under them. DigiCert and browser vendors have done a decent job of telegraphing the changes..

> Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization.

Source: https://sslmate.com/certspotter/failures

“Willfully” is the key word here. The business side of running a CA is fundamentally at odds with the security side. A few short-sighted decisions by business-minded managers with their eyes set on profits can completely eviscerate the security side of a company, and it’s possible that nobody remains at Symantec who has the combination of security knowledge + internal political power + will.

There’s also the Trustico fiasco. Trustico revoked 50,000 Symantec-issued certificates in a shockingly bad way. Because policies allowed for certificates with compromised public keys to be revoked, Trustico intentionally compromised the private keys in order to achieve the desired revocation.

https://groups.google.com/forum/#!topic/mozilla.dev.security...

> As one of Symantec's former largest partners - my personal opinion and personal experience is that Symantec is a company that thrives on recklessness and one that I wouldn't trust nor deal with.

You can see more bad behavior here—Symantec is seen as a reckless company, and Trustico (recklessly) cuts ties with Symantec for its business needs. Both actors are bad enough that their relationship reflects poorly on both of them.

I’m sure there are some people who could fix this problem in six months, but I bet they don’t work for Symantec or don’t have the power to do it.

> The business side of running a CA is fundamentally at odds with the security side.

Well, as we're seeing here, they can only be out of phase to a certain degree before both suffer.

Given how wide-spread the issues were, I'm not surprised that they couldn't turn it around within six months, even if they had the will from management to do so (which it isn't clear they did!).

The problem is that they repeatedly mismanaged and violated the BRs.

There’s only so many screw ups you can accept from a CA before you simply can’t trust them to do the right thing. Given that Trust is the basis of the entire CA system there isn’t really an option but to distrust the CA.

Note that multiple CAs have been distrusted in the past, and they were more or less instantaneous distrust. Symantec was a huge CA, and that got them through multiple errors that would have probably resulted in distrust for smaller CAs, and even the final distrust has had something like a years notice.

Pardon my ignorance, but what does "BR" stand for?

Pretty sure it refers to "Baseline Requirements" as specified by the CA Browser Forum.

https://en.m.wikipedia.org/wiki/CA/Browser_Forum

You beat me to it! :)

https://cabforum.org/baseline-requirements-documents/

Just to be clear : there is no "fix this issue" because the problem is with certs issued _in_the_past_. The only fix is to re-issue the cert and replace the existing one on servers with the new one. This fwiw is easy to do, if you know you need to do it. But then presumably folks running SSL endpoints already knew they had to keep on top of expiry dates, cipher suites and so on so this is just one extra aspect to watch out for. Explicitly tested and reported via ssllabs, of course.

The base issue is trust, not some technical issue.

They repeatedly violated the trust placed in them. They'd have to fire the entire chain of command that allowed those to happen, retool their processes, and probably post a sizable bond before many folks would give them a second chance.

But really, who needs them? We need fewer registries, or in the alternative many, many, many more.

PayPal's site is affected by this

That's surprising, because Chrome has distrusted Symantec certs for a few months and it's odd that Paypal would not have fixed it by now.

Chrome and Firefox have only distrusted Symantec certs in their pre-release versions. The Chrome 70 and Firefox 63 releases in mid-October are when the hammer will fall.

https://security.googleblog.com/2018/03/distrust-of-symantec...

The hammer fell in April already. Google published a roadmap, the link you gave, but didn't respect it.

Your anecdotal evidence doesn't prove they didn't respect it. I was just able to load PayPal with a Symantec cert on Chrome 69 on Android, which I realize is dueling anecdotes, but I'm just reinforcing the status quo, you're the one making a bold claim.

The head of Symantec's board is the CEO of PayPal.

PayPal is a diehard Symantec company and will not abandon anything Symantec related until it is absolutely forced to.

All the communications browser vendors have had with PayPal imply they're on track to replace the certificate before the distrust hits stable.

Firefox bug 1484006 has a list of some sites that are still using distrusted Symantec certs:

https://bugzilla.mozilla.org/show_bug.cgi?id=1484006

https://www.ssllabs.com/ssltest/analyze.html?d=www.paypal.co...

I was getting frustrated because I could not visit Paypal (and Ebay) with Firefox nightly, because thy still use the old Symantec TLS certificates. I wonder whether there is _any_ major party that should be more concerned with their certificates than Paypal.

I've got a question about this, as I've been hurled into the admin of our certs, and honestly I probably shouldn't be the one to do it, lol.

But, we run root certs from DigiCert with the rest of the chain provided by RapidSSL. However, I have not received any depreciation warnings via email or any notification in the console output on these sites.

Is there a utility available to "check" our sites, in the same way vendors provide utilities to verify your cert installations? Or should I assume that our stack is going to get caught up in this, and move to find alternative certs now?

Chrome's dev console shows a warning for affected certs.

anyone know if Microsoft is following suit? I searched briefly and could not find any comments...

Microsoft rarely comment publicly prior to making changes to trust levels, but I've heard from several people that they will similarly distrust them.

Apple are yet to state when they will perform the final, total distrust, but it is planned: https://support.apple.com/en-gb/HT208860

There's two problems this exposes. One, it takes a very long time to dis-trust a root cert. This means some people's connections could be exposed for a very long time.

Two, the method for update shown here is to upgrade your browser. Not everyone can upgrade their browser. Corporations often lock down browser updates, and take a very long time to upgrade. Sure, it's fine for you to say "that's the corporation's fault, too bad for them!" but the users of those companies still have to suffer in the meanwhile - to say nothing of vendored smartphone OSes with slow updates...

The other problem with upgrading is legacy computers run very old browsers. I don't know if you've tried to browse the web on an old computer with a new browser, but here's a secret: it doesn't work. New browsers have so many "advancements" that they bloat and crawl on older machines. So effectively, the means of being able to use the internet requires you to buy a new machine.

If operating systems immediately shipped patched CA lists, and browsers immediately used them, that would patch the legacy browsers. But it would not prevent sites from immediately breaking. So no matter what, either we wait forever to dis-trust certs, or we break sites.

Clearly we need an option C that will allow site owners to upgrade their keys immediately and without issue, and users to update their CA lists immediately and without issue. ACME is a good start, but it too has issues that need to be solved.

In addition, the whole idea of trusting hundreds of root certs to sign for every domain is just crazy. We need a method to sign certs only by the organization who actually has responsibility for ensuring the ownership of the domain: the registrar.

CAs are a great "hack" because they allow browsers to verify certs of sites without ever putting any onus on the registrar, but they also have a wacky "trust" model. Any of hundreds of organizations can verify who controls the IP space of a domain, one time, and issue a magical assurance of this, which is trusted until the assurance expires in several years. This can be overridden at any time, and it has nothing to do with who actually controls the domain, which is the registrar and the user who registered it. All the current system really verifies is who controlled the DNS at one time, which is merely pointed to by the registrar, and can be hacked independently of the registrar, meaning there are extra attack vectors.

Yes, lots of little extra "hacks" have been added as stop-gaps, like CAA, and Certificate Transparency, the now-defunct HPKP, and the future implementation of cert issuers verifying the DNS and host integrity from multiple ASNs. But these are just to keep the status quo limping on, and ignore the unnecessary risks the current design imposes. We need innovation and better design, not hacks.

It sounds like you could be describing a desire for trust stores in operating systems that users and system administrators can manage. Is that the case?

Moving on past that, I think you've hit the nail on the head. CAs are about having a root for tree of trust. CAA and DANE are about ensuring that. I'm very curious how you imagine an improved, innovative solution to assuring trust!

I've seen proposals like Namecoin, which are innovative but fail the test of being improved.

My favorite story is when Mark Shuttleworth sold Thawte to VeriSign and used the money to start Canonical. This shows one of the problems of the current debt-based economy.

> Mark Shuttleworth

> Canonical

> debt-based economy

What do any of those things have anything to do with Symantec certificates being distrusted?

Nothing, just mentioning the history. It is worth mentioning since VeriSign was one of the first CAs.

Wow, talk about an obscure warning that tells nothing to the domain owner.

Symantec should have contacted everyone they issued a certificate to.

It appears that there are a lot of things that Symantec should have done, yet here we are.

Haha it’s so weird, it’s almost like they aren’t very good at being a CA :D

While that is true, all service providers, VPS providers, cert resellers, hosting companies have known about this for over a year and should have replaced all of these certs by now as well as contacting cert holders.

They're still exceptionally user-hostile warnings. You can get this running a pre-release browser (and I doubt that they'll be changed for the stable releases of either FF or Chrome) trying to visit Paypal. It's utterly bananas to present this to an end-user doing a very common, security-dependent interaction.

Nobody who runs a website can pretend to be ignorant of this fiasco.

I mean with the huge number of set-and-forget Wordpress installations I could absolutely believe people are ignorant of this. I mean why would anyone outside of professional webdevs even care? It's not like this news escaped the tech bubble.

Those forgotten Wordpress installs may not even have https support.

I knew that my sites weren't at risk because I don't have Symantec certs. It was only triple checking things today that I discovered RapidSSL is a Symantec cert and I am in fact affected.

I don't have a copy of Firefox handy to check, but IIRC the message in the inspector is a bit more descriptive.

The message screenshotted in the article is a message to the website visitor, not to the domain owner. And not going out of their way to shame Symantec to every visitor to a site with a Symantec cert is probably a decent policy. Even without their cert business, Symantec is a big player that the browser vendors will have to work with in the future.

All I can say is Firefox and Mozilla need to go away.

Google, Apple and Microsoft are doing the exactly same thing in this matter: https://news.ycombinator.com/item?id=17920093

FYI: Your site has been unreachable since April if you use Symantec certificates.

Chrome announced the depreciation for October but they didn't stick to their own roadmap and blacklisted Symantec since April instead (Chrome 66 release). https://security.googleblog.com/2018/03/distrust-of-symantec...

Yeah I have seen ecommerce sites that were using Symantec. Nobody cares about Firefox I guess but once Chrome starts enforcement shit will hit the fan.

Point being. Chrome already started enforcement in April.

Not sure why this is downvoted. It is correct.

Because it's wrong. The very post GP linked explicitly says that Symantec certs issued before June 1, 2016 would stop functioning in Chrome 66.

Chrome also blacklisted certs issued after June 1, 2016.

I understand if you don't want to reveal your organization affiliations, but if this was widespread, it should have been discussed somewhere with more specifics. Can you link to a discussion anywhere with more specific examples?

We had a bunch of RapidSSL certs in-use internally, and were rather pokey in replacing them since they were less-critical internal certs. Everything with the deprecation warnings were exactly as expected and announced.

I follow Mozilla's dev Security list and the CAB Forum mailing lists fairly regularly, can't find any discussions about Google deviating from their announced plan.

You can imagine how ridiculous this sounds right? If Google had blacklisted these certs in April as you claim, would that have not been a massive shitshow for everyone involved, and would have been on the top of HN?

Can you post the original roadmap that they didn’t follow? I can’t find a roadmap that doesn’t list April 2018 / Chrome 66 as the time when Symantec certificates issued prior to June 2016 will become distrusted.

https://security.googleblog.com/2017/09/chromes-plan-to-dist...

Reply on news.ycombinator.com