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.
If you want to dig a little deeper, here's the last version of the BRs:
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.
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.
> 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 firstname.lastname@example.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.
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.
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".
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.
I found this attached PDF interesting as well: https://bug1334377.bmoattachments.org/attachment.cgi?id=8831...
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...
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 .
"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 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.
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.
Are you sure? I've never heard/seen/notice anyone non-technical care remotely. Or even know what it means.
It's on the checklist of things companies ask about when assessing third-party services.
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!"
It has the secure padlock as an image on the page! And a green check mark!
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? :/)
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.
(Yes, I gave the client a strongly worded statement of my misgivings - and all the other bad code-smells in the project)
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 :)
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".
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.
If you make such astonishingly obviously poor decisions, you deserve to fail.
And market consumers lack the technical ability to discriminate between anything more finely grained than "works" / "doesn't work."
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)
I don't know if they have actively used it to issue SHA-1 certificates, but they certainly could.
Given the G1 root they pulled has an intermediary called "Symantec Trust Services Private SHA1 Root CA", I can make some guesses...
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...
Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
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.
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.
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
GeoTrust was started from buying Equifax's security business. Symantec bought GeoTrust. Symantec doesn't own the Equifax brand or company.
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'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?
Do we know that Symantec is being malicious, or just lazy like Google's response to spam?
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.
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.
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 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!".
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.)
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.
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?
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).
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.
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...
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.
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...)
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.
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?
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?
4) Banks require Chrome 55, "here's a download", good thing it's open-source, and we get the IE6 story again.
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.
The general public doesn't care about inside baseball. Site operators can't afford not to work perfectly with Chrome.
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
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.
I think the likely result here is more widespread adoption of LE. The point is that CA's shouldn't be businesses.
I think the idiom you want is "brought to heel".
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.
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.
Edit: Oh wait. Verisign and Thawte. Okay, that's some massive excrement on a collision course with the ventilation device.
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.
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.
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?
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.
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.
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)
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.
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.
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.
How would you validate that the initial set of trusted CA roots is actually from those CAs?
(finally, finally there's a use for that quote!)
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
(Archive link: http://archive.is/Cq9VO )
Really interesting reading!
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.
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
> ...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.
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.
The proposal was just made, so you shouldn't expect it to be reflected in code just yet.
>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)
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
DigiCert were also the CA that helped us get Tor onion addresses validated which eventually became a standard
Almost 10x as expensive as Comodo for wildcard .
Why does that matter? Pretty sure you don't have to change your public key to get or renew a Let's Encrypt cert.
Letsencrypt is painful on docker. I dont mind paying 40$ per year for a wildcard ssl certificate.
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.
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.
There is no reason for these apps to have a public cert. An app shouldn't be publicly exposed.
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.
For business I highly recommend DIGICERT. They are an independent company.
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.
(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.)
And maybe you should disclose that you are a Comodo reseller.
When I read that something like this popped up in my head:
"Google is using the nuclear option on Symantec. Neat!"
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.
PayPal Inc [US] | https://paypal.com
Here is a DV cert:
openssl x509 -in domain-validated-example.com.crt -noout -text | grep Subject
OU=Domain Control Validated
openssl x509 -in extended-validated-example.com.crt -noout -text | grep Subject:
ST=City of London
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?
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 . Other browsers don't show validated identity as effectively though.
 Safari should also add a country indicator to distinguish other validated legal entities called 'Stripe, Inc.' in different jurisdictions.
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.
There's cheaper options around, but we only do EV and we're the best at it.
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.)
> 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.
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.
They don't improve security -- that is true.
That's a bit hard to reconcile with the fact that Amazon.com can't be bothered to get one.
Non-household name eCommerce sites benefit significantly from quality signals like the EV bar, however.
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.
They're "only" planning to remove the extended validation indicator and reduce the maximum validity time instead of completely phasing out the root.
This seems to be indicative of the general indication that Chrome wants to head in anyway.
 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
Kinda undermines the idea of having a standards group if Google is going to strongarm the industry by doing their own thing anyways
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.
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.
That's definitely not enough to keep Ryan Sleevi happy, but it may be enough to buy CAs a bit more breathing space.
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.
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.
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.
is this for all the certs or just symantec certs?
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.
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.
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.
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.
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.
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.
They're big enough to afford the higher end law firms likely needed too. :(
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.
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. :/
But that's almost 2 years old. Have there been any more recent incidents that I'm unaware of?
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.
Not sure if all of them issue EV.
TC TrustCenter GmbH
RSA Data Security
Thawte Consulting cc
Equifax Secure Inc.
TC TrustCenter for Security in Data Networks GmbH
The USERTRUST Network
sorry if I missed this...
32 million = 0.1%
32 000 million SSL certs? = 100%
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
The IC wasn't interested because it was easier for them to just steal certificates or work around TLS completely.
The CA system is such an untrustworthy mess.
> 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.
and this was the first link: https://www.chromium.org/developers/calendar.
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
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?
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.
In Mozilla's case, HTTPS is better for privacy. In Google's case, HTTPS makes it harder to substitude their ads.