Live data from Hacker News

Distrust of Symantec TLS Certificates

blog.mozilla.org

101–110 of 124 posts

Re: Distrust of Symantec TLS Certificates

#101
post #88

The CA trust model is totally broken! We pay certificate of authority CA companies a lot of money for certificates that are not fully confirmed to be authentic. Here is a better model. You normally register your company with the local government corporate registration authority. The local government knows who this company is, who the corporate registrars are. One should use a digital ID card to apply to register a co…

> One should use a digital ID card to apply to register a company. The founders sign the registration of the company with their personal digital ID. The company is then registered. To apply for a domain name for a company should be digitally signed. The registration government authority should handle certificate of authentic not foreign CA registrars.

You must be from Estonia. Or on crack. I'm guessing Estonia.

A lifetime of experience has convinced me that we will have hoverboards, hell, self-flying hoverboards, before such a scheme becomes the universal norm.

Re: Distrust of Symantec TLS Certificates

#102
post #64

Earlier quoted context omitted.

Yes, this roadmap. It was not followed. All certificates were blacklisted in April, irrelevant of their date.

Are you sure? Paypal.com's Symantec-issued certificate still works in Chrome, at least on my PC: https://www.paypal.com/

Can confirm here PayPal's Symantec Class 3 EV SSL CA - G3 signed certificate validates in Chrome 68 and 69 but returns NET::ERR_CERT_SYMANTEC_LEGACY on Chrome 70

They really need to update their certificate soon

Re: Distrust of Symantec TLS Certificates

#103
post #82

It's been obvious to me for quite a while that EV etc only really tells you "this person paid $$$ to get a cert" rather than anything about the site being trustworthy or being who it says it is. I wouldn't bat an eye if 10 years from now major browsers distrusted everything but letsencrypt. Once the letsencrypt project comes out with a comparable solution for code signing, there is really no more reason for paid cert…

I would bat an eye because it's never good to rely on a single point of failure. Imagine, for instance, that at some point, LE is the only trusted CA for code-signing. If its root key gets compromised for some reason, how are we supposed to move to a new CA if the auto-updaters cannot trust the old CA anymore?

True. They should maybe consider breaking up their operation into 20 or so root certs.

Re: Distrust of Symantec TLS Certificates

#105
post #82

It's been obvious to me for quite a while that EV etc only really tells you "this person paid $$$ to get a cert" rather than anything about the site being trustworthy or being who it says it is. I wouldn't bat an eye if 10 years from now major browsers distrusted everything but letsencrypt. Once the letsencrypt project comes out with a comparable solution for code signing, there is really no more reason for paid cert…

I strongly agree to the conclusion but not the logic. It is an entirely possible situation that while EV indeed is a CV's scheme to earn more $$$ users do care and as a result the user security does improve (most possibly, only a bit though). My own conclusion results from the observation that, well, users don't; see an account [1] from Troy Hunt (of the HaveIBeenPwned fame) for example.

[1] https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...

Re: Distrust of Symantec TLS Certificates

#107
There's two problems this exposes. One, it takes a very long time to dis-trust a root cert. This means some people's connections could be exposed for a very long time.

Two, the method for update shown here is to upgrade your browser. Not everyone can upgrade their browser. Corporations often lock down browser updates, and take a very long time to upgrade. Sure, it's fine for you to say "that's the corporation's fault, too bad for them!" but the users of those companies still have to suffer in the meanwhile - to say nothing of vendored smartphone OSes with slow updates...

The other problem with upgrading is legacy computers run very old browsers. I don't know if you've tried to browse the web on an old computer with a new browser, but here's a secret: it doesn't work. New browsers have so many "advancements" that they bloat and crawl on older machines. So effectively, the means of being able to use the internet requires you to buy a new machine.

If operating systems immediately shipped patched CA lists, and browsers immediately used them, that would patch the legacy browsers. But it would not prevent sites from immediately breaking. So no matter what, either we wait forever to dis-trust certs, or we break sites.

Clearly we need an option C that will allow site owners to upgrade their keys immediately and without issue, and users to update their CA lists immediately and without issue. ACME is a good start, but it too has issues that need to be solved.

In addition, the whole idea of trusting hundreds of root certs to sign for every domain is just crazy. We need a method to sign certs only by the organization who actually has responsibility for ensuring the ownership of the domain: the registrar.

CAs are a great "hack" because they allow browsers to verify certs of sites without ever putting any onus on the registrar, but they also have a wacky "trust" model. Any of hundreds of organizations can verify who controls the IP space of a domain, one time, and issue a magical assurance of this, which is trusted until the assurance expires in several years. This can be overridden at any time, and it has nothing to do with who actually controls the domain, which is the registrar and the user who registered it. All the current system really verifies is who controlled the DNS at one time, which is merely pointed to by the registrar, and can be hacked independently of the registrar, meaning there are extra attack vectors.

Yes, lots of little extra "hacks" have been added as stop-gaps, like CAA, and Certificate Transparency, the now-defunct HPKP, and the future implementation of cert issuers verifying the DNS and host integrity from multiple ASNs. But these are just to keep the status quo limping on, and ignore the unnecessary risks the current design imposes. We need innovation and better design, not hacks.

Re: Distrust of Symantec TLS Certificates

#108
I've got a question about this, as I've been hurled into the admin of our certs, and honestly I probably shouldn't be the one to do it, lol.

But, we run root certs from DigiCert with the rest of the chain provided by RapidSSL. However, I have not received any depreciation warnings via email or any notification in the console output on these sites.

Is there a utility available to "check" our sites, in the same way vendors provide utilities to verify your cert installations? Or should I assume that our stack is going to get caught up in this, and move to find alternative certs now?

Re: Distrust of Symantec TLS Certificates

#109
post #98
post #65

Earlier quoted context omitted.

I was a technical lead for a project involving a) governments and b) lots of income from taxpayers, and I noticed this warning about Symantec certs a while ago from a Qualys scan I ran on the third-party payment website. I told my manager and our client about this several times before being laid off, and I would bet they never did anything about it. I'm wondering how this is affecting them.

When it actually /breaks/ something they'll divert resources to fixing it.

[deleted]

Re: Distrust of Symantec TLS Certificates

#110
post #7
post #3

When such an error (see article) is presented, it’s a teachable moment not only for the user surfing the site, but also for the owner of the site who is going to field questions about the error message from users. It would be great if Mozilla would include some wording that instills alarm in site owners about how the site’s information, not just the user’s, is at risk. For example, most non-malicious site owners prob…

> It would be great if Mozilla would include some wording that instills alarm in site owners about how the site’s information, not just the user’s, is at risk. I'd expect the reseller to inform the buyer about the distrust of these certificates. The SSL reseller we use informed us before April this year.

I’m not talking about the distrust though. I’m talking about how to convince sites why they should give a care about the distrust. Many of them have no cares to give because they are missing this part of the picture.
Post reply on HN