How not to run a CA • Hacker News Board

Re: How not to run a CA

#121

Post by cortesoft » Thu, Mar 01, 2018, 5:49 PM UTC

Karunamon wrote: post #114

rkangel wrote: post #75

Earlier quoted context omitted.

There is at least some merit to the argument that "Trustico Bad" => "CAs bad" => "HTTPS Bad". More than one CA has been shown to be extremely lacking in trustworthiness and that trust is important. I'm OK with the centralised model but there needs to be a bit more visibility of the CA process.

I'd settle for an end to the credentialism that ensures only the rich and powerful can enter the CA business. The actual technical chops and physical/operational requirements to become a CA are modest by the standards of the average HN reader, but the financial cost for the audit required to wind up in the browser trust stores is prohibitively high. ...That, and given the massive failures we've seen coming out of the…

Aren't the audits what allow us to find out about the failures, and revoke their ability to be a CA?

Re: How not to run a CA

#122

Post by azernik » Thu, Mar 01, 2018, 5:51 PM UTC

jnbiche wrote: post #87

devit wrote: post #78

Browsers need to remove all CAs except Let's Encrypt. CAs have proven again and again to be ridiculously insecure, and the problem is that there is no penalty for their mistakes. So just remove them all, after a warning period: Let's Encrypt is enough. Or if they want to stay in business and be trusted by browsers, then require them to put up at least $100k in cash in escrow for each certificate they sign, which is f…

> Browsers need to remove all CAs except Let's Encrypt. No. I love Let's Encrypt, but we can't put all our eggs in a single basket like that. Now, if we could somehow foster multiple non-profit organizations like Let's Encrypt, but run under the aegis of different boards and sponsors, I'd be 100% for this idea. It's very odd that companies for whom CAs business is quite literally a money printing operation can't be b…

This market failure is neither bizarre nor unexpected. The CAs are like ratings agencies in the financial crisis: they are in the business of selling to one party (the website) a credential that they offer to a third party (the browser). Their incentives are aligned to make them sell certificates as cheaply as possible, and they are of course willing to trade off as much security as possible for convenience/cost, as long as they don't go over the lines defined by internet governing bodies and browser vendors. And when they're pushing those boundaries, every once in a while they're going to make a mistake.

Re: How not to run a CA

#123

Post by blfr » Thu, Mar 01, 2018, 5:52 PM UTC

tialaramex wrote: post #88

blattimwind wrote: post #53

Earlier quoted context omitted.

Up until a few years ago there was a tag which embedded a x509 CSR generator into a regular HTML form. The private key was generated by the browser(1) and was completely inaccessible to the site or any JS running on it. That's the proper way to generate certificates in browsers, but it's been removed since and was never supported in IE. StartSSL used it, for example, but also allowed you to hand them a CSR of your ow…

You say "they of course ignored almost everything in the CSR apart from the public key" but it turns out they went a bit further than that, they also ignored the signature on the CSR. So you could put some other public key in there, add a bogus signature that wouldn't verify and they'd issue certificates for a key you never even controlled. The bad security implications for that scenario are a bit subtle, and situati…

Sure, they should have checked but I don't see the implication. If you take steps to prove ownership of a domain and then request a certificate for it with a key you do not control, that's on you.

Re: How not to run a CA

#124

Post by u801e » Thu, Mar 01, 2018, 5:52 PM UTC

dpark wrote: post #101

u801e wrote: post #81

Earlier quoted context omitted.

> I guarantee you a month later Google and Apple and Microsoft will become the de facto CAs Except that none of those companies bother verifying one's identity if you're not actually paying for their services. > and see if one of them vouches for their banking website. In that scenario, could I not just verify the bank's public key when I'm physically in one of their branch locations while opening an account? They co…

> Except that none of those companies bother verifying one's identity if you're not actually paying for their services. I'm sure in this scenario, those companies will be delighted to step fully into the role of CA including accepting money for identity vouching. > In that scenario, could I not just verify the bank's public key when I'm physically in one of their branch locations while opening an account? They could…

It probably could apply to some that I locally deal with. But you're correct in saying that it's not practical for companies that don't have local branches.

Re: How not to run a CA

#125

Post by makecheck » Thu, Mar 01, 2018, 5:54 PM UTC

This shows that you need a lot more than a fancy web site to convince you that a CA is professional.

It’s kind of crazy how little we know about these important institutions. Credit reporting agencies are another example of complete incompetence in a presumed-sensible organization.

Especially once money changes hands, there ought to be a lot more terms in the contract to specify good behavior. You need backup when you discover something is run by 6-year-olds.

Re: How not to run a CA

#126

Post by dredmorbius » Thu, Mar 01, 2018, 6:08 PM UTC

inetknght wrote: post #50

slim wrote: post #23

Earlier quoted context omitted.

Security depends on your threat model. HTTP is generally secure for publishing and has the added advantage of being cacheable by proxies. This blog is secure

> HTTP is generally secure This statement is wholly incorrect. HTTP is not generally secure. > for publishing When I publish something I do not intend for third parties to interfere with the delivery of what I publish. > and has the added advantage of being cacheable by proxies If you trust your proxy, you can still have cached data at your proxy. If you don't trust your proxy, then why are you proxying through it?

HTTP plus a trusted hash would provide an integrity measure of the content of a page, and enable hashing.

It would not prevent anyone from examining that content in flight, or altering it. It would allow any such alteration to be identified.

It is possible to offer various levels of assurance on unencrypted communications.

Mind: I'm describing a possible world, not the one most of us happen to live in. Unless, say, you're retrieving Debian package repositories over FTP or HTTP transport, and rely on the package signature rather than HTTPS for integrity.

See for example: https://unix.stackexchange.com/q/90227

Re: How not to run a CA

#127

Post by edaemon » Thu, Mar 01, 2018, 6:08 PM UTC

chedabob wrote: post #102

aiCeivi9 wrote: post #6

Earlier quoted context omitted.

"Trustico allows customers to generate a Certificate Signing Request and Private Key during the ordering process," the statement read. "These Private Keys are stored in cold storage, for the purpose of revocation." Maybe they decided preparing CSR is too hard for their clients :/

I don't understand why they'd need the Private Keys for revocation. Isn't one of the reasons to revoke because you've lost the private key?

You don't need the private keys for revocation, and you're right that compromise of the private key is one of the best reasons to revoke a cert.

I can't figure out why the Trustico CEO emailed the private keys to DigiCert. It doesn't make sense.

Re: How not to run a CA

#128

Post by dredmorbius » Thu, Mar 01, 2018, 6:09 PM UTC

sphix0r wrote: post #47

slim wrote: post #23

Earlier quoted context omitted.

Security depends on your threat model. HTTP is generally secure for publishing and has the added advantage of being cacheable by proxies. This blog is secure

TLS = encryption TLS = authentication TLS = tamper proof

Largely, yes, modulo CA integrity and APT attacks.

Re: How not to run a CA

#129

Post by Karunamon » Thu, Mar 01, 2018, 6:10 PM UTC

cortesoft wrote: post #121

Karunamon wrote: post #114

Earlier quoted context omitted.

I'd settle for an end to the credentialism that ensures only the rich and powerful can enter the CA business. The actual technical chops and physical/operational requirements to become a CA are modest by the standards of the average HN reader, but the financial cost for the audit required to wind up in the browser trust stores is prohibitively high. ...That, and given the massive failures we've seen coming out of the…

Aren't the audits what allow us to find out about the failures, and revoke their ability to be a CA?

How many of the most recent failures have come to light as a result of a failed audit, and how many were due to a post-audit, outrage-generating violation of basic best practice and common sense?

Re: How not to run a CA

#130

Post by devit » Thu, Mar 01, 2018, 6:18 PM UTC

jnbiche wrote: post #87

devit wrote: post #78

Browsers need to remove all CAs except Let's Encrypt. CAs have proven again and again to be ridiculously insecure, and the problem is that there is no penalty for their mistakes. So just remove them all, after a warning period: Let's Encrypt is enough. Or if they want to stay in business and be trusted by browsers, then require them to put up at least $100k in cash in escrow for each certificate they sign, which is f…

> Browsers need to remove all CAs except Let's Encrypt. No. I love Let's Encrypt, but we can't put all our eggs in a single basket like that. Now, if we could somehow foster multiple non-profit organizations like Let's Encrypt, but run under the aegis of different boards and sponsors, I'd be 100% for this idea. It's very odd that companies for whom CAs business is quite literally a money printing operation can't be b…

Security requires that ALL CAs be secure, since any compromised CA can compromise all websites (barring fragile schemes like pinning or certificate transparency checks), so the less CAs there are, the more secure the system is.

It's like a building that needs secure doors: it's better to invest in a single, massive, bulletproof, guarded door rather than inviting anyone who meets some standards to add a door to the building, since what matters is the weakest door.