Live data from Hacker News

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

groups.google.com

251–260 of 329 posts

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

#251
post #26
post #15

Earlier quoted context omitted.

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.

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

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

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

#252
post #125
post #24

Earlier quoted context omitted.

> 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

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.

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

#253
post #26

Earlier quoted context omitted.

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

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

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.

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

#254
post #111

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?

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…

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/

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

#255

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

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

#256
post #233

Earlier quoted context omitted.

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.

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

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

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

#257

Earlier quoted context omitted.

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

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

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

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

#259
post #2

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

And none have ever deserved it more than Symantec.

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

#260

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

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