Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

groups.google.com

Post reply on HN
Print view View original

81–90 of 329 posts

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

#81

Post by aianus »

gcp wrote: post #32
aianus wrote: post #23

Earlier quoted context omitted.

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.

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

#82

Post by gcr »

sandGorgon wrote: post #59
Ajedi32 wrote: post #52

Earlier quoted context omitted.

> 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.

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

#83

Post by msbarnett »

ceejayoz wrote: post #31
zorpner wrote: post #22

Earlier quoted context omitted.

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 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.

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

#85

Post by tobltobs »

looklittlejohn wrote: post #65
sandGorgon wrote: post #49

> 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…

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

> 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.

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

#86

Post by yuhong »

sandGorgon wrote: post #49

> 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…

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

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

#87

Post by phaed »

ergothus wrote: post #62
jasode wrote: post #38

Earlier quoted context omitted.

>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 m…

or 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.

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

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

#88

Post by DaiPlusPlus »

Sir_Substance wrote: post #68
ygjb wrote: post #50

Earlier quoted context omitted.

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…

>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 corn…

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)

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

#89

Post by zie »

jstrom wrote: post #78
zie wrote: post #53

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…

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.

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

#90

Post by specialp »

spelunker wrote: post #21
stevecalifornia wrote: post #16

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 certi…

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.
Post reply on HN