How not to run a CA • Hacker News Board

Re: How not to run a CA

#101

Post by dpark » Thu, Mar 01, 2018, 5:14 PM UTC

u801e wrote: post #81

dpark wrote: post #76

Earlier quoted context omitted.

Yeah, web of trust gives me the option to manually decide, every time, if the chain(s) of trust looks "good enough" for me to trust the other party. There are two problems with this: 1. This is a ton of work and a lot of guesswork even for educated individuals. I end up looking at either explicit chains of trust (I trust Bob and he trusts Alice and she says that this is definitely my bank's website) or some random va…

> 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 also verify my public key at the same time. That would allow for a direct line of trust. The same could apply to any company one deals with.

No. The same couldn't apply to any company. My primary bank is online only. And how many times have you actually walked into an Amazon office? Or Paypal? Are people in Ohio supposed to fly to San Jose to get Paypal's public key when they create an account? Or are we going to wait for the post office to deliver a physical copy of Paypal's public key (and we'll just trust that whole transaction couldn't be compromised). Physical key exchange is simply not practical in most cases.

Re: How not to run a CA

#102

Post by chedabob » Thu, Mar 01, 2018, 5:15 PM UTC

aiCeivi9 wrote: post #6

firloop wrote: post #2

The thing that isn’t clear to me is how Trustico even had the private keys to begin with. It’s been a while since I’ve purchased a SSL certificate, but I remember generating the private key locally and providing a certificate signing request, which isn’t the private key. What am I misunderstanding here?

"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?

Re: How not to run a CA

#103

Post by tialaramex » Thu, Mar 01, 2018, 5:16 PM UTC

warent wrote: post #71

Ajedi32 wrote: post #64

Earlier quoted context omitted.

FWIW, Trustico isn't a CA. They're a certificate reseller; all certificate validation is handled by a different company. If Trustico hadn't been generating their customers private keys for them (or if their customers had refused to let them do things that way) they wouldn't have been able to screw things up this badly.

Got it, that kind of makes sense. The concept of certificate reseller doesn't make a whole lot of sense to me but thank you for making the distinction

Mostly they exist because of price discrimination.

Rich Uncle Bob hears he needs an "SSL Certificate" he's heard of "Thawte" brand SSL, he goes to the brand website and clicks "Buy $69.99 per year".

His savvy friend Tight Mike needs one too, he shops around, finds a reseller called "Discount SSL" that offers an Thawte certificate for $18.99

What's the difference? Nothing except that Tight Mike was looking for a cheaper price, and if "Discount SSL" didn't sell it to him for $18.99 he might have eventually kept looking enough to find that somewhere else has a GoDaddy cert for $12.99 or whatever. Bob didn't care, he just paid whatever they asked, so wring the maximum possible out of him.

In theory there's also some more traditional "sales and service" type role, where they educate customers, help manage local experience e.g. maybe the Reseller is in Egypt and your English isn't so good - and that sort of thing. But a LOT of the business is straight price discrimination, trying to ensure as much of the customer's money goes to you as possible without them switching to a competitor with lower prices.

Re: How not to run a CA

#104

Post by greenhouse_gas » Thu, Mar 01, 2018, 5:16 PM UTC

u801e wrote: post #81

dpark wrote: post #76

Earlier quoted context omitted.

Yeah, web of trust gives me the option to manually decide, every time, if the chain(s) of trust looks "good enough" for me to trust the other party. There are two problems with this: 1. This is a ton of work and a lot of guesswork even for educated individuals. I end up looking at either explicit chains of trust (I trust Bob and he trusts Alice and she says that this is definitely my bank's website) or some random va…

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

>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 also verify my public key at the same time. That would allow for a direct line of trust. The same could apply to any company one deals with.

You could? Would your grandmother? Would you fly to Mountain View to get Google's? And then turn around and fly to Washington DC to get the IRS's? And then turn around and fly to who knows where to get HN's? And then tell them to keep customer staff ready to assist you to install their public keys?

And what about personal blogs that don't want to be MITM?

Re: How not to run a CA

#105

Post by sphix0r » Thu, Mar 01, 2018, 5:17 PM UTC

nemoniac wrote: post #73

sphix0r wrote: post #10

Ironically his blog isn't available on https. Would be time that browers mark http sites' address bar as "Not secure" in orange. It's either secure or it isn't. Fun fact; Europe's ePrivacy law is coming next year which enforces all communication to be secure.

Europe's GDPR data law contains no such stipulation.

I'm referring to the communication (ePrivacy) not data / consent (GDPR).

Re: How not to run a CA

#106

Post by snuxoll » Thu, Mar 01, 2018, 5:20 PM UTC

discreditable wrote: post #82

peterwwillis wrote: post #56

Earlier quoted context omitted.

Correction : that you can control the IP space advertised to Let's Encrypt. A BGP exploit would result in getting valid certs for someone else's domain/host. It's almost trivial to exploit BGP, which is why PKI is so important... so it should actually be incredibly difficult to get a cert.

If someone is hijacking BGP to MITM the world, how are the old methods any better?

If you could hijack BGP you could just as easily inject routes to intercept DNS requests as well.

Re: How not to run a CA

#107

Post by sneak » Thu, Mar 01, 2018, 5:21 PM UTC

originalsimba wrote: post #96

"Bad Actors" in the tech field tend to flock together. Comodo has been at the center of several really ugly stories, this one being the latest. The CEO of Comodo attempted to sue Lets Encrypt before they launched, in order to kill the project because of the threat it represented to their business model. after 24 hours of backlash from the internet public he backed down and said it was all a misunderstanding. Of cours…

Your argument for guilt by association is not compelling. Cloudflare is their customer. I am Cloudflare’s customer. Does that make me a bad actor too?

Re: How not to run a CA

#108

Post by blattimwind » Thu, Mar 01, 2018, 5:21 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…

Actually I've never seen a solid argument for why that's a problem. A similar issue exists in PGP, but again it's unclear what the actual problem is. Some (non-x509) PKIs can't do this anyway.

Re: How not to run a CA

#109

Post by kerkeslager » Thu, Mar 01, 2018, 5:22 PM UTC

firloop wrote: post #2

The thing that isn’t clear to me is how Trustico even had the private keys to begin with. It’s been a while since I’ve purchased a SSL certificate, but I remember generating the private key locally and providing a certificate signing request, which isn’t the private key. What am I misunderstanding here?

As mentioned elsewhere in the thread, Trustico has a tool for generating keypairs. On their server. Which is dumb for exactly this reason.

Re: How not to run a CA

#110

Post by jakewins » Thu, Mar 01, 2018, 5:25 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…

> A bizarre and unexpected failure of the market.

The consumers are, partially, buying a product they can't see: The security operations of the vendor.

Given the consumer has imperfect information, it is exceptionally profitable for a supplier to just not invest in security. The downside being the risk of compromise.

A market set up this way entirely predicts low-cost suppliers. With no way for consumers to introspect security routines, two vendors will appear to simply differ in price. The outcome is rather obvious.