Sustaining Digital Certificate Security | Hacker News Reader

Sustaining Digital Certificate Security

googleonlinesecurity.blogspot.com

260 pointsfred25689 comments

> It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency.

Symantec said they did an audit, Google spent 'a few minutes' and found many more mississued certificates just from the CT logs. In other words, Symantec can't audit themselves, so Google now require public issuance logs for all their certificates.

> [Google] expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit.

This is a massive (and justifiable) smack in the face to Symantec.

Disclaimer: we're a Symantec competitor, as you may have realised:

https://certsimple.com/blog/seal-in-search

https://certsimple.com/blog/sgc-ssl-certificates

Yes, and a very well-deserved one.

What is a "Point-in-time Readiness Assessment"? I googled it and found it in the requirements for some CAs, but not what it actually is.

"Point-in-time" is a term of art for audit. It basically means that a third party will attest to a given state at a given time. They're in contrast to "continuous" audits, which is more focused on auditing records over a period of time, or on a recurring basis.

A "point-in-time readiness assessment" is kind of redundant, but it basically means getting a third party to come look at their CA (processes, procedures, standards, implementation) and assert on Symantec's behalf that it meets some criteria.

Thanks for clarifying.

Days after the initial reports of rogue certificates being issued, Symantec wrote in their blog that they had already fired employees:

In addition, we discovered that a few outstanding employees, who had successfully undergone our stringent on-boarding and security trainings, failed to follow our policies. Despite their best intentions, this failure to follow policies has led to their termination after a thoughtful review process... At the end of day, we hang our hats on trust, and that trust is built by doing what we say we’re going to do.

http://www.symantec.com/connect/blogs/tough-day-leaders

It's starting to look now like this the fault of systemic flaws at Symantec, and not just a few employees who didn't follow procedure.

Yes, that was a very old-school way of dealing with the problem. It’s mostly symbolic.

Most problems are systemic, which is a nice way of saying “ultimately management’s fault”.

Most things that most people do, most of the time, are reasonable in the circumstances. Management creates the circumstances. “Human error” is a non-explanation.

Here’s a book on the topic, often called systems thinking: http://www.amazon.com/Field-Guide-Understanding-Human-Error/...

Getting even more bookish: firing “bad apples” for “human error” is a form of substituting an easier question when presented with a harder one, as Kahneman describes in Thinking Fast and Slow.

>Most problems are systemic, which is a nice way of saying “ultimately management’s fault”.

Systemic problems are _everyone_'s problems. Both management and employees are a part of the same system. Firing bad apples for human behavior is equally as pointless as firing/resigning management (or pointing fingers).

Managers are the ones responsible for setting the system. Systemic problems are their fault.

Not past a certain level where many people become part of the problem, otherwise replacing managers would be a effective way to fix organisations.

Replacing managers IS an effective way to fix organisations, if there is a systemic problem, if other parts are not problematic and if you find good replacements.

On the subject of managers and systems thinking: http://www.safetydifferently.com/if-it-werent-for-the-manage...

Fair.

Book looks interesting - anyone else think it's worthwhile?

It makes me* uncomfortable that Google has effectively appointed themselves as the internet police and using their power to push people around like this. But at the same time, there is nobody else (?) who is taking care of this, and I suppose the good of someone/anyone looking into and taking action on the sorts of serious problems that Symantec has exhibited probably outweighs my discomfort.

* Disclaimer: Google employee, no connection to any of this cert stuff.

This is how the public certificate authority system is set up. The client vendors (Google, Microsoft, Apple, Mozilla) choose what the rules are for trusting a Certificate Authority and which ones meet the requirements. These "root programs" are the only thing that prevents rogue/incompetent CAs from mis-issuing certificates on a regular basis.

Since the CA business model is based on selling digital signatures that meet specific requirements, the threat of those certificates not working as advertised is compelling.

On the other hand, the client vendors can't go overboard with requirements on existing "too big too fail" CAs because the alternative is having large portions of the Internet stop working in their products due to untrusted certificates.

Edited to add: Google doesn't run its own root program, they use the OS root store, which will be from Apple, Microsoft, or Mozilla (most Linux distros use the Mozilla list). This means that the requirements from Google are in addition to those of the OS that is being used.

AFAIK Chrome comes with its own NSS certificate store and doesn't respect the system certificates. Firefox does the same.

I believe Chrome uses the underlying system trust store but also has its own list that it uses where Google wants to be stricter/do its own thing.

Hmm, searched a bit and it seems only on Linux Chrome doesn't respect the system certificates but relies on Mozilla's NSS store. Still, extremely annoying since NSS isn't where system certificates are stored on Linux.

It's too easy to get certs into the root store of most distros, which means they're not practically usable for secure communication. There's often no auditing of the CAs to ensure they are taking due care to minimise risk of a bogus certificate being issued. [1]

To be fair, some things have improved: Debian (and maybe Ubuntu) now have the Mozilla trust store plus one additional root (SPI). That said, all you need is one bad actor for the system to fail, and it seems the only reason why SPI is there is Debian infrastructure relies on it—but that doesn't make SPI trustworthy. [2]

[1]: https://plus.google.com/105761279104103278252/posts/eVdB6X3N... [2]: http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certific...

All browser vendors IMHO should do exactly this. The CAs want them to entrust them with their customers secrets, they should make sure the CAs they accept work properly.

I'm not sure. There's no real deliniation between Chrome and Google (as brands / entities) - this seems like Google exerting power over another company.

I have no love for Symantec but it doesn't feel right. I wonder if private negotiations have failed and this is Google trying to push the point?

Can you imagine if Mozilla tried the same stuff? I mean, they don't trust CACert any more after CACert wasn't able to verify itself (?) adequately, but this is on a different order of magnitude.

Mozilla was much more forceful when they removed a CA from their default certificate list earlier this year, for lacking in their audits[1], when the post indicates no suspicion of wrong certificate emission.

Compared to that, Google just forcing Symantec to be externally audited after it was shown that, not only have they issued wrong certificates, but also that they are unable to properly audit themselves, is being soft on them.

[1] https://blog.mozilla.org/security/2015/04/27/removing-e-guve...

I think that's less about the browser vendor and more about the CA. The Symantec CAs are the most widely used on the internet (They bought Verisign's CA business and roots) and are used on 4 of the Alexa Top 10 websites (so I'd assume a similar percentage of the rest).

If a browser vendor just kicked them out, users would abandon that browser - just imagine if 40% of your common websites stopped working.

I was thinking about this. They could special-case it to not allow any certificates issued past some cutoff-date. This way the existing internet continues to work but who is going to renew a certificate, knowing it's not going to work in the browser with the biggest market share?

Mozilla runs a root program that regularly enforces similar requirements on CAs. For example, they are currently discussing whether they will require the same of Symantec as Google or even more: https://groups.google.com/forum/#!topic/mozilla.dev.security...

And here is a thread about a Chinese government CA that mis-issued certificates for Google domains: https://groups.google.com/forum/#!topic/mozilla.dev.security...

The alternative, not trusting their certs immediately instead of giving them additional requirements, would also be "exerting power over antother company". Mozilla has done so in the past, and I hope they will do so in the future.

Google's argumentation that Symantec apparantly isn't able to properly assess themselves seems sound to me: if after being told about a specific issue they still are not capable of finding all instances of it happening, while outsiders can do so with the published information, then they they are missing critical abilities in this regard.

Google distributes Chrome, and it is 100% their choice to determine what certificates they want to trust and how they will do so. Just as its Microsoft's decision to do the same for Windows.

Well, no, it's 100% _my_ choice what certificates that I want to accept on my physical devices, but I'm happy to indulge Google's suggested defaults.

True, but you are a rounding error. Almost everyone who uses Chrome is using whatever defaults it provides for CAs, ciphers, etc.

I'm okay with it for two reasons:

1. Google is already my personal internet police, as a Chrome user. Everything from which SSL stack to use, to whether and how to mitigate weak DH keys, to what NPAPI plugins to use, to whether my browser vendor is going off and signing contracts with Adobe about porting Flash to a brand-new runtime, to what sandboxing is in use, is in Google's hands.

I suppose someone could, fairly easily, set themselves up as an intermediary between Google and me, auditing and patching Chromium if necessary, and running their own update server. (Arguably Linux distros do this.) And if so, they have the option of overriding these decisions. (And the Linux distros sometimes do, for things like the default trust store.) But so long as Google is writing this gigantic codebase that I couldn't possibly audit myself, they've not particularly gained any more power by caring about the CA system.

2. Google gets to be my personal internet police because Chrome is good; part of why I run Chrome (and I'm typing this from a Chromebook) is that out of all the participants in the market, I trust Google to be the best at protecting my security, in part because they've shown a willingness to do things like this, and in part because they're developing things like Certificate Transparency (and doing that negotiation with Adobe, and implementing seccomp mode 2, and so forth). I even prefer google-chrome to chromium on Debian, despite generally being a Debian fan, because I trust Google more to do quick security response and to make fewer mistakes. Google only gets to do this because Chrome is a choice by a significant fraction of internet users. Even Opera wouldn't be able to pull this off.

The explanations for why they are doing it that I've seen so far covers that Google is involved in all parts of the problem. Embedded devices, servers, network stacks, now ISP, carrier, laptops (chromebook), web apps, etc...

They need all parts to work optimally and securely, and they get to feel the heat themselves for everything that's suboptimal. So they're working on fixing all of it.

It makes me uncomfortable that the CA system is set up in a way that makes this necessary. If an alternative, such as Convergence, had taken off we wouldn't be in this situation.

If it were done another way, wouldn't it make it hard for the Governments to use NSL-like methods to surreptitiously masquerade as others?

If an alternative, such as Convergence, was perfect, it would have taken off.

This argument is valid only if you implicitly assert that the current system is perfect. Every system has it's trade-offs.

exactly. thats what makes the parent comment so preposterous.

If this is your argument it also requires the assumption that the trade-offs with Convergence are identical in both scale and type to the current system; at least in reference to this specific problem.

I don't see it as Google policing, but more so the industry self-policing.

Google relies on certificates being accurate as much as we do, it's in everyone's interest for this to be happening.

Though I do admit I can see a slippery slope argument with Google's power.

If vendors and industry groups don't regulate themselves, some form of government will do it and likely the consequences of that won't be liked.

We need leaders in security on the Web to push things forward. Otherwise we'd still be stuck with RC4 and MD5 (and in fact we still are because nobody has taken such drastic actions to force them to move...in the past 10 years since they've been made obsolete).

A clear example of too big to fail. If this was any smaller CA (like cnnic before), they would now be gone from the trusted roots.

I wonder what's coming out of this. Personally, I think Symantec doesn't care in the least about Google's sabre rattling here. It's clear to everybody that Google hardly wants to release a browser which doesn't display 50% of the encrypted web sites.

This is a further issue with the current PKI: too few CAs are around (after symantecs buying spree lately) which gives them way too much power to do what ever they want. Furthermore, the process of acquiring a certificate (especially an EV one) makes switching CAs very burdensome, so not even bad reputation will compel people to leave.

What a mess.

Symantec already agreed to start using Certificate Transparency in the near future, as per Google's request. This is a good thing.

Is the CA model just unfixably broken at this point? What should replace it if so?

Convergence was the perfect replacement, but it never gained any traction.

Moxie's talk at BlackHat[0] introducing it is a good watch for those unfamiliar with the idea, and if you want to be wistfully frustrated at what could have been.

[0] http://www.youtube.com/watch?v=Z7Wl2FW2TcA

We still don't know how that would have worked in practice. Even skilled people have trouble making trust decisions reliably for everything and while we'd avoid the compromised CA threat I'm certain we'd start seeing equivalents like dishonest or incompetent notaries – and those might last longer because fewer people see the dodgy results since not everyone is using the same set of notaries.

If it became popular, it's really easy to imagine something like the Great Firewall being configured to block outside notaries to encourage people to use local notaries which are still under the control of the local authorities.

That's not to say it's not interesting work or potentially a solid improvement, only that I would be extremely hesitant to make absolute statements about an untested internet-scale security protocol. The approaches we're seeing work now do so because they're adding to well-understood protocols (e.g. HSTS, key-pinning, etc.) or don't change the trust model (if Google goes rogue, Chrome users are already screwed).

I have no doubt that there would be incompetent or dishonest notaries. The difference being that in an alternative universe, where Convergence is used, a rogue notary doesn't destroy the trust of the entire system. When Symantec is a rogue notary, oh well, Mozilla and Google push out an update and no one uses Symantec anymore, their notary just becomes irrelevant. However, in this reality, the darkest timeline, deciding to stop trusting Symantec immediately breaks 30% of HTTPS websites on the internet, so even though Symantec has given everyone plenty of reasons to stop trusting them, we have no choice. Same for Comodo, their notary would have stopped being used in 2011 (after their root certificate compromise).

Instead, with Comodo and Symantec combined, we now have over 60% of HTTPS websites secured by authorities who are incompetent and/or dishonest.

> Convergence was the perfect replacement, but it never gained any traction.

It's really not.

https://github.com/okTurtles/dnschain/blob/master/docs/Compa...

That sounds like it was written by someone who doesn't completely understand Convergence, and also has an alternative agenda (they want their own solution adopted).

> It is not very user friendly. Users are asked to manage a list of notaries. This list of notaries is stored locally on the computer, or even the browser. Managing this list is not feasible for most users.

Browsers can replace the CA root certs with a notary list and pick notaries at random from the list. This is not a problem like with CAs as multiple notaries have to collude to form a consensus (you only need one rogue CA), and rogue notaries can be removed on a whim, unlike CA roots which are indentured (removing a CA breaks any site that uses it).

> It's not clear how well it protects (or can protect) if some notaries haven't yet cached the latest SSL certificate for a particular website.

This doesn't matter at all. The notary looks the cert, checks the signature and tells you if it matched what you're seeing.

> It does not provide MITM protection on first visit.

Yes it does. If your connection is MITM'd the notaries won't match your perspective.

> Waiting for group consensus means all connections have higher latency (slower page loads).

Only the first visit, before the notaries confirm the certificate signature you're seeing, and then you cache it and only need to check it again if it changes.

> Both Convergence and Perspectives (see below) results in you sharing every website you visit with random third-parties.

Bounce notaries exist for this reason.

> With DNSChain, if privacy is a concern, you can run your own server and only rely on it

Same with Convergence.

Thank you glass-! The information you've provided here I did not find in the Convergence documentation. I've updated the document to be accurate with your reply and added a new, rather significant critique that I somehow missed the first time around. Please feel free to re-review:

> It does not protect you if the MITM is sitting in front of the server you are visiting. Notaries would see exactly the same key that you see (the one that belongs to the MITM).

Something that sets things up so that the actual domain registrar becomes the only valid issuer of certificates for any given domain.

That would kill the possibility of unrelated entities issuing and obtaining certificates (well, unless you go with a registrar that happens to cheat on you, but at least you can avoid shady registrars and limit that possibility. Also if you registrar is that shady, they could already today switch around your nameservers or WHOIS records if only for a second and simply buy a certificate)

Maybe some combination of DNSSEC and cert pinning? Of course, without slowing anything down!

That's called DANE, and it's already in use by a number of websites and supported by many registries. Unfortunately the major browsers do not support it.[1] There's an extension for Mozilla Firefox that implements it.[2]

[1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... [2]: https://addons.mozilla.org/en-US/firefox/addon/dnssec-valida...

Is there a particular reason why it's not supported?

Because DNSSEC can't be trusted. Instead of placing the trust on the commercial CAs that have all the incentive to do a good and trustworthy job if they want to stay in business, DNSSEC places trust on the various countries registries that have all the incentive to abuse their powers for national security or to enforce the current governments beliefs.

Of the two evils, the CA model is slightly better because the incentives align

> [...]Instead of placing the trust on the commercial CAs that have all the incentive to do a good and trustworthy job if they want to stay in business, DNSSEC places trust on the various countries registries that have all the incentive to abuse their powers for national security or to enforce the current governments beliefs.

With very high probability, there are a number of nation-state governments controlling some entries in your CA store. Even a short glance at the content of debian's "ca-certificates" package gives these:

  - CNNIC (China)
  - TÜBITAK (Turkey)
  - WoSign (two certs, one specially named for China)
  - Juur (Estonia)
  - TeliaSonera (Sweden, Finland)

The last two are likely not going to be compelled to issue rogue certs, but technically the data interception laws in Sweden (and the ones proposed in Finland) might not even require any modifications to allow such operations. There are probably a lot more.

Certificate pinning will help, but even that faces a bootstrap problem for new clients. With smartphones being replaced, on average, every two years, there are ALWAYS new clients. Incidentally, a wide-scale MITM for new clients only is something I would expect the Great Firewall to be capable of.

So the commercial incentives for CAs may be more suitably aligned, but there is still overlap with the DNSSEC problems.

If only the registrar holding a domain can issue certs, and for example you don't trust CNNIC or the .cn TLD operator (which also happens to be CNNIC in this case), then you can simply avoid .cn domains and register your domain elsewhere, at a registrar that you trust not to issue fake certificates.

If you cannot trust the TLD operator, then you have already lost, as the TLD operator could arbitrarily fake data in WHOIS if only for a second, and obtain a DV certificate from any CA right now, since a WHOIS lookup for an email address is usually what powers the DV. But at least then you'd eliminate the risk of third parties (not the TLD operators) obtaining a parallel certificate that you don't even know about. Right now, I don't think there's anything stopping CNNIC (or any other root CA) from issuing certs for yourdomain.com, and you wouldn't even know it.

Might bring some value back into the reputation of TLDs and registrars, as a bonus :)

> DNSSEC places trust on the various countries registries

I'm not a security expert. Aren't DV certificates put trust on the registries too? If you control the domain then it's trivial to get a DV cert for the site. So with the CA model you trust both CAs and registries.

Ask to remember certificate at first contact with site, like openssh. Keep certificates in protected wallet, like passwords. Warn about any change of certificate, like Chrome does for Google sites. Get fingerprints of common sites from trusted sources by subscription, like spam and ad blocking lists.

Decentralize the PKI!

How would this make it more secure ?

How to revoke?

Blacklist bad certificates like spam lists.

Yes and no. Moving the responsibility for linking/attesting a secret key to an ip address (and DNS name) to the DNS system is probably the more sane model - but it's not really possible to do in a backwards-compatible way (such a system would be a new system).

The first thing we could/should do, is probably demand support for (sub)domain limits on CA certs. Eg one cert to sign CA certs for .com (but not eg: .cn) - and give each CA a limited cert for some subset of TLDs (preferably one for each). And remove the wildcart cert nonsense, and just give domain holders a CA cert for their domain.

[edit: And by demand, I mean that SSL clients such as Chrome and Thunderbird and Outlook and Safari... should treat "unbounded" CA certs as invalid. It would require a major overhaul. Also note that there are lots of broken clients (all of them?) that ignore limitations so any security gain wouldn't be seen until all those were upgraded/phased out. It may indeed be more realistic/easier to move to a new/more secure system (ie: the "www" would be "secure" with a "secure DNS with records for certs", but IMAP would remain broken)]

This would "compartmentalize" the trust somewhat, meaning that compromises would be more limited.

It would also allow us to move to a setting where the default is mistrust, rather than trust: make it normal that both certs and (intermediate) CA certs need to be rotated, say every month or so.

Certainly not perfect - but I'm not sure I trust the DNS system with encryption keys much more than the current CAs. So I'm not sure that "securing" DNS will really help - sure you could argue that SSL "just" binds a cert to a domain name -- but that isn't really any meaningful level of trust either. The fact that DNS is insecure, and CAs can sign willy-nilly any domain is bad. I'm not convinced allowing eg. all Russian registrars of .com-domains to issue .com certs is that much of an improvement.

No, its not. This problem detected by a third-party due to a recent industry initiative (Certificate Transparency). Now Google has doled out appropriate punitive measures which will greatly reduce chances of this happening again.

The industry is moving forward and doing lots to improve.

Lets also not forget a hugely important point that there is no evidence of harm from Symantec's action. They were just embarrassingly stupid and irresponsible.

But this is the 4th or 5th similar announcement I recall, some of which have been malicious, some incompetent. Maybe CAs are getting better but 'trusted' is not the first word that comes to mind any more.

This is the first of those by a CA that is actually too big to fail.

I think the last too-big-to-fail CA that misissued certs in recent memory was Comodo, in March 2011, who had a reseller's account broken into (apparently by an Iranian state-sponsored attacker). And that was well before there were options like insisting on Certificate Transparency, and Comodo reacted well (they had an accurate audit trail and deployed changes that blocked the attacker when they retried two weeks later), and it didn't involve active incompetence on Comodo's part. Since then, there's also been CNNIC, India CCA, TURKTRUST, ANSSI, and DigiNotar. CNNIC and DigiNotar have both been removed from Chrome's root store, India CCA and ANSSI have been restricted to their country's TLDs, and TURKTRUST (which apparently reacted well) lost their EV powers.

(There were also a couple of misissued certs due to Microsoft Live allowing anyone to sign up for accounts like "hostmaster", but those are not considered the CA's fault.)

Is the system problematic? Yes. Does it have room for improvement? Tons. Is it broken? No, I dont think so.

I dont think the CA system is unique in having breaches, holes, or incompetent actors.

The CA system is unique is that one hole, breach or incompetent actor compromises the entire system.

It's also unique is that when an authority has a hole, breach or is an incompetent actor, it's very difficult to remove them from authority.

>It's also unique is that when an authority has a hole, breach or is an incompetent actor, it's very difficult to remove them from authority.

There is no proof of this. There are lots of systems in place to deal with mistakes and trust breaches. If it gets to the extent that a Root or CA needs to be removed from trust stores, then they are removed.

Just this year we saw two CAs lose their trust.

>Symantec performed another audit and, on October 12th, announced that they had found

>an additional 164 certificates over 76 domains and 2,458 certificates issued for

>domains that were never registered.

I don’t know much about how the CA system works, but “there’s something fishy going on with this CA” in conjunction with “starting with June 1st 2016” is not very reassuring.

Well the CA in question represents a large market share of both internet and non-internet certs. You can't just top trusting them, large parts of the internet would crash and burn.

And until that happens, why do we expect and significant portion of Symantec's customers to care? And unless they care, why would Symantec?

Apple are using a Symantec ssl cert right now:

"The identity of Apple Inc. at Cupertino, California US has been verified by Symantec Class 3 EV SSL CA - G3. Valid Certificate Transparency information was supplied by the server."

But their level of give-a-shit is clearly demonstrated as well:

"Your connection to www.apple.com is encrypted using an obsolete cipher suite.

The connection uses TLS 1.2."

You can revoke their certificates from your root trust stores yourself on most devices.

Scrolling through the two PDFs linked from the post, looks like we would have to stop trusting Symantec, Thawte, VeriSign, GeoTrust, and probably a few others. Is that right?

All the more reason why client-side encryption needs to become part of our daily interaction with software and cloud services.

You mean client-side authentication? And how would this have helped.

I would venture that your parent meant that we should use 'dumb' cloud services that just store encrypted data which are then retrieved and de-crypted on the client side.

Bingo.

Say you attempt to do this all in JavaScript; you've still got to deliver the page (the encryption code, really) to the user securely; otherwise, I can modify it s.t. when it gets a blob from the server and decrypts it on the client, that decrypted value is also sent off to a shady spot. You still need to get your app from you to your user securely, and how do you do that?

It's the core problem really: how do you distribute your public key? How do you make sure Joe user gets the right public key? Today, we have the CA infrastructure, which admittedly isn't great, but… what would you do differently? (And the big problem is that it needs to work for average Joe.)

The one thing you can do with such a system is to make it harder to compromise the code and get away with it. Any gossip system, public ledger, etc. (including "the blockchain", but you don't actually need something that power-hungry) can enforce that my copy of the JS is the same as everyone else's copy of the JS.

Right now it's easy to get in a network position between a single person and Gmail, without anyone else knowing, especially if you're a government, which is why a valid .google.com cert is such a valuable target. Getting in a position to compromise everyone's* copy of Gmail is much more involved, and if you pull it off, it's instantly visible to the entire world.

http://hyperboot.org/ solves some of these issues

Couldn't you have a browser plugin that would verify your js is being served up from the correct source?

Subresource integrity (sort of) solves this.

http://githubengineering.com/subresource-integrity/

To state the obvious (again) the third-party based trust system underlying TLS is broken. It places a massive amount of faith in a large crowd of human beings (the collective employee populations of all the CA's in the world) to behave with absolute rectitude and discipline for years and years without fail.

The sad part is that all of us, collectively, trust pretty much our entire financial lives and other matters requiring secrecy and authentication to this system everyday. It's mind-boggling how we came to be in this situation. How did the entire society, including very very smart security experts came to vouch for and blindly trust this system?

DNS certs would be better https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

This reminds me of https://www.agwa.name/blog/post/how_to_responsibly_misissue_...

This is terrible. This is sad. Is it any wonder so many people have no faith in Government, in the Financial system? How much of the system we take for granted is corrupt? I'm not intending to be negative, I know I am. But for Pete's sake. This sucks sucks sucks.

Reply on news.ycombinator.com