Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How not to run a CA

blog.koehntopp.info

Post reply on HN
Print view View original

221–230 of 255 posts

Re: How not to run a CA

#221

Post by duskwuff »

originalsimba wrote: post #206
prdonahue wrote: post #195

Earlier quoted context omitted.

We use several CAs to issue—Comodo, DigiCert, GlobalSign—and will be adding Let's Encrypt once they support i) SHA-2/ECDSA signatures and ii) wildcards. Having multiple issuers is important for us as each CA, at some point in time, has operational issues. Additionally, as you've seen with Symantec, browsers take action to distrust certain issuers/roots. When either of these scenarios happens, our customers don't care…

If Cloudflare wants wildcards it's so they can have multiple customers, each using completely different origin servers, on a single certificate, which makes those certificates worthless, and I hope Let's Encrypt blacklists Cloudflare from using them when wildcards are launched.

What you're describing is a multi-domain certificate, not a wildcard. Let's Encrypt already supports multi-domain certificates.

Re: How not to run a CA

#222

Post by jgrahamc »

djsumdog wrote: post #201
sneak wrote: post #107

Earlier quoted context omitted.

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?

Continued usage of Cloudflare baffles me. They spewed tons of private data, across customer boundaries, on random web responses, which made its way into search engine cache around the world. They conducted an act of Internet censorship: https://fightthefuture.org/article/the-new-era-of-corporate-... ..and the CTO who made that decision later backed down and said he wouldn't make that same decision again. O_o I really…

^CTO^CEO

Re: How not to run a CA

#223

Post by jgrahamc »

originalsimba wrote: post #206
prdonahue wrote: post #195

Earlier quoted context omitted.

We use several CAs to issue—Comodo, DigiCert, GlobalSign—and will be adding Let's Encrypt once they support i) SHA-2/ECDSA signatures and ii) wildcards. Having multiple issuers is important for us as each CA, at some point in time, has operational issues. Additionally, as you've seen with Symantec, browsers take action to distrust certain issuers/roots. When either of these scenarios happens, our customers don't care…

If Cloudflare wants wildcards it's so they can have multiple customers, each using completely different origin servers, on a single certificate, which makes those certificates worthless, and I hope Let's Encrypt blacklists Cloudflare from using them when wildcards are launched.

Huh? We want wildcards so that if you sign up example.com we can give you a certificate for example.com and *.example.com. This has nothing to do with SANs.

Re: How not to run a CA

#224

Post by waterbomb »

originalsimba wrote: post #206
prdonahue wrote: post #195

Earlier quoted context omitted.

We use several CAs to issue—Comodo, DigiCert, GlobalSign—and will be adding Let's Encrypt once they support i) SHA-2/ECDSA signatures and ii) wildcards. Having multiple issuers is important for us as each CA, at some point in time, has operational issues. Additionally, as you've seen with Symantec, browsers take action to distrust certain issuers/roots. When either of these scenarios happens, our customers don't care…

If Cloudflare wants wildcards it's so they can have multiple customers, each using completely different origin servers, on a single certificate, which makes those certificates worthless, and I hope Let's Encrypt blacklists Cloudflare from using them when wildcards are launched.

They are not worthless. They still protect the data from the user to the Cloudflare servers, and only Cloudflare keeps the private keys for them. Not sure how this would be made any safer by each domain having a separate certificate.

The main issue is that Cloudflare needs to have plain-text traffic to examine, which cannot be done with End-to-End encryption from the client to the origin server, in which case you would definitely need a separate certificate for each domain.

Re: How not to run a CA

#225

Post by zaarn »

0x0 wrote: post #172
Xylakant wrote: post #170

Earlier quoted context omitted.

No. The CSR is tied to the key and the resulting certificate as well. Verifying that the CSR belongs to the key would be he CAs job, not the servers. If the server was rooted, an attacker could probably just use it to create an arbitrary new certificate - but revoking the legitimate cert won’t fix that.

1. User validates domain and submits csr 2. Rootkit swaps out csr with one of its own whose private key is under its control and submits upstream to the CA 3. CA signs a cert because the domain was validated 4. Rootkit receives valid cert for its own private key 5. Rootkit presents a bogus error to enduser 6. Enduser tries again and rootkit lets it through End-result: there are now two certs and private keys for the…

1. Rootkit issues cert and sends to hacker

I find this plan to be much much easier.

Re: How not to run a CA

#226

Post by zaarn »

greenhouse_gas wrote: post #85
zaarn wrote: post #62

Earlier quoted context omitted.

There is levels of trust. While I maybe trust someone to be a real person after I've met them in real life and ate their spaghetti to give me back the 10$ they borrowed, I wouldn't trust them to verify the identity of the IRS for me. The current solution is that we have some third parties which follow strict rules defined by themselves and browser vendors. Everyone involved has a very good incentive to remain trustwo…

>They're switching to TOFU instead, the first time you see a key it's trustworthy, similar to SSH. Which is horrible unless your first connection to a server is trustworthy or you have an out-of-band way to verify keys (which is why it works in SSH, and can't work on the web).

Exactly. SSH Connections are usually towards servers you have setup so verifying the keys is easy. Even then there is little concern since most of it happens in the local area network anyway.

For PGP/GPG I feel like that TOFU is what most people are doing anyways, this change will only formalize the 0.90-quantile behaviour.

Re: How not to run a CA

#227

Post by technion »

benmmurphy wrote: post #213
flamingcow wrote: post #202

Earlier quoted context omitted.

Does it really? Even if the code author hadn't learned to escape/sanitize close to use so it's visible (or to avoid cases where you need to escape/sanitize entirely, like using something that bypasses the shell and takes array arguments), let's look at the manpages. PHP's system() manpage: http://php.net/manual/en/function.system.php [red box] Warning When allowing user-supplied data to be passed to this function, us…

at this point i think the problem with system() should be blamed on the language and not the people using the language. how many legitimate uses of system() functiona call are there. a primitive that does fork() execv() on an array is a much better alternative. yeah, it doesn't 100% fix problems you might have issues with - style flags but you are in a much better situation. like if your users want to do system() may…

Whilst I do wish I could cleanse a web application of actually supporting system(), we have system() in Perl, Ruby, Python, and modules for Node. I've seen people bagging PHP and that really isn't fair.

Shower thought: Allow me to globally disable system() in for language x. Aside from the obvious case of just banning these insane system calls, you're protected against surprise vectors in parsers.

Edit: You would presumably mitigate pipe open vulnerabilities too

Re: How not to run a CA

#228

Post by cup-of-tea »

zaarn wrote: post #226
greenhouse_gas wrote: post #85

Earlier quoted context omitted.

>They're switching to TOFU instead, the first time you see a key it's trustworthy, similar to SSH. Which is horrible unless your first connection to a server is trustworthy or you have an out-of-band way to verify keys (which is why it works in SSH, and can't work on the web).

Exactly. SSH Connections are usually towards servers you have setup so verifying the keys is easy. Even then there is little concern since most of it happens in the local area network anyway. For PGP/GPG I feel like that TOFU is what most people are doing anyways, this change will only formalize the 0.90-quantile behaviour.

> For PGP/GPG I feel like that TOFU is what most people are doing anyways, this change will only formalize the 0.90-quantile behaviour.

Yes, probably. Key signing parties used to be a thing. I was able to find one that happened in London in 2014 (no idea how many keys were signed, though). Unfortunately people are not aware of the concept of trust and especially of the fact they delegate trust to these third party CAs. It's just not a proper way to do security.

The TOFU model is the best thing if you actually verify the keys out-of-band. Web of trust is the best way I'm aware of to enable in-band verification. I don't claim that it will actually work in practice. But that's fine. All it means is you can't actually do in-band verification in practice. I think most people here are beginning with the assumption that in-band verification is possible and then criticising WOT for its practical shortcomings which is ridiculous.

Re: How not to run a CA

#229

Post by 0x0 »

zaarn wrote: post #225
0x0 wrote: post #172

Earlier quoted context omitted.

1. User validates domain and submits csr 2. Rootkit swaps out csr with one of its own whose private key is under its control and submits upstream to the CA 3. CA signs a cert because the domain was validated 4. Rootkit receives valid cert for its own private key 5. Rootkit presents a bogus error to enduser 6. Enduser tries again and rootkit lets it through End-result: there are now two certs and private keys for the…

1. Rootkit issues cert and sends to hacker I find this plan to be much much easier.

Presumably, even if you had root on the reseller website, you would need to wait for the domain owner to actually perform a domain validation before the actual CA's system would deliver any certificates?

Re: How not to run a CA

#230

Post by zaarn »

0x0 wrote: post #229
zaarn wrote: post #225

Earlier quoted context omitted.

1. Rootkit issues cert and sends to hacker I find this plan to be much much easier.

Presumably, even if you had root on the reseller website, you would need to wait for the domain owner to actually perform a domain validation before the actual CA's system would deliver any certificates?

Considering the security on that website, probably not.

Even if you did, I would argue that if you have root access to the validation form, getting a certificate signed is not going to be exponentially harder either.

Waiting for a potential target to sign a cert using that specific reseller is just borderline useless.

An attacker of a CA will be interested in either their CA private key (or intermediary) or the ability to get arbitrary certs signed.

Random targets on the internet are useless since it's unlikely they can MitM them.

Post reply on HN