Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates | Hacker News Reader

Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

groups.google.com

762 pointsehPReth317 comments

TLDR: Google has lost trust in Symantec's ability to properly validate certificates they issue. Chrome has a Root Certificate Policy that expects a CA to perform in a manner commensurate with the trust being placed in them and the Google team appears to see evidence that they are not living up to the standard laid out.

They propose a gradual distrust of existing certificates by reducing the 'maximum age' of the certificates with each release of Chrome.

EV certificates are proposed to have their EV indicators stripped immediately until Symantec, for one year, demonstrates sustained compliance.

The max time also starts at 33 months w/ Chrome 59 so thankfully they're giving plenty of time to either resolve the situation or have people switch CAs.

Not really. By the end of the year with their schedule Chrome 64 will be out with 9 month validity. Then who knows after that. So it is at the most 18 months.

You're right. I didn't look into the Chrome release schedule so I just assumed they followed the max validity deprecation schedule. My mistake.

They're also planning on stripping EV status from their Certs too... that's going to be fun for a lot of banks.

"effective immediately"

They mention the issue is treated as a "medium priority" security issue, which means it should land in the next stable version according to their guidelines (https://www.chromium.org/developers/severity-guidelines)

Banks can just switch to better SSL services...

Any large organization lacks the ability to "just switch" from one thing to another.

I'm fairly sure at least some of the "policy violations" that Symantec did were done exactly as a service to their large bank-or-close-enough customers.

It's not that banks want to switch to a "better" SSL service, it's Symantec being a "better" service for them that got Symantec into trouble.

(IIRC, from reading some of the incident reports)

Can you name some specific examples?

IIRC several of the mis-issued SHA1 certs.

Symantec took one of their widely trusted root certificates and declared that it was now "off the reservation", meaning they may choose to not comply with the BRs for its leaf certificates.

I don't know if they have actively used it to issue SHA-1 certificates, but they certainly could.

You will notice that was also their SGC root, and one of the oldest roots that browsers trusted.

But how or why was this done as a favour for their banking customers?

Banks and companies like First Data were the (sole?) source of exception requests for SHA-1 issuance past the date it was prohibited.

Given the G1 root they pulled has an intermediary called "Symantec Trust Services Private SHA1 Root CA", I can make some guesses...

The exception process used by payment processors such as First Data were for SHA-1 certificates chaining to a root that was still publicly-trusted. They couldn't use an off-reservation root because their client devices didn't trust them.

The roots that Symantec took off-reservation are regularly issuing SHA-1 certificates to anyone whose check clears. Got $1,699 to spare? https://www.thesslstore.com/symantec/secure-site-pro-sha1-pr...

I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted?

Side note: Are payment systems required to link to revalidate their roots at any regular intervals?

> I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted?

Yes, if a client isn't receiving root store updates it will continue to trust certificates chaining to the off-reservation root. This is why taking previously-trusted roots off-reservation is bad for the ecosystem and would ideally be prohibited.

> Side note: Are payment systems required to link to revalidate their roots at any regular intervals?

Many payment systems apparently have no automatic update mechanism, so I assume there is no requirement for such.

Wow, the two of those combined with embedded systems with extended lifecycles seem like a recipe for disaster.

It really is :-(

Indeed, I was just speculating that more banks and payment processors might take advantage of the off-reservation root if it was possible, given the type of companies that publicly showed they needed one.

I agree.

However, there's no point in pretending these certs are good if we can't trust the issuer to not put out BAD certs. Painful or not, if the banks are user the certs to show they are trustworthy, then they need to switch when the issuer ISN'T trustworthy.

Not always, although it depends on what you are changing. I work for a 200,000 person company, and switching cert providers would not be a huge task. We have done it before.

ha.ha.ha.

I worked at a financial institution for several years. There are many, many IT folks, internal auditors, and others who are probably wishing they wore their brown pants to work today.

SSL certificates are cheap in contrast to the labour intensive management practices that exist around them, especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/)

>especially around legacy platforms that may have been hardcoded to use certificates from a specific issuer (not that I have ever seen that before, no one would be that foolish right? :/)

D'ya know, I would have naively assumed this wasn't technically possible. I shudder not only to think of the code, but also of the thought process that could compel someone to undergo the effort of bricking themselves into this corner because honestly, that sounds a lot harder than doing it right.

It happened to me - I was working on an application for the pre-paid electricty system in Texas: the server-side code connects to a data-source over a TLS connection (complete with client-side certificates too), except the server-side used a self-signed certificate, and my code didn't have admin/root rights on the client hardware so it had to use in-app certification verification code. I had to hard-code the root CA's fingerprints directly into my code so it would be baked into the signed binary (this was a project requirement). That thing is going to fall-apart if the root CA ever changes - fortunately it won't expire until 2099.

(Yes, I gave the client a strongly worded statement of my misgivings - and all the other bad code-smells in the project)

So basically you're pinning the server certificate chain into your signed client code? Actually that sounds like a good thing!

https://www.owasp.org/index.php/Certificate_and_Public_Key_P...

Except that that likely ended up baked into a system that is hard or impossible to upgrade. So when the certificate is revoked or changed the system stops working.

Pinning is a good thing, assuming you have built in a reliable upgrade path (oh hey, browsers update themselves automagically now so yay!) but when you have occasionally connected devices that have low bandwidth that have a long deploy lifecycle, it's not always feasible, or even a good idea.

It's even worse if said device is embedded and has severe hardware constraints for compliance and regulatory reasons, and those same reasons prevent you from deploying patches on the regular.

Layer in some "built by the lowest bidder" and "accumulation of 30-odd years of poor practices for smart payment cards" and you have a big mess of a situation to unravel.

Oh yeah, and lest you think this is not an issue because this is browser related, may I introduce you to the world of services that proxy legacy green terminal applications into web front ends, ranging from IBM HATS to bespoke AJAXy things that unwrap screen scraped terminal emultor content from XMLHttpRequests.

Jeez. Remembering why I used to drink more when I worked in fintech :)

Hardcoding certificates is actually way too easy. SSL libraries don't necessarily use the system ca store or even know about it. OpenSSL has the option of disabling certifcate validation, providing your own certificate list or pointing to some system-supplied certificates which you need to find first. So in a way you even have to count yourself lucky if the hardcoded one instead of choosing to just disabling validation.

If you're hard coding certificates in your own client software, this issue doesn't affect you.

It's pretty common in the embedded world where you don't have enough flash space-- or don't want to use what flash you have-- to hold a root CA store.

Such devices are usually great targets for learning how not to secure things, because when they care that little they often don't get anything else right either.

This is essentially what HTTP Public Key Pinning (HPKP) does [0]. HPKP is a header your web server responds with that tells the client's browser, "Only trust my domain if the certificate presented is in a chain that goes up through one of these CA public keys". This is so an attacker can't go buy a certificate from a less-diligent CA and use that to MITM HTTPS traffic between clients and your domain.

You pick two or more CAs you trust, and brick yourself into a corner saying "these are the only CAs you should ever trust w.r.t. this domain".

[0] https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

A number of people recommend doing that as best practice.

https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extens...

suddenly everyone gets hauled into a change control board meeting to chance a cert on an F5

Well, you guys here love capitalism, and this is capitalism.

If you make such astonishingly obviously poor decisions, you deserve to fail.

The problem is that kludges like this (Symantec's handling) work perfectly up until the point they explode.

And market consumers lack the technical ability to discriminate between anything more finely grained than "works" / "doesn't work."

Somebody needs to tell Bank of America. They're still presenting a Symantec EV cert.

So is Chase, Citi, PNC, Schwab, TD, ...

Oh no, of the 20 users that know about EV, 2 might send an email.

EV actually causes a different "secure" UI to display in the browser. Usually it is the name of the corporate entity that the certificate is issued for. If you don't have EV you only get a padlock.

Browsers make changes like that to their UIs all the time. I highly doubt that a member of the general public would notice the difference. Heck, I doubt most developers would notice.

I agree, because I experienced it just now. I'm on Chrome 57 and just realized that Chrome certificate details UI seems to have changed sometime recently.

I remember I could earlier click on the padlock or "Secure" text, click More (or something) on the popup and it would display certificate details in developer tools (which is itself weird, but atleast it was available for end users).

Now, it doesn't give any direct way to see certificate details. "Learn More" just opens a support page with vague details. The only way for a user to see details now is to explicitly launch developer tools. I find this logic a bit weird. Apparently, this is not a bug but a feature [1].

[1]: https://productforums.google.com/forum/#!topic/chrome/kPlY52...

You just made me look, and what I saw made me sad. Even more than I already was. :(

"Let's remove this thing that is super useful while your stated goal could just as easily be reached while keeping the original functionality." Bill Hicks was so incredibly right about marketing.

I noticed that a while ago. I thought I was just doing something wrong.

Oh, I know. But name me a non-IT professional that knows the difference, or would care that their bank has "secure" and not "Bank of America LLC".

I think there are groups of smart PKI/UI people discussing how better to design security warnings at various levels of EV/HTTPS/Partial HTTPS/HTTP.

While users don't care, the bank (internal) security policy auditors do and a lot of them have EV cert listed as a requirement.

A. EV certs are bought for a reason, the very "green bar". Customers will notice this and won't be happy about it.

B. the 9 month expiration will also make customers unhappy

Both measures will put operational pressure on Symantecs customers and eventually decrease Symantec's market share in the business.

Yes, you are correct, in that Symantec's customers will care.

I am saying the customers of banks don't give a damn about EV or not. It's not in the literature. It's hard enough to train them not to click through; even I as an IT guy would probably not notice the lack of EV unless there were a modal or bubble saying "Hey! This is different!"

> A. EV certs are bought for a reason, the very "green bar". Customers will notice this and won't be happy about it.

Are you sure? I've never heard/seen/notice anyone non-technical care remotely. Or even know what it means.

We've been asked about it by "enterprise"-y clients.

It's on the checklist of things companies ask about when assessing third-party services.

Those are not users. Those are people who have read up about SSL certificates and have bought in to the hype.

most business is B2B, I don't see how they're not users.

The business is not the user for SSL. It's the human logging into the website. Maybe Bank of America will care if the padlock in the URL bar is gone, but John Doe couldn't care less and probably has never noticed the green padlock and word secure in the URL bar ever.

Yes, the EV cert market is pretty enterprisy. Those customers need EV certs for compliance and will abandon Symantec to stay compliant.

> name me a non-IT professional that knows the difference, or would care that their bank has "secure"

It has the secure padlock as an image on the page! And a green check mark!

This is a good summary, but I'd clarify it by saying that Google isn't being subjective about Symantec's process failures. The CA industry self-regulates. Its regulatory organization is the CA/B Forum, and their principal regulation is the Baseline Requirements (the BRs). Google claims Symantec violated multiple BRs.

If you want to dig a little deeper, here's the last version of the BRs:

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...

Have they published anywhere the violations?

Normally browser makers publish openly evidence of mis-issued certificates, together with having the discussion with the vendor in the public.

It's sad that this announcement from Google seems to basically be saying "we had a closed door dispute with Symantec, and now don't trust them".

The issue has gotten plenty of public discussion (from Google, Mozilla, and others) on Mozilla's dev-security-policy mailing list: https://groups.google.com/forum/?fromgroups=#!forum/mozilla....

The main thread is https://groups.google.com/forum/?fromgroups=#!topic/mozilla.... , and it contains some nuggets like this:

  So after reading this, the following auditors aren't
  trusted by Symantec anymore:
    - E&Y Korea
    - E&Y Brazil

  The following isn't trusted by Mozilla anymore:
    - E&Y Hong Kong

  This seems to be a worrying trend to me.

  Kurt

I was curious if E&Y was Ernst & Young, and indeed it is, apparently they go by the name of EY now.

I found this attached PDF interesting as well: https://bug1334377.bmoattachments.org/attachment.cgi?id=8831...

Yes, each of the Big Four isn't really a single company, that'd be too vulnerable to lawsuits when (let's face it, not if) they screw up. Instead they're a network of companies licensed to use the same name.

Mozilla was asked (I do not know if they actually did it) to have one of their London people stroll over to EY's headquarters building in that city and explicitly let them know about the Hong Kong EY's failures so that there's no opportunity to later pretend EY as a network didn't know this was a problem.

The nature of audit work, both for the Web PKI and for business accounting means that "capture" is a big problem, the auditors get paid by the company they're supposed to audit and further work is conditional on giving a good report, so, why look for trouble? Failure is inevitable.

If you're wondering when it became the Big Four, the Big Five had one more member, they audited Enron and signed off accounts which bore no resemblance to reality, then when they realised it was being investigated they destroyed all evidence of what they'd done. The resulting scandal destroyed them, although the US Supreme Court eventually decided that the people who ran the audit firm and gave orders to cover up what it had done were innocent...

Small correction: the CA industry doesn't self-regulate. Both browsers and CAs participate in the CA/Browser Forum and my (admittedly outsider) impression is that browsers almost always have the upper hand.

Things that go to vote in the CAB Forum are often split pretty exactly down CA v. browser lines, and the CA outnumber the browsers and hence typically win. That said, the power of the browser vendors as those who maintain the trust stores is obviously there.

This is not accurate. To pass, a ballot must receive a 2/3 majority from CAs AND a 1/2 majority from browsers. While there have been some contentious votes along CA-browser lines, you can see from the ballot history that most ballots have passed and thus had support from both browsers and CAs:

https://cabforum.org/ballots/

Oh let me guess how this goes:

> Ballot 161 – Notification of incorrect issuance

> In the event that a CA issues a certificate in violation of these requirements, the CA SHALL publicly disclose a report within one week of becoming aware of the violation. A link to the report SHALL simultaneously be sent to incidents@cabforum.org.

> From the CAs, there were 0 YES votes, 14 NO votes and 5 Abstentions

> From the Browsers, there were 3 YES votes, 0 NO votes and 0 Abstentions.

sigh

The ballot was a bit more nuanced than it seems. 1) Browsers already require reporting of mis-issuance directly to them. Mozilla requires a public bug list and 2) There was insufficient clarity in the ballot about "mis-issuance". Plus with crt.sh, this information is already available in one general location, which made the reporting requirement of everything seem a bit redundant.

If they can't get their way, the browser vendors can just shrug and make their own rules, that's what happened for Ballot 169 for example.

Ballot 169 says to validate DNS names in a certificate you can't just make up any old "validation method" and say you think it's adequate, you must use at least one of these specific enumerated methods.

The Ballot passed, but then a bunch of CAs declared that they had patented some of the methods on the list. So effectively even though it passed Ballot 169 was unwound while they negotiated patent licensing agreements.

But Mozilla meanwhile went "everybody must obey Ballot 169 or get kicked out of Mozilla's trust store", so that raised the bar anyway.

The happy news is that a mix of Mozilla saying "comply or feel free to go out of business, we don't care" and people like me pointing at the crappy patents and laughing at their weak excuse for "innovation" appears to have had the desired effect, and a new Ballot will reinstate the stuff from Ballot 169 later this year.

But if I understand correctly, this decision was Google's entirely?

If that is the case then it doesn't matter much what forum thinks about Symantec. Buying a certificate which is not supported by a major browser vendor would be... eccentric, so my guess is this will be a major blow for Symantec certificate business.

CA/B is neither a regulator nor, formally, a Standards Development Organisation although if you can squint it can look a little like either. CA/B produces the Baseline Requirements and also a set of EV Guidelines, for how a CA should behave.

The browser vendors (actually mostly OS vendors in their guise as browser vendors, Mozilla effectively stands in for all the Free Unix type operating systems) operate trust roots, and each of them decides their own criteria for things to appear in those roots.

BUT there was concern as the root store programmes began to tighten up their criteria that they might step on each others' toes, CA/B is a forum to share common principles. For example, rather than Mozilla tell CAs to stop issuing certificates that last more than 2 years plus a few days, and Google tell them not to issue ones that last more than 25 months, and then Microsoft say they want a rule forbidding new certificates that last more than 750 days, everybody got together at CA/B and passed a Baseline Requirements change setting the limit at 825 days from next year.

CA/B looks a lot like a cartel (all the companies in an industry meeting up to agree things) so it has a bunch of things it mustn't do to ensure it doesn't break anti-cartel legislation and get anybody sent to jail [The world's most famous cartel, OPEC, doesn't fear the law because OPEC is run by governments and governments have sovereign immunity]. For example it can't talk about prices, or future products.

Another result of not being a cartel is that CA/B doesn't bind either CAs or Browsers. The CAs can break CA/B rules without being kicked out of CA/B and the Browsers can and do require things beyond the Baseline Requirements, for example Microsoft requires every CA in its programme to revoke any certificate it tells them to, on demand.

Initially CA/B was all about smoke-filled rooms (maybe not literally) but Mozilla and Google have pressured them to gradually act more in the open, so you can actually follow along most of their decision making in real time via their mailing lists.

If anyone here hasn't realised, Symantec bought Verisign back in 2010 - who own many brand names, like GeoTrust, Equifax, Thawte etc. You can see a list of their roots certs here: https://chromium.googlesource.com/chromium/src/+/master/net/...

In case you missed it at the bottom:

> From Mozilla Firefox’s Telemetry, we know that Symantec issued certificates are responsible for 42% of certificate validations

Symantec bought Verisign's authentication business, still two different companies.

GeoTrust was started from buying Equifax's security business. Symantec bought GeoTrust. Symantec doesn't own the Equifax brand or company.

Wasn't Verisign the very first CA business? How the mighty have fallen!

This is huge, Symantec owns about 15% of the SSL certificate market[1], and as stated in the article, has issued 30% of in-use certificates. No certificate authority of this size has ever been raked over the coals like this.

[1] https://w3techs.com/technologies/history_overview/ssl_certif...

Pretty much it will decide the question on whether or not the certificate system is even workable. My thesis is that either Symantec will not be able to respond (and so lose their ability to be a root certificate) in which case it will warn other root cert authorities to shape up or lose their business, or they will placate the Google and Chromium teams somehow and show that root cert authorities can be brought to bear.

Or they will ignore Google, continue to create bad certs, and users will start getting instructed by sites that they have to manually add a root certificate in order to use they site, and the entire ecosystem will collapse.

I think it's likelier that Symantec will start a negative PR campaign, leading its users to yell at google to change things, perhaps calling this FUD. Whether that'll be effective is another question.

It would be pointless. Who would listen?

The general public doesn't care about inside baseball. Site operators can't afford not to work perfectly with Chrome.

>Symantec will start a negative PR campaign, leading its users to yell at google to change things,

It seems Google has the leverage, not Symantec.

A PR awareness campaign is out-of-band information that's separate from the web surfer actually navigating to a site. Millions of users would see a scary message similar to "This site's security certificate is not trusted!"[1].

To prevent scary security popups, which is more likely?

1) The website owners abandon Symantec and switch to a Certificate Authority not flagged by Chrome

2) Users get "educated" on Symantec's side of the story and manually add Symantec as a trusted root certificate. (Some can switch browsers but for many non-techies, that's a pain because they have all their bookmarks in Chrome -- and migrating them on mobile phone is not obvious.)

[1] https://www.google.com/search?q=google+chrome+this+site%27s+...

3) Large websites using Symantec certs start telling users Chrome is "broken" and we find out if users will switch browsers, not care about the security, and/or complain to the sites.

I definitely find any variation of #3 to be more likely than #2. I see it as a battle between #1 and #3.

>Large websites using Symantec certs start telling users Chrome is "broken"

I'm having a hard time thinking of a scenario where a large website concludes it's cheaper to convince web shoppers at ecommerce sites and web visitors at news sites to switch to Firefox/IE instead of the website just switching CA vendors.

If you're a website that wants to put up zero friction between buyers submitting their credit-card info and pay you money, why try to "educate" them? If you're a website that wants visitors to see your ads next to your journalists' stories, why make it more difficult than it has to be? Does Symantec as a CA offer up extra benefits that no other CA has such that it makes sense to "train" web visitors to switch browsers?

Of the millions of non-geeks that use Android phones, what % download and use Firefox instead of the default Chrome browser?

This line of reasoning works for banks or commercial entities.

But note, it does not work for governments. They can, and will, put up a red banner instructing the user to install another browser (or in case of Firefox 52, explain how to disable updates so you can keep using NPAPI plugins).

Interesting point. I spot checked CAs for some of the most popular USA government websites.

irs.gov (Internal Revenue Service): Entrust CA

va.gov (Veterans Affairs) : Symantec CA

So if Symantec is the CA for a critical mass of government websites that won't abandon them, Google Chrome could lose this battle.

Without looking at traffic data (e.g Alexa), my intuition says the vast majority of web traffic is not government websites. If Veterans Affairs forces user to switch browsers, I'm guessing people would still use their Chrome browser for all the other websites because that's where all their bookmarks live.

As for non-government websites, I notice that Netflix.com currently has a Symantec Class 3 CA. I'm guessing Netflix would rather switch to another CA.

I believe it is actually a matter of political campaigning in South Korea to get rid of ancient IE ActiveX requirements for government websites.

It's not just government websites, it's requirements that the government placed on all e-commerce sites in South Korea.

The US Federal Government has stated a long term plan to operate a CA in the Web PKI, because after all it does operate a whole shitload of web sites, and it has secure buildings and trustworthy employees needed to run the CA. Like some other government-owned CAs it has offered up front to limit its CA to a TLD it controls anyway (in this case gov) so it won't be offering certificates to the general public.

They don't have a formal proposal yet, such proposals take anywhere from 6-18 months to process once they come out, and so the IRS or Veterans Affairs won't be getting new certificates from them in 2017, but in 2018 that's definitely a possibility.

Of course, a US Federal Government CA in the Web PKI would be problematic for Google, Apple, Microsoft or Mozilla (all US corporations) to distrust later if things go wrong, this is doubtless why they ask to limit to one TLD, defusing concerns in advance...

Mozilla has also been putting the hard word on Symantec over this issue, I don't think they'll be too far behind Chromium in taking action.

How will these websites communicate #3? Through the blocked website?

Wouldn't they just do what all browser-version-specific websites have done in the past and have an http landing page with a conditional redirect? User agent is IE6, and you progress to ie6.bankofamerica.com. User agent is Chrome/Firefox, progress to webpage with browser version warning and download link for IE6.

Maybe after their HSTS header expires. What do they do until then? Or for all the users with https bookmarks?

Well, just looking at the Bank of America example, they don't seem to use HSTS in their landing page. How widespread is HSTS? How long is the expiry period typically set for (I would guess a long time?)

Does anyone still use browser bookmarks?

Actually, just thinking about it, it might be even simpler than this. If Bank of America wanted to, couldn't they still host their redirect landing page over SSL with a valid non-Symantec certificate, and then redirect to the ie6.bankofamerica.com page which will continue to use the bad Symantec cert? If switching certs for their web infrastructure was really difficult and they didn't want to do it, they could just build a simple little front-end web server with a valid certificate to redirect people to an IE6 download page or ie6.bankofamerica.com.

HSTS is currently used by 2.8% of all websites, up from 1.2% this time last year. [1] If people are using Qualys SSL Labs tool to check their "grade", they won't be awarded an A+ grade unless their HSTS max-age is at least 6 months [2], so I'm going to assume the average is somewhere close to that due to how common usage of that tool is.

My grandma still uses browser bookmarks, but I have no none-anecdotal source for this.

BoA could absolutely do all the things you just mentioned, but all of them are more difficult than simply replacing their certificate using Comodo or some other trusted root CA.

[1] https://w3techs.com/technologies/details/ce-hsts/all/all

[2] https://community.qualys.com/thread/15972

On the plus side, it would probably break the Mint / fintech scrapers for a bit...

BoA could absolutely do all the things you just mentioned, but all of them are more difficult than simply replacing their certificate using Comodo or some other trusted root CA.

That depends on the design of the site and their business policies. I agree though - for any sensible organization switching certs is going to be easier. But if that was really the case here, why were they asking Symantec for special favours?

> Does anyone still use browser bookmarks?

This made me cry a little. But on a more serious note, every existing link on the Web is essentially a bookmark, so I don't think we can ignore that when discussing impact. (Though I'm betting all incoming requests could be rerouted more easily than telling your customers to (and how to) install a cert...)

Obviously they get another cert, but only serve it to chrome users via SSL handshake fingerprinting, and serve the Symantec cert to everybody else...

I can't tell if you're joking.

Just in case you're not, if they went through all the trouble to get another cert for Chrome, why wouldn't they just use it for everyone?

I suspect it was a joke, but you raise a very important question. Unfortunately, some clients (likely embedded devices) trust only Symantec roots, since that's the CA the website was using at the time the developer slapped together their code.

4) Banks require Chrome 55, "here's a download", good thing it's open-source, and we get the IE6 story again.

The PR campaign won't be targeting users, it'll be targeting business/site owners. A user might be annoyed that random sites stop working, but the people who operate those sites will see their traffic fall off a cliff.

The only effective solution to stop the pain will be to switch to a new cert as quickly as possible, and that only hurts Symantec, not Google

To which the response will inevitably be "Communication with the bank can't be trusted" and many people will read as "The bank can't be trusted". I think people will quickly come to the conclusion that the stakes are much higher for them if the bank can't be trusted when they have their money there, compared to the browser being too assertive, and will just move their money. Without definitive knowledge or a good understanding of all the intricacies, that's the safe decision.

Banks know this. Like the CA system, the whole banking system only functions because of trust, and in the US that trust is backed by the government. They aren't going to let that erode. Regardless of whether all their back-end certs get updated, their customer facing ones will if needed.

Yes. You can't just jeopardize a substantial portion of a large company's revenue stream like this and not expect retaliation. Guaranteed that unless the executive team steps in to reverse this, Google has made itself a few powerful enemies.

Google is playing with fire here. I would expect Symantec and other major business who stand to be negatively affected, especially the extremely large ones that Symantec was accommodating by skirting some of the EV rules, will immediately start pushing for regulations around this process. That's the easiest way for large companies to control this kind of thing.

"Norton Security Browser" a new free browser with internet security baked in...

Remember google has chrome AND android. I think they're big enough to win this battle if it comes down to that. Symantec is at the clear disadvantage.

>Symantec is at the clear disadvantage.

I'm not sure how they are at a disadvantage if they have supplied 30% of in-use certificates, and are responsible for 42% of all validations.

While I don't condone Symantec's behaviour, I think google is being a bit hypocritical here. Have you ever tried reporting gmail spammers to google?

Sans maybe spear phishers, spam campaigns aren't generally ran by oppressive governments. MiTM certs with bogus certs absolutely are, and could result in jail / death.

EFF ftw!

https://ssd.eff.org/

I'm simply pointing out that both companies seem to think they can do what they want, due to having such large market share.

Do we know that Symantec is being malicious, or just lazy like Google's response to spam?

This is a real security issue and spam isn't.

> Or they will ignore Google, continue to create bad certs, and users will start getting instructed by sites that they have to manually add a root certificate in order to use they site, and the entire ecosystem will collapse.

IIRC that's Amazon's answer to 'how should a user install Amazon Prime on Android?' I don't know how successful they've been convincing users to allow installation of untrusted apps (I certainly haven't done it), but … probably more than a few have done it.

Installing apps from other stores on Android is literally a checkbox away - but installing new root certs on computers is considerably harder, or impossible if your computer is locked-down (group policy, etc).

Installing new roots on Macs, iOS, and Android devices is really easy. It's mildly inconvenient on Linux desktops.

It's actually no longer possible on Android, without jumping through significant hoops:

https://android-developers.googleblog.com/2016/07/changes-to... https://news.ycombinator.com/item?id=12061320 https://github.com/mitmproxy/mitmproxy/issues/2054

And it's really not the sort of thing your average non-technical user is likely to do - and trust me, having supported these users before, it's likely to go horribly wrong if you try providing steps for them.

I did it... mainly for amazon's own apps.

users will start getting instructed by sites that they have to manually add a root certificate in order to use they site

Or switch browsers. Google needs to (and will) play this so it ends up being unattractive for other browser vendors not to distrust Symantec as well.

That's a good insight. Apple and Mozilla don't seem to mind making big decisions for their users on behalf of perceived security threats either, so I imagine only Edge will hold out for long time. Google probably won't lose any market share over this.

Could actually dodgy sites then imitate bank websites, ask the same of users and then commit a MITM attack?

I'd much rather be able to say -- 'no, never manually trust a cert', instead of 'well, ok, for now yes in this one case if you're sure there's no typos in the URL... What? Yeah, the text at the top in the little bar... argh'.

I hope I'm missing something here, but even better I hope Symantec and banks get their acts together.

Could actually dodgy sites then imitate bank websites, ask the same of users and then commit a MITM attack?

Technically, certificate pinning etc can prevent this, but in practice, yes, this is a possible attack vector.

But it has little to do with CA validation. If the user understands how to verify the domain and security of the connection the attack doesn't work, and if he doesn't, the Google vs Symantec situation makes no difference either.

It is workable. This gets brought up every time we have an issue like this. The problem is that existing CA's keep fucking up. But the system is clearly working: bad CA's get excluded.

I think the likely result here is more widespread adoption of LE. The point is that CA's shouldn't be businesses.

Mostly agreed... for the most part, EV certs are meaningless to most people. Wether it's LE, or otherwise.

> brought to bear

I think the idiom you want is "brought to heel".

Maybe, but in the meantime I can't imagine a scenario where such a direct financial threat to a business isn't vigorously defended by Symantec. I'm not a lawyer, but certainly they must be working to determine if they have a legal basis for seeking an injunction against Google. They could even be building some sort of legal theory based on tortious business interference, contending that Google is doing irreparable harm by trying to come between Symantec and the expectations of its paying customers.

That seems unlikely if Symantec have indeed violated the CA/B Forum Baseline Requirements that they already agreed to.

How is this different from StartCom except for size? Is the "too big to fail" enough of an argument here?

Edit: Oh wait. Verisign and Thawte. Okay, that's some massive excrement on a collision course with the ventilation device.

StartCom were blatently lying, I don't think Symantec have stooped that low.

Hard to say which is worse, the intentional lying or the fact that Symantec has repeatedly violated the BR's and root store policies despite the appearance of best efforts not to.

Yeah seriously, every time Symantec slips up it seems like their response is some variant of "lol whoops, we didn't know we weren't supposed to issue certificates for entities other than the owner!"

Am I the only one worried about LetsEncrypt becoming a monopoly? This move from Google is, indirectly, a huge service for them.

I don't see the link with LetsEncrypt here. Symantec doesn't give away free certs, and LetsEncrypt doesn't do EV.

If I'm reading the settings page right, Chrome trusts over 70 certificate issuers right now. Let's Encrypt is just one of those, and only issues a limited set of certificate types.

As I understand it, Chrome (unlike Firefox) does not ship its own root CA store - rather it defers to the root store of the operating system that it's running on. It does however apply some form of blacklist / additional restrictions over what the OS may allow.

Arguably, they could just adopt LE technology wholesale. Shrinking cert lifetimes is compatible LE's already short cert lifetimes.

The implementation is open source. You can launch your own ACME server (valuable for testing), and use that. CAs implementing this technology obviously need to go through the same hoop-jumping in order to become trusted, but that's true of any strategy of starting a CA.

The technology is available for any CA, existing or new, to copycat.

And if they don't want to use the open source reference implementation, they can cleanroom an ACME server that works with all the existing clients that work with letsencrypt.

I'd be quite happy if LetsEncrypt becomes a significant monopoly - they're following much better practices than many other CAs, they run on open source software and are generally operated in a much more transparent way than other CAs. By using stuff like Certificate Transparency Let's Encrypt makes it so their issuances are publicly auditable - much more than many other CAs are doing these days.

And none have ever deserved it more than Symantec.

I've often wondered: why is trust in CAs an all-or-nothing proposition (aside from EV certs), and why should my particular browser vendor have all the authority over who I should trust?

For the vast majority of users that's probably just fine, but I would have thought that there'd be a browser or extension or something that allows security-conscious power users more fine-grained control over this by now.

For example, I could subscribe to changes in CA trust levels from every major browser vendor, and if they don't agree my browser could show me a warning with an explanation.

Or I could subscribe to feeds from other entities I trust, like the EFF. Or my security-conscious friends.

Or if I decide I have lower trust in certificates issued by governmental CAs, or CAs in certain regions, I could mark them as lower trust.

Basically a web of trust for CAs.

> Or I could subscribe to feeds from other entities I trust, like the EFF.

How would you validate that the EFF's feed is actually from the EFF? Assuming we're using existing SSL infrastructure, the browser would first need to trust the CA used by the EFF, which means we need an initial set of trusted CAs.

> which means we need an initial set of trusted CAs.

How would you validate that the initial set of trusted CA roots is actually from those CAs?

It ships with your operating system, which you physically obtain from another computer (with hardware like a USB drive or via internal network).

But how to trust that this other computer has a good set of CAs?

How can you know your signing software is not backdoored? How can you know you're not living in a computer simulation?

Well, I'm certain my eyes are real so I am certainly not living in a computer simulation.

How Can Our CA Roots Be Real If Our Eyes Aren't Real

https://twitter.com/officialjaden/status/329768040235413504?...

"If real is what you can feel, smell, taste and see, then 'real' is simply electrical signals interpreted by your brain." -Morpheus, The Matrix

(finally, finally there's a use for that quote!)

Because then you have the web of trust model, which absolutely sucks in practice for people to actually use.

So yes, you could do this. But outside of a few hundred people, nobody wants to actually undergo the constant effort this would actually require.

> I've often wondered: why is trust in CAs an all-or-nothing proposition (aside from EV certs), and why should my particular browser vendor have all the authority over who I should trust?

It doesn't. You can adjust your root certs in Firefox by going to about:preferences#advanced and clicking on certificates.

But what does partial trust look like? Showing half of the HTML? An eyebrow raised emoji instead of a lock?

I wish CA management was easier to bulk-edit. Show me a table of root CAs with their data, their country of origin, etc., and allow me to filter and enable/disable all based on filters.

Full disable would shut down trust entirely, and get the warnings similar to a self-issued cert.

Reduced trust would have a "not Secure" label or something, like a plain http connection.

Many CAs are cross-signed, what should the software do in that case?

"Country of origin" is a really interesting one for precisely the Symantec scenario.

Symantec is a US company right? But the main _problem_ happened at a company called CrossCert, full name Korea Electronic Certification Authority. They're Korean.

So if you decided you don't trust Koreans, Symantec's root looks fine, nothing Korean about that. Except, somewhere Symantec signed a contract with CrossCert saying "OK, we'll issue any certificate you want, so long as you pay us and promise to do all these things". Oh, and then they didn't actually check CrossCert did any of the other things (I think we can assume they checked they got paid...). You don't get to see that contract. It wasn't even prohibited by the rules Symantec had agreed to. If Symantec hadn't been caught issuing bogus certificates as a result you wouldn't even be reading about it.

For example:

Full trust: green lock icon

Medium trust: yellow lock icon with list of reasons when clicked

Low trust: prompt when attempting to load

No trust: completely blocked, or more difficult to override (like Chrome does now)

I could go for an eyebrow-raised emoji in some cases. Self-signed certs for instance, or any root cert that the browser picks up from the OS.

Is there an eavesdropper emoji?

U+1F575 SLEUTH OR SPY

Useless. On my computer it looks like Firefox is using a font that has a sleuth with a magnifying glass and a hat, while Emacs uses a font that has a silhouette of a guy wearing a trenchcoat.

You can always disable everything except for LE.

It's not WoT because WoT is supposed to help you know of unknown people are secure (say LE and FSF trusts ABC, it probably means that ABC is reliable), which doesn't work at all

It looks like the questions that Google/Mozilla asked Symantec and didn't like the answers to are posted here:

https://knowledge.symantec.com/support/ssl-certificates-supp...

(Archive link: http://archive.is/Cq9VO )

Really interesting reading!

Because the process happens in the public newsgroup mozilla.dev.security.policy anyone with a legitimate interest in the Web PKI can ask questions during incidents like this or indeed during Mozilla's new CA application process.

Some of the questions on that list are mine. I don't remember if representatives from Google or Mozilla explicitly told Symantec they needed to answer my questions, beyond a certain point it's implied that smart questions (and I hope mine are smart) should be answered regardless of who asks them.

Other than Google and Mozilla, major trust stores mostly prefer to conduct their activities in private, so we don't know what (if anything) Symantec were asked by Microsoft, Apple, etc.

I was curious if this would affect my Symantec issued certs... according to my date math:

Chrome 59 (Apr 13, 2017) +1023 days: 2020-01-31

Chrome 60 (May 25th, 2017) +837 days: 2019-09-09

Chrome 61 (Jul 20th, 2017) +651 days: 2019-05-02

Chrome 62 (Aug 31st, 2017) +465 days: 2018-12-09

Chrome 63 (Oct 12th, 2017) +279 days: 2018-07-18

If I'm reading the post right, it's stricter than that:

> ...distrusting certificates whose validity period (the difference of notBefore to notAfter) exceeds the specified maximum.

I.e., a certificate valid from 1/2015..1/2019 is distrusted as of Chrome 59.

And the more lax restrictions only apply to certificates that have already been issued. Any one issued after Chrome 61 are held to the highest (9 mo) limit.

> In addition, we propose to require that all newly-issued certificates must have validity periods of no greater than 9 months (279 days) in order to be trusted in Google Chrome, effective Chrome 61.

I agree with the newly issued certs. The other, that's going to be painful, and a mess to figure out, if you are right.. and that's quite possible that you are. UGH.

EDIT: Update, I'm not sure you are correct, I just downloaded the latest dev release (Version 59.0.3047.0 (Official Build) dev (64-bit)) and it accepts a rapidssl issued(symantec owned) cert valid for 1187 days, which would exceed the 1023 days.

It's also possible it just hasn't made it into the release yet, I'll have to keep like a daily eye on this, and plan to replace much much sooner just in case.

> It's also possible it just hasn't made it into the release yet,

The proposal was just made, so you shouldn't expect it to be reflected in code just yet.

>All Symantec issued certificates. GeoTrust and Thawte are CAs operated by Symantec, simply afforded different branding.

>While this list may need to be updated for some recently created roots, https://chromium.googlesource.com/chromium/src/+/master/net/... may accurately capture the state of impact

Damn. There goes my certificate (Rapidssl). Anybody know what are the remaining, trustworthy certificate issuers ?

No we cannot use LetsEncrypt for convenience reasons (we bake our certificate pub key in many places)

> No we cannot use LetsEncrypt for convenience reasons (we bake our certificate pub key in many places)

Why does that matter? Pretty sure you don't have to change your public key to get or renew a Let's Encrypt cert.

we spawn our servers and scale them up and down. We terminate ssl internally to our applications which are on Docker.

Letsencrypt is painful on docker. I dont mind paying 40$ per year for a wildcard ssl certificate.

Why not keep `/etc/ssl` inside a volume mounted by each docker container and run letsencrypt outside of docker? Each docker container doesn't need its own instance of letsencrypt; it just needs access to your key.

If you use the DNS auth, its actually not bad: you can securely issue the certs on a different machine and just copy the PEM files to the right place. I used this with Route 53's API and it works quite well and is (in my opinion) superior to having to place files.

Use self signed certificate with your own CA.

There is no reason for these apps to have a public cert. An app shouldn't be publicly exposed.

xenolf/lego in DNS mode FTW.

Can confirm, Lego on k8s is really pain-free to use. Following the official documentation meant that I was able to have HTTPS running on our Google Cloud load balancer within 30 minutes.

You can get a Let's Encrypt certificate manually; you don't have to automate it. There are a few options, including https://gethttpsforfree.com/ by 'diafygi, which involves running some openssl commands and pasting public keys and signatures into the web form (which in turn send API requests to Let's Encrypt). Or you can find or build a client yourself.

The only hard part is you'll have to find a way to prove ownership other than email ownership. But if these are public-facing web servers, implementing a response for the HTTP challenge shouldn't be hard, and as the website points out, you can configure all your servers to send an HTTP redirect for the challenge to some other single URL, which you can configure manually. https://letsencrypt.org/docs/integration-guide/#picking-a-ch...

This process is significantly less painful, especially on renewals, than the traditional certificate renewal process. If you're already planning on spending an hour of someone's time a year to request a renewal, pay for it, click a link in an email, etc., plan on spending 10 minute of someone's time every two months, instead. (And an hour is optimistic based on my experience.)

Your public and private keys don't change, since these are renewals. You're just updating the certificates themselves. And certificates are public data (they're sent in their entirety when you make an HTTPS connection), so you can just put them in a git repo or an S3 bucket or whatever else is convenient for your deploy process.

You think it is the same to setup renewal for Letsencrypt and a vanilla cert, but it's not.

We buy 3 year wildcard certs - Rapidssl was about 80$. From about a month before renewal, they start sending you emails and make sure you don't forget.

Letsencrypt is a good idea for larger setups with dedicated devops. For a start-up, it's the exact same argument as Gitlab vs Github.

You can use an existing CSR with Let's Encrypt, so you wouldn't have to change your public key.

Well, Comodo's had an okay track-record, if I recall correctly. But I also don't recall them being cheap.

i have been seriously considering comodo. Their wildcard is not priced all that bad.

According to the this survey I'm ruthlessly stealing from another comment, they have the biggest market share right now: https://w3techs.com/technologies/history_overview/ssl_certif...

That might be because they're the CA underlying Cloudflare's automated SSL issuance - at least for free tier customers.

Comodo, as in the Comodo which tried to trademark "Let's Encrypt" last year? https://arstechnica.com/tech-policy/2016/06/800-pound-comodo...

> Comodo's had an okay track-record,

I am not sure what standards apply to companies in this segment, but Comodo has an awful track record imho. Just looking at the Wikipedia article gives me a shill. And those are only the cases where Comodo couldn't deny any wrongdoing or failure.

Haven't they been hacked more than once?

One of Comodo's registration authorities was breached, but not Comodo themselves. Comodo were able to detect the breach and cut off the compromised RA because they were monitoring what their RAs were doing. Symantec, on the other hand, didn't know that their RAs were mis-validating certificates until I noticed and told them.

(Registration authorities are third parties that perform certificate validation on behalf of the CA. I think Comodo bears some responsibility for delegating validation to an RA that was compromised, but Symantec's conduct has been so much worse in comparison.)

It wasn't one but three authorities which have been breached.

And maybe you should disclose that you are a Comodo reseller.

I used to be a Symantec reseller too before I realized how bad they were. I only do business with CAs which I actually believe are good.

> Anybody know what are the remaining, trustworthy certificate issuers ?

You could take a look at Gandi.net. I don't have any experience with their Certificates, but I trust them with the all their other offerings.

I have heard lots of good things about Digicert, FWIW. No personal experience as my use case can be covered by LetsEncrypt.

Digicert works for us. Wouldn't mind switching to LetsEncrypt but vendors are the issue (oh, the joy of approved lists).

What about Globalsign?

Seconding Digicert. They're expensive, but the most solid and trustworthy option when it comes to "old school" cert providers. EV, Wildcard, code signing.

The fun thing is that RapidSSL was the biggest problem when they were trying to kill 1024-bit roots for example.

Also wondering this, as I'm about to buy a new cert.

I switched to DIGICERT when Verisign started buying everyone up (then Symantec bought them). I haven't looked back...except for dev boxes where I can get away with Let's Encrypt.

For business I highly recommend DIGICERT. They are an independent company.

Thanks.

DigiCert

https://www.digicert.com/

Great company and good people involved in CA/B Forum who advocate on behalf of user security. They'll never pull some of the nonsense the other CA's attempt and I can't recommend them enough.

edit: to add, DigiCert were one of the only CA's to support Google's motion to reduce max cert validity period to 12 months, which didn't pass[0]

DigiCert were also the CA that helped us get Tor onion addresses validated which eventually became a standard

[0] https://cabforum.org/pipermail/public/2017-January/009374.ht...

Very cool, thanks for that. Their prices are super super super expensive though.

Almost 10x as expensive as Comodo for wildcard .

As others have said, Digicert is good, as is IdenTrust (though neither are cheap). You might also look at HydrantID, which is rooted to QuoVadis, who've been around a good long time.

> Intent to Deprecate and Remove: Trust in Existing Symantec-Issued Certificates

When I read that something like this popped up in my head:

"Google is using the nuclear option on Symantec. Neat!"

Perhaps it's neat for you, I just found out that our newly issued EV certificate status is being revoked in the next build of Chrome, so our expensive EV certificates may as well be $5 StartSSL certificates.

I imagine that there will be a lot of angry customers asking for refunds from Symantec/Verisign for certificates already issued which no longer conform to the offered product.

How recently did you renew? This has been in the works for over two years,I'm surprised that anyone is still giving them business.

We renewed recently, through our hosting provider who have Symantec in their certificate chain.

I would contact your hosting provider. They are going to have to find a new CA themselves and when they do, I would guess they would be willing to mint you a new EV cert.

I for one find it totally neat that people realize their expensive EV cert was a waste of money. Although that was true before, too. EV certs are a waste of money, the only thing they do is show a green bar. They don't improve security.

Absolutely, I totally get that, it's worth mentioning that we take our TLS implementation seriously (HSTS, no TLS1.0, etc) and score an A+ on SSLLabs test: http://i.imgur.com/QbH4YZS.png

The green bar with our company name in it translated in to a measurable conversion increase week for week from guest checkouts, so saying it's a waste of money isn't strictly true in our case.

It proves (if the issuer has done their job) that the organisation requesting the certificate has been properly vetted, so you’re more likely to be doing business with the right website.

As the neighbor comment points out, EV validation is absolutely not a waste of money. I've been part of A/B testing on most aspects of domain security and it's arguably one of the best ROIs out there for e-commerce sites.

They don't improve security -- that is true.

> I've been part of A/B testing on most aspects of domain security and it's arguably one of the best ROIs out there for e-commerce sites.

That's a bit hard to reconcile with the fact that Amazon.com can't be bothered to get one.

amazon has brand recognition, they don't need to assuage people's semi-conscious perception of site trustworthyness.

Most outliers are hard to reconcile with the mean.

Amazon as a brand already has the trust of visitors to the site, through sheer pervasiveness in our culture.

Non-household name eCommerce sites benefit significantly from quality signals like the EV bar, however.

Wow, that's interesting. Would you mind share numbers like percentage of A and B group?

So you're serving an EV vs. DV/OV some random % of the time for same site and measuring conversions? Mind sharing the data?

They can improve security. We used to pin the EV roots of a couple CAs that we trusted in our mobile apps and in the browser via hpkp. This protected against someone tricking or coercing a lesser CA into issuing a DV cert and MITMing us.

I don't understand how EV vs DV factors into certificate pinning here.

If we had a DV cert and pinned the DV root then the barrier for an attacker is a lot lower. They just need to jack our DNS and get their own automated DV cert issued quick.

Why does EV make a difference here? Can't you pin an intermediate or root cert from your CA of choice and avoid other CAs issuing end certs for your domain just as well?

I think the idea here is that they're not trying to prevent other CAs from issuing end certs, they're trying to only allow certs for their domain - from any CA on their short list - if the owner of the cert has been through Extended Validation.

Of course, this only works if the CA _actually_ makes sure they don't use the root you pinned for DV issuance. Just because it says "Ultra Great EV root" in the CN doesn't provide you that security, and it won't count as mis-issuance so long as the DV certificate doesn't have an EV policy OID baked into it.

If we'd asked in 2015, Symantec would probably have pointed us to CrossCert's CPS which said they only use certain Symantec roots. In fact Symantec had no mechanism in place enforcing that, CrossCert could and did issue from any Symantec root, whether it was on the list or not. So, if you chose a root thinking "I don't trust CrossCert, but they don't use this root so it's fine", oops, too bad.

EV certificates have the same level of confidentiality and integrity as DV certs, but they have different authentication - specifically, they tie the certificate to a legal entity rather than a domain name.

ie.

    https://paypal.com-customerservice.ru

    PayPal Inc [US] | https://paypal.com

I run https://certsimple.com. We sell EV certs. But you can verify the above pretty easily by checking out the EV guidelines, the additional requirements that apply only to EV certs (https://cabforum.org/extended-validation/). You can also see the difference with openssl pretty easily:

Here is a DV cert:

    openssl x509 -in domain-validated-example.com.crt -noout -text | grep Subject
     OU=Domain Control Validated
     CN=example.com
     DNS:example.com

Here is an EV cert:

    openssl x509 -in extended-validated-example.com.crt -noout -text | grep Subject:
       jurisdictionOfIncorporationCountryName=GB
       businessCategory=Private Organization
       serialNumber=09378892
       C=GB
       ST=City of London
       L=London
       O=example Limited
       CN=example.com
       DNS:example.com -

Your pricing is very reasonable and I've just placed your website at the top of my to-do list tomorrow morning, thanks for posting.

Thanks! We're actually about the middle of the road price wise, our main thing is tech: the EV process can be pretty painful, our role is to speed it it up and make it easier. We start checking against government directories in 63 countries prior to payment, use webcrypto in supported browsers to quickly generate CSRs, make instant-paste openssl / windows scripts to make an ECC or RSA keypair quickly if you prefer to make keys on your own servers, we have a LOT of country specific logic, a meta directory of 'Qualified Independent Information Sources' to handle that part of the EV requirements, we validate in realtime and a bunch of other stuff to save you time and effort - https://certsimple.com/about.

There's cheaper options around, but we only do EV and we're the best at it.

Your mobile page doesn't show any pricing, and the FAQ redirects to the front page.

I'm bookmarking your page for when I need it...

But that overlay just before I started reading your landing text is a serious mood-killer. I'm not going to set-up a remainder for when my certificate expires before I read your page.

That and the browser notifications request for every other blog online is starting to really tick me off.

If a site with an EV cert is being spoofed using a similar-looking domain name and a DV cert, how realistically is the user going to remember that the real site is supposed to have an EV cert? (Besides just maybe remembering it for Paypal in particular.)

See also the Nordea section at https://hsivonen.fi/bank-idp/ . How is a user supposed to form a mental model about multi-server org who don't use EV consistently?

That's a legitimate concern. The bank in the link is harming itself with mixed validation and further issues with mixed content (and yes the banking industry surprisingly bad at crypto - Barclays in the UK has mixed content issues pretty frequently).

There's no simple, single answer here: you can stop validation downgrades is pinning to EV roots but browser UI is also a huge part: mobile Safari, for example, simply uses the validated legal entity as the address and keeps it on screen during the entire session (even when you scroll). Visit https://stripe.com on mobile Safari and you'll see

> _______________Stripe Inc.______________

...persistently on top of the screen throughout the entire session [1]. Other browsers don't show validated identity as effectively though.

[1] Safari should also add a country indicator to distinguish other validated legal entities called 'Stripe, Inc.' in different jurisdictions.

My understanding is that there is no reason why a DV certificate's Subject can't also identify the legal entity. It doesn't authenticate that the key binds to that legal entity (only the domain), but the Subject line can still be at least informative, even if not authenticated.

What makes an EV cert an EV cert is that it contains a Certificate Policies extension. (There are also requirements for the EV to have certain things in the Subject; I'm only saying that they're not necessarily forbidden from the Subject in the DV case.)

That said, many CAs like to overwrite whatever subject you give them with stuff like what's in your example. But you can find examples on the Internet where this doesn't hold, and the Subject contains useful information (e.g., Wikipedia, Let's Encrypt, Google).

One of the things I wish that x.509 was would be that certificates could have been simply a signed (CSR + additional data from CA); since CSRs are themselves signed, this would have prevented the CA from being able to change the CSR after it's submission; that is, the process of submitting the CSR would give the CA two options: append information and sign, or not sign. As it is, their first option is "rewrite the cert however we like and sign"

It doesn't matter so much for the Subject, but CAs will also do things like take a requested extension that has the critical bit set in the CSR, and mark it as non-critical in the certificate. (or even flat out drop the extension) A dev who blindly assumes that the CA will either do as asked, or refuse with a reason then runs the risk of putting a certificate that was really ever requested into production.

(One, I suppose, could assert that allowing free-form Subjects might cause a CA to sign a cert whose Subject is lying or misleading, which could be bad if the reader thinks the signature implies validation of that data.)

Take a look at Baseline Requirements section 3.2. CAs have to have a basis to believe the subject information they include in the cert, although of course EV requirements are more stringent. E.g.

> If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation.

What? Of course they improve security. They reduce the risk the user has accidentally navigated to a squatted typo-domain registered by an attacker (or the correct domain, but the registration somehow accidentally expired and was reregistered by an attacker)

Should've gone with a better vendor. Symantec has been a known bad actor in this field for years now.

If they're going nuclear then it's akin to merely lobbing tactical nukes on military bases, not city-busters on some megalopolis.

They're "only" planning to remove the extended validation indicator and reduce the maximum validity time instead of completely phasing out the root.

Good. The security of certificate system is dependent on an incentive model where misbehavior is punished with revocation. It is important not just because we shouldn't give individual authorities trust after they have demonstrated themselves untrustworthy (although that is an important factor), but also as a punitive measure to disincentive misbehavior.

It amazes me how often Symantec is in the news about the same subject, yet they seem to be incapable of learning a lesson from it.

As they say "It is difficult to get a man to understand something, when his salary depends upon his not understanding it."

I don't think that's the case here, I think Symantec understood perfectly but thought they were too big to get anything more than a slap on the wrist from Chrome. Chrome's previous sanctions on Symantec, though very helpful for those trying to evaluate Symantec and inconvenient to implement on Symantec's side, were not much of a threat to their business.

If they were learning lessons from it, they wouldn't be in the news so much for it.

Google's also been looking to limit the maximum validity lifetimes in general through the CA/B Forum[1] in a ballot that ended up not passing (with hints[2] that Chrome would end up enforcing something similar itself even if it wasn't part of the Baseline Requirements).

This seems to be indicative of the general indication that Chrome wants to head in anyway[3].

[1] https://cabforum.org/pipermail/public/2017-January/009373.ht...

[2] https://cabforum.org/pipermail/public/2017-February/009746.h... - there was a more explicit post elsewhere but I can't find it in the archives right now

[3] https://twitter.com/sleevi_/status/829804370900426752

> with hints[2] that Chrome would end up enforcing something similar itself even if it wasn't part of the Baseline Requirements

Kinda undermines the idea of having a standards group if Google is going to strongarm the industry by doing their own thing anyways

"Baseline Requirements" sort of implies that what is specified is minimum, rather than exhaustive, rules, and that specific applications will have additional rules.

And they all do.

Mozilla's rules are public so you can go read them, and indeed you can help write them. But most famously they required all CAs to disclose loads of stuff, and they require CAs to do lots of stuff in public where everybody can see it, not behind closed doors where we don't know what they're up to.

Google's rules include lots of stuff about their Certificate Transparency idea, which has helped no end.

Microsoft's rules famously include them getting a veto where they can order any CA to revoke a certificate or else leave their trust programme. They mostly use this to zap malware / phishing sites.

Apple's rules forbid having lots of roots at once. Although apparently this didn't apply to Symantec, or various other people. Huh.

> Kinda undermines the idea of having a standards group if Google is going to strongarm the industry by doing their own thing anyways

In any industry where a single actor has a clear majority of the market share, you either vote with your feet (and implore all your friends to do so as well) to bring the powers back into equilibrium, or you cross your fingers and pray that Goliath is (and remains) benevolent.

You wouldn't want a standards group that somehow mandates all clients must accept all valid certs, right?

The standards group in question is unfortunately impotent. Two totally reliable voting blocs: the browsers and the CAs. There are more CAs than browsers, so the result of every vote is in the favour of the CAs.

As was noted above, they have a constituency representation system so ballots have to pass with support from both constituencies, rather than an absolute majority of members.

I expect the browser to look out for my interests as the user. How could the browser do that if it lets the CAs set the terms in the CAs' favor?

Ballot 193 subseqently passed, limiting maximum (Web PKI) certificate lifetime to 825 days from March 2018.

That's definitely not enough to keep Ryan Sleevi happy, but it may be enough to buy CAs a bit more breathing space.

Symantec thinks Google is being inflammatory. Symantec fired the people who made the test cert a couple of years ago.

Here's Symantec's press release:

Google’s statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading. For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program. This control enhancement is an important move that other public certificate authorities (CAs) have not yet followed.

The 30 000 certificates don't have any documentation. The BRs require that a CA keeps documentation showing how they validated the Subject, because without that any CA could issue anything and then say "Er, I forget why, but it was definitely OK" and who can prove they were wrong?

CrossCert wasn't able to produce any documentation for the certificates they got Symantec to issue. Maybe their dog ate it, or they kept it in the Recycle Bin on somebody's laptop and then mistakenly hit "Empty" one day. Most likely they simply never created the documentation at all, because Symantec had never asked them to produce it, so why bother?

But that means we have no reason, other than a general sense that CrossCert appear to have been incompetent rather than malevolent, to believe any of those certificates was actually validated. On that basis they're mis-issued, and so Symantec revoked them.

The 127 certificates discovered by investigators are clearly bogus, some aren't even for valid domain names, but the thousands of others weren't magically fine - we have no idea, and not having any idea is itself unacceptable.

It is true that Symantec shut down their entire RA partner programme (the relationship with CrossCert and half a dozen others) without explicitly being told to do that, and personally I felt that might be enough, but Google clearly don't see it the same way.

Not much focus in the comments has been put on the 9-month certificate validity, but it seems like that is going to be almost as big a punishment for Symantec as the deprecation. Because dealing with SSL is so painful for some large corporates, being told that you have to go from a 3 year renewal schedule to a 9 month one would be enough to cause many to go looking elsewhere.

Since certificate revocation is pretty much unworkable, reducing the maximum lifetime of certificates is probably a good thing for security in general.

SYMC is at an all time high, and every one of their EV certificate customers is about to start talking to different security vendors. The Jan18, Jan19 near ATM puts are quite reasonably priced.

Crazy! A third of SYMC's revenue might be going POOF! and the market is just shrugging?

They'll all be caught by surprise and lose their shirts when Symantec releases their financials next quarter and the stock tanks. The market is full of ignorant people.

Just remember that the market can afford to be wrong longer than you can afford to bet against it.

Usually I agree, but SYMC is at an all time high and trading at 40x price per earnings. The price already implies a massive bet on increased profits, but there is no way that is going to happen.

It's a bit scary how much power do browser creators wield. Even if it's being used for good.

It's better than it used to be. We have 4 major browser vendors now, Apple (Safari and iOS), Microsoft, Google (Chrome and Android), and Mozilla, all of which have plenty of market share and none of which have most of it.

There was a long period of many years when IE was king and anything else was irrelevant. There was also, even earlier than that, a period where Mosaic/Netscape/Mozilla and its kin were dominant.

This is the best it's been in a long time in terms of no single browser maker controlling the market.

Indeed, there was a set of roots IE 5.01/NT4 SP6/Win2000 and later trusted, and at that time only XP did automatic root cert update making them very valuable. Just before then, I think IE/SChannel only trusted VeriSign/Thawte/CyberTrust, and VeriSign bought Thawte just after IE 5.01 and NT4 SP6 was released.

It will be interesting to see what happens when a Chrome user can't access his bank web site because of this, and the bank tells her to switch to Firefox/IE/Safari.

Related: not valid certs should show a red warning after accepting them: https://bugzilla.mozilla.org/show_bug.cgi?id=1349897

is this for all the certs or just symantec certs?

Why not immediately begin treating these connections as plain HTTP? Don't show the padlock or "Secure".

Don't fail the connection, so people will still be able to use the site, but don't present it as secure.

This would be a stronger action than treating EV certs as non-EV, which only a few geeks will notice. Or reducing the maximum age of certificates.

As someone who just renewed a Symantec EV cert (for a pretty penny), this would super piss me off.

The steps Google has laid out seem proportionate to me. It clearly gets the message across without unduly burdening 3rd parties like me.

And it has nudged me to look at other CAs. Unfortunately the first good option I've looked at--Digicert--has also been publicly rapped on the knuckles by Ryan Sleevi this month.

Pissing off Symantec customers is a necessary evil in this case. It's a sign that the strategy is working.

Some Symantec customers are in a position to file a complaint with Google well over the heads of the Chrome cert team. Some have many $millions of transactions dependent on Symantec certs, and aggressive legal staff.

Imagine if Chrome started reporting all Apple and Microsoft domains as insecure, with no warning. That's straying into very deep waters.

To be clear: I support Google's action against Symantec, and it is causing me to look at other CAs. But I need time to make an orderly change.

You can't compare Symantec with Apple and MS, since Apple and MS are competent.

If you think someone might sue Google, on what basis? And Google is more than capable of defending itself.

I agree about the time needed to make an orderly change, which is why I didn't propose that connections fail yet, only that they not be presented as secure in the UI.

Apple and Microsoft buy their TLS certs from Symantec. All their sites would be affected if Chrome abruptly stopped trusting Symantec certs overnight.

Imagine if everyone going to Apple.com in Chrome suddenly saw "site insecure" when they were trying to buy an iPhone--an area where Google is a direct competitor.

That would be a significant barrier to overcome.

It's not tortious interference with Symantec's business (who are still "free" to issue whatever they like).

Google is under no obligation and cannot or should not be coerced into saying "You have to accept Vendor A's CA so that they can continue to represent Vendor B's SSL certificate as 'secure'."

That's also very deep water that might result in some 'diplomacy' but with little actual legal position.

And teach your grandpa it's ok if his bank's website no longer displays that green address bar?

Making your grandpa think everything is right with the bank defeats the whole point of what Google is trying to do.

Symantec being well... Symantec, I'd expecting them to lawyer up in order to delay, or outright block this.

They're big enough to afford the higher end law firms likely needed too. :(

They're not bigger than Google. And it's Google's browser and the open source Chromium project, so I'm having a hard time seeing how Symantec is going to get a judge to say anything along the lines of "I forbid any and all members of the Chromium project to commit anything to the codebase that would no longer treat Symantec issued certificates as before". Especially considering since plenty aren't under US jurisdiction nor necessarily employed by Google.

Then they'd also have to strong arm Mozilla, Apple and Microsoft since they're rather likely to act too and at least the latter two don't disclose such changes until they've made them.

Sure, it'd probably be an uphill battle.

But, Symantec has generally shown little/no morals in past times when it comes to attempting to protect their business interests. Not really seeing why this would be different. :/

Anyone have any more information on the incidents that triggered this response? I was able to find this article on Google's Security Blog: https://security.googleblog.com/2015/10/sustaining-digital-c...

But that's almost 2 years old. Have there been any more recent incidents that I'm unaware of?

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

https://www.mail-archive.com/dev-security-policy@lists.mozil...

TL;DR: in 2016 Symantec issued unauthorized certs for example.com (owned by ICANN) and a multi-domain cert with SANs for test1.com, test2.com, test3.com... even though those domains are each owned by very different organizations and did not all agree to have a common cert.

It's more than that. The ensuing thread uncovered that Symantec had exercised very lacking oversight over their partners (called Registration Authorities, or RAs) who were allowed to perform certificate validation on Symantec's behalf.

...and at least one of those RAs didn't seem to be doing any validation at all!

What's Mozilla doing?

like the post linked says, Mozilla(and the other browsers) have yet to announce/decide anything.

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

As far as I can tell, discussion about what to do with Symantec was ongoing, Google didn't think the outcome was going to be what they wanted, and then enacted a different policy on their own.

I was wondering the same thing. In previous cases, it seemed that Mozilla and Google acted as one, by working off the same NSS trust database. Has something about that changed? Apparently Google thinks Mozilla is moving to slow on this one?

We need a service to check if your certs could be flagged as bad. Especially since this spans so many brands (Symantec, Equifax, VeriSign, GeoTrust, Thawte, etc). Something like, plug in the domain name, and it'll tell you if you need to update the cert.

Since Google typically enacts the restricts through major Chrome updates, running the Beta version of Chrome can give you some early warning at least.

Is there a list anywhere of which EV cert providers use Symantec as a CA?

From the Google link on Symantec root certs:

http://pastebin.com/raw/nUEq5cFP

Not sure if all of them issue EV.

I extracted a readable list of cert providers:

  Equifax
  VeriSign
  TC TrustCenter GmbH
  RSA Data Security
  Equifax Secure
  Symantec Corporation
  GeoTrust Inc.
  Thawte Consulting cc
  thawte
  Thawte Consulting
  Equifax Secure Inc.
  TC TrustCenter for Security in Data Networks GmbH
  The USERTRUST Network
  Thawte

Source here in case I screwed up or anyone wants to verify my terrible regex: https://gist.github.com/JodiWarren/376aebbf7ce6902b06766843f...

I do not know how to observe if this has been accepted, does it not require 3 others to approve and say 'looks good to me' to continue with this proposal?

sorry if I missed this...

But why is https://w3techs.com/technologies/history_overview/ssl_certif... saying Let’s Encrypt has 0.1% when https://letsencrypt.org/stats/ says 32 million Fully-Qualified Domains Active?

32 million = 0.1% 32 000 million SSL certs? = 100%

? what?

The Let's Encrypt roots were cross-signed by IdenTrust, who are number 2 in that table.

Judging by the explosive growth of IdenTrust, which cross-signs Let's Encrypt's certs, I'd guess that Let's Encrypt certs are being counted under IdenTrust.

TLDR: Look at the IdenTrust numbers if you want to know the real Let's Encrypt numbers.

Not many people use Let's Encrypt's own root for their validation chain when they use Let's Encrypt certificates. The Let's Encrypt root is not propagated widely enough across clients.

We (Let's Encrypt) have a cross-signature from IdenTrust, that's what most people use because it's widely trusted. IdenTrust issuance is otherwise very small, so you can effectively consider the IdenTrust numbers in charts like this to be a proxy for Let's Encrypt.

-Josh from Let's Encrypt

W³Techs also understates the fraction of "web sites" that use LE certs because it counts only the 10,000,000 top sites. But LE alone has current valid issuance covering over 30,000,000 subject names, most of which are small sites not in the top 10,000,000 sites by traffic volume or search engine ranking.

https://w3techs.com/technologies

https://letsencrypt.org/stats/

in chris palmer mar 23, 19:33 (9th answer)

> Combined with the gradual move to certificates with shorter lifespans anyway (as a way of coping with problems like this, and with the difficulty of certificate revocation generally), automation is a necessity going forward.

Interesting. What are the effects of automation? E.g. is it possible to automate the update of EV certs? Is this opinion fueled by the idea that websites should be hosted in the public cloud? What is OWASP's stance?

Where can I find more on pro & con automated cert renewal? Around the time when Letsencrypt was introduced, there must have been someone who wrote an informed article/blog on automated cert renewal.

I'd rather trust Google to be a/the defacto CA than some has been AV company.

What is the chrome release schedule? i.e. what is the timeline for the 59 - 64 releases to happen? A quick google isn't getting me an answer(and I don't use Chrome, so don't really pay attention).

What'd you search for? I typed in: chrome release schedule

and this was the first link: https://www.chromium.org/developers/calendar.

Thanks! My date math says:

Chrome 59 (Apr 13, 2017) certs invalid after 2020-01-31

Chrome 60 (May 25th, 2017) certs invalid after 2019-09-09

Chrome 61 (Jul 20th, 2017) certs invalid after 2019-05-02

Chrome 62 (Aug 31st, 2017) certs invalid after 2018-12-09

Chrome 63 (Oct 12th, 2017) certs invalid after 2018-07-18

PKI is broken. The problem isn't the crypto, it's the wardens.

Unless Mozilla and IE goe along with this, effected orgs could just inform users that Chrome is not a supported browser? Have we heard from the other browser vendors?

"We now do not support the one browser that has over 50% of usershare." To me, that seems to be the equivalent of shooting yourself in the foot...using the Tsar Bomba.

If this also applies to Chrome on mobile, good luck telling almost all Android users to switch browsers.

Let's be honest, switching your cert is a far cheaper option than the lost business of telling 50% of your users that they need to switch browsers. Whith ecommerce sites being so hyper focused on abandoned cart stats, this is the easiest change they'll make all year.

For ecommerce yes, but the people most impact here are prob. banks... and if somones back tells them they have to install and use FF or use Edge over Chrome, they will probably do it.

"...pour encourager les autres"

In English please?

Take a second look. It's just another dialect of Latin.

Byng's execution is referred to in Voltaire's novel Candide with the line "Dans ce pays-ci, il est bon de tuer de temps en temps un amiral pour encourager les autres" – "In this country, it is wise to kill an admiral from time to time to encourage the others."[1]

[1] https://en.wikipedia.org/wiki/Battle_of_Minorca_(1756)

Why trust central CA who say security charge for it but do not implement it? Why not instead use a distributed security model such as LetsEncrypt and Blockchain?

The whole security model of the web is quite centralized maybe we need something more distributed? What if you had strong hashing on content, distributed webservers and distributed content?

I'd be very surprised if Symantec doesn't have some backroom deal with intelligence agencies, and not just in the U.S. either, especially since they've acquired BlueCoat - a "security company" known for selling surveillance tools to authoritarian regimes - and after they made the BlueCoat CEO the CEO of Symantec.

Prior to the Symantec aquisition, VeriSign used to pitch just this thing as a product. AFAIK the usage was limited to DoD and a few mundane things.

The IC wasn't interested because it was easier for them to just steal certificates or work around TLS completely.

Interesting that it would be "so much easier" for the U.S. intelligence community to steal most certificates or work around TLS, when countries like Thailand, which have much fewer resources, prefer to get Microsoft to install their own root certificate for them in Windows. Perhaps this is what the IC meant as well, when it said there are other easier ways? Why bother with Verisign's solution, when they could have their own root certs in Windows?

The CA system is such an untrustworthy mess.

http://www.theverge.com/2017/1/25/14381174/microsoft-thailan...

Because using your own CA is not deniable. You aren't allowed to move forward with any solution that may lead to attribution.

TL;DR Google prefers to override what the standards say about validity of certicates instead of what would be the logical thing: stop trusting Symantec root Certs. A dangerous precedent.

Can you elaborate? Having trouble parsing whether you think Google is over- or under-reacting.

Google is divesting trust from Symantec but is doing it in a way that avoids hurting end-users and badly breaking the internet. They explicitly state why they don't just want to revoke it in one go and they have really decent arguments. What are yours?

Aside from that, to the best of my knowledge the CA/B forum doesn't set forth any rules that require the immediate and complete removal of trust of a CA that is found to be in violation of the guidelines. I also don't see how they could, the best they could do is put out some form of recommendation but it's up to the parties that actually include the CAs to decide how they get removed, which is normally stipulated in the rules for inclusion in a Root Certificate bundle.

Are they just hoping to drive business to their new CA: Google Trust Services?

That's unlikely, as they currently do not offer certificates to the general public. I imagine if they do at some point, it might be as part of something like their version of Amazon's ACM for their Cloud offerings, or for custom domains on sites like Blogger. I'd expect both to be free. They're also a platinum sponsor of Let's Encrypt.

This happened recently with all my free StartSSL / Startcom certificates. I switched to LetsEncrypt. Also noticing Google and Mozilla's sponsorship.

Google and Mozilla were heavy sponsors of LetsEncrypt (in money and in Mozilla's case manpower too) because they wanted to push out HTTPS more, and mandate HTTPS for some new HTML features. That would have been problematic if certificates weren't free or convenient.

In Mozilla's case, HTTPS is better for privacy. In Google's case, HTTPS makes it harder to substitude their ads.

TLDR: for the next few months, expect to tell your relatives "just click yes on the big red warning dialog". Not sure if this is good conditioning.

The schedule they're proposing tries to specifically avoid as much of this as possible. This is probably as close to "no impact for average users" as you can get if you don't want to accept that too-big-to-fail is a thing in the Web PKI.

Reply on news.ycombinator.com