> we believe that delaying the release of this change until later this year when more sites have replaced their Symantec TLS certificates is in the overall best interest of our users.
They do not want to mess up the user experience. Which I can sympathize with, especially for a browser that does not have market share. Chrome on the other hand:
> 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. 
From my point of view this boils down to "We're going to let websites fail for Chrome first, which will get greater visibility, and then we'll follows suit once things have calmed down". If this is the true motivation, then I believe this is a wise decision as Chrome failures will get far more attention and action vs. Firefox failures.
Edit: Just to add some numbers. Chrome is currently at 60% usage while Firefox is at 5%. That is a significant difference in error visibility.
That is a real shame and I sincerely hope they are able to return to a health 25-33% mindshare.
Also, the main offenders aren't the small players, we're talking about the top 1 million. Sure any lambda person could use http if they wanted - but would they make it to the top 1 million?
Is the top 1 million so low a bar that it also contains one-person-orchestra that have no idea how to handle their site?...
Why is TLS 1.0 and 1.1 still enabled by default in Mozilla?
More of the same. Big players don't want to tighten up.
Instead of a generic "Something went wrong" TLS error message that's Greek to normal users and potentially causes blame to the browser, get aggressive.
At this point, it's laziness or incompetence.
"Warning: [WHOIS_COMPANY_NAME] is using a vulnerable certificate from Symantec. Criminals may be able to read anything you do on this site.
Please email [WHO_ADMIN_CONTACT_EMAIL] about securing their site. Click [here] for more information about why Symantec certificates are no longer trusted."
Warning: Potential Security Risk Ahead
Nightly detected a potential security threat and did not continue to [site].com. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.
Websites prove their identity via certificates, which are issued by certificate authorities. Most browsers will no longer trust Symantec, the certificate authority for [site].com.
You may notify the website’s administrator about this problem.
"Firefox won't let me do this" vs "ING's page is broken"
You ever wonder what's happening on the back end of some of these sites running with ancient certs?
Because PCI DSS still didn't obsolete TLS 1.1, probably.
Is there a list somewhere? I'm curious to see which organizations missed what happened with Symantec.
Edit: Answering my own question. Found a list: https://scotthelme.co.uk/the-final-symantec-distrust-is-comi... There are a few I recognize, like solidworks.com, ferrari.com, and quite a lot of .gov. sites.
Rather than "teaching a lesson the hard way", but also rather than just delaying the distrust passively, I would introduce a visual warning in the lock icon, rather than in the developer console.
While _some_ of those 1000+ sites may just be brochureware, I'd bet reasonable money that the majority of them are collecting user data of some sort (even if it's just email/password for site logins) - and the reality of website breaches and credential dumps in 2018 - those 1000 website owners are doing the Personally Identifying Information equivalent of unlicensed and uninsured driving.
I'd stop somewhat short of suggesting we should put the people responsible in jail, but if you run a top million website and have no clue your ssl cert is dodgy - I'd probably support calls to revoke your right to run a public website...
Crying wolf about the security of sites too slow to upgrade their certificates isn't telling anyone accurately that they are in danger, it's just attempting to punish those who are slow. From the outside it just looks like political bickering and for people who don't care it lowers how much they care at all about anything being said about certificate security.
If they haven't already, what reason is there to believe this delay will make them? Just curious if there is another catalyst that will push them beyond cert expiration.
In a few cases your systems might desperately care about those magic brand names, and DigiCert (who now own all these brands) can sort you out if this is the case. In most cases you don't need to worry, just follow instructions.
My worst case hypothetical is clients in retail pinned to Symantec root, upgrade url is https (pinned) and hostname matches your consumer facing website.
So it's issued by "Symantec Class 3 Secure Server CA - G4"
and that cert chains back to a root named "VeriSign Class 3 Public Primary Certification Authority - G3"
Well all that stuff is tainted so it's going away, right? Yup. But maybe your client checks for a pin to that "VeriSign Class 3 PPCA - G3" stuff so you need that!
DigiCert have your back, since it's being distrusted anyway there's no problem having their "DigiCert Transition Root G3" signed by that VeriSign root and that can issue its own Intermediate which they can keep online to sign for you.
So now the certificates aren't issued by the tainted Symantec systems, but your client trusts them.
They also have a bunch of brand new intermediates with the old branding, for cases where you need the branding to match (Yes, I know, that's cosmetic, but eh...) but the cryptography is all fresh.
You definitely should talk to DigiCert people about the specifics of anything you need, rather than take advice from random people on Hacker News like me, but for most scenarios they will either be able to advise you on how to transition safely to something that stays trusted in the Web PKI, or how to transition to something that's maintainable off the Web PKI.
The scenario they can't help with is if you need stuff directly (not via an intermediate) signed by old Symantec roots. That wasn't even supposed to be happening when Symantec existed, and in fact one of the smaller items taken into consideration when deciding to distrust Symantec was that they weren't able to resist plaintive cries (doubtless accompanied by hard cash) by banking customers who asked for this to be done even though it was forbidden.
For example, Let's Encrypt maintains compatibility with old browsers by having IdenTrust (a widely trusted root) cross-sign their intermediate CAs.
>However, given the current situation
"We march North!" says man marching South.
I ran into this issue while trying to visit Paypal on my Pixelbook (on dev channel). There was no "simple" workaround (ie. click to ignore the warning) so I just used a different device.
$ google-chrome --flag-switches-begin --enable-features=LegacySymantecPKI --flag-switches-end
If you need to re-enable the old behavior after version M70 is released, use the following command line flags:
$ google-chrome --flag-switches-begin --disable-features=LegacySymantecPKI --flag-switches-end
It would be nice if the sites were mentioned and contact information posted.
It would be nicer if that information was mentioned directly to the end-user to encourage end-user action toward the site.
And, is it not possible that the sites are fraudulent to begin with?
The broad issue with Symantec was the lack of oversight delivered by its board and senior executives. People with the power to Make Shit Happen at Symantec either didn't know about, didn't care about, or actively permitted practices that were either forbidden, or which weren't specifically prohibited but a reasonable person should have known were unreasonable.
This is not like DigiNotar, where we knew actual bad guys had either the keys or something morally equivalent to the keys (e.g. root passwords to issuance systems).
It's not even like StartCom/ WoSign, where they were doing naughty things and trying to hide that so they wouldn't get discovered, but they fundamentally retained control of their systems, it's just that we didn't trust them.
But nevertheless this could not be allowed to continue.
Distrust was the mechanism by which it was made certain that it couldn't continue. However, Symantec decided to exit the business in 2017, and as a result their management practices are now largely irrelevant.
In theory we could imagine some James Bond style villain copying their old root keys and, before they can be finally distrusted, using them to enact some ludicrous over-the-top plan. Stealing a trillion dollars? Starting a war between the US and Russia? Something like that. But this is not a James Bond movie, most likely everything proceeded as intended and the final distrust is merely a precaution.
Your only option is to use a _different_ browser which trusts the old certificate.
You are right, but there's always a chance that the various documented HSTS bypasses might filter down to normal people. People might be willing to find and use them if they /really/ need access to the site.
e.g. Typing "thisisunsafe" in Chrome on the error screen, or flushing the HSTS state in the browser.
Even in the case of credit card information (or other sensitive data) I would love to know exactly what the probability is of info being stolen. Not hypothetically. But the actual risk.
This idea of 'security at all costs' without looking at the actual cost and/or implementation is not realistic at all and can do more harm (some site not being accessible) than good.
To accommodate Symantec customers, browser vendors have given people (a lot of) time to change certificates, trusting the certs even though the party that signed them was no longer trusted. This placed users at somewhat of a risk, but made possible a grace period.
Now that grace period is nearly over. The companies at fault, who gave out unverifiable certificates, have not contacted all of their customers or their customers have not acted on their messages. Either way, this is not the problem of web browser vendors. End users trust their browsers to warn them if their safe connection is fishy and browsers will soon actually show those warnings.
If you disagree and want to ignore the recommendations of Google and Mozilla, feel free to disable the Symantec distrust flag or to use a different browser that still accepts the bad certificates. That is your choice and the choice of any end user. However, those who don't understand the underlying problem continue to rely on the safety their browser software provides, as they should. If a small website can no longer display simple information because of Symantic not being trustworthy, that website should take it up with Symantec. And it's not as if the certificate wouldn't have to be replaced within about a year from now anyway; there's no extra costs or effort required, just earlier costs.
Let's not forget that it is the web browsers that gave Symantec a business model to take away in the first place. If from the beginning non-commercial key distributions would have been set up (public keys over DNSSEC or something like that) this would not be a problem and the whole HTTPS certificate market wouldn't even exist. Sure, X509 certificates are used for other usages as well, but not as prominently as for web browsing.
Also Let's Encrypt (I am familiar and we use that btw) is great for certain types of situations but not all situations and doesn't work with all control panels in certain cases. For example using the plesk control panel you can't map a domain to a directory or sub page on a site. You can of course add it as an alias to the main page but not say /thisdirectory/index.html at least not as of last week.
Also installing a cert is non-trivial for most users and takes time and work. My issue is not with the people that care to do that or feel it's necessary. It's with this idea that 'everyone should do it period' being decided by the browser vendors. And in particular the way an error message is displayed and shocks a typical user not every gently at all. That is the issue that stops people cold in their track. And scares them.