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

161–170 of 255 posts

Re: How not to run a CA

#161

Post by slrz »

tialaramex wrote: post #143
blattimwind wrote: post #108

Earlier quoted context omitted.

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.

Two people have asked essentially the same thing here, I'll answer this one because it was at the top. I am going to deliberately use a far-fetched scenario rather than invoke specific technologies, because there is no benefit to learning more specific here than "Nope, a competent CA must never allow this to happen". Alice has public key A, and Bob has public key B, and everybody trusts Charlie the Certificate Agency…

Ah, ok. In your scenario, the assumption appears to be that by issuing a (Bob, A) certificate, Charlie asserts that key A belongs to Bob.

For some reason, I never thought of DV certificates that way. I always took (Bob, A) to mean "I checked with the real Bob and he says it's fine to use key A in his name".

The former is, of course, the more useful guarantee.

Re: How not to run a CA

#162

Post by blattimwind »

tialaramex wrote: post #143
blattimwind wrote: post #108

Earlier quoted context omitted.

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.

Two people have asked essentially the same thing here, I'll answer this one because it was at the top. I am going to deliberately use a far-fetched scenario rather than invoke specific technologies, because there is no benefit to learning more specific here than "Nope, a competent CA must never allow this to happen". Alice has public key A, and Bob has public key B, and everybody trusts Charlie the Certificate Agency…

I'm aware of this[1], and with what you said out front in mind - it doesn't apply to either HTTPS or PGP. (I'm pretty sure you can build systems affected by this with X509, though).

[1] I don't want to take away from your good post, it's a good and well explained scenario to illustrate the issue. Personally I found Dominic Tarr's paper on AKEs-as-capabilities quite illuminating when I read it, and the analysis applies to your scenario as well. (The scenario is also a neat demonstration of a bunch of other issues, too)

Re: How not to run a CA

#164

Post by giobox »

walrus01 wrote: post #144

This is such a clusterfuck I don't even know where to begin. I am very happy that "pay money" for DV SSL certs is going the way of the dinosaur, with Let's Encrypt. The only SSL cert you should ever pay money for is $90/year for an EV SSL cert for an ecommerce/product purchasing website where people are entering credit card details. The big friendly green bar GUI element, for non-technical users, is worth it.

> I am very happy that "pay money" for DV SSL certs is going the way of the dinosaur, with Let's Encrypt.

> The only SSL cert you should ever pay money for...

You can still "pay" Lets Encrypt, my understanding is that as a non-profit they rely primarily on sponsorship and donations. If you are using them in production for a product making money one could at least consider throwing them a donation. If no one contributes we don't get to have nice things like LetsEncrypt!

Re: How not to run a CA

#165

Post by blattimwind »

tetha wrote: post #135
mkhalil wrote: post #61

In related news, Trustico's site is down apparently due to users being able to run commands as root on their webserver. I wonder if this was used to extract some private keys? https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/Manawyrm/status/969230542578348033

I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?

"As a security company."

Well, their CEO's linked-in profile doesn't really sound like a security company.

> Email Marketing Digital Marketing Google Analytics Google Webmaster Tools Market Analysis Marketing PPC SEM SEO Sales Security Social Media Marketing Web Analytics Affiliate Marketing Google Adwords Management E-commerce Lead Generation Online Marketing Online Advertising SaaS Marketing Strategy Strategic Partnerships Cloud Computing New Business Development Business Strategy Start-ups Web Development CRM Social Media Product Marketing Solution Selling Strategy Channel Partners Channel Sales Business Alliances Business Development Leadership Social Networking Network Security Hardware Product Management B2B Professional Services GTM Partner Program Development Internet Security Google B2B Marketing Sales Operations

Re: How not to run a CA

#166

Post by tetha »

blattimwind wrote: post #165
tetha wrote: post #135

Earlier quoted context omitted.

I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?

"As a security company." Well, their CEO's linked-in profile doesn't really sound like a security company. > Email Marketing Digital Marketing Google Analytics Google Webmaster Tools Market Analysis Marketing PPC SEM SEO Sales Security Social Media Marketing Web Analytics Affiliate Marketing Google Adwords Management E-commerce Lead Generation Online Marketing Online Advertising SaaS Marketing Strategy Strategic Part…

If you sell certs, you're a company in a security-related context. I don't care who you are, I care if you do your job.

Saying that, that quote sounds way too long to not be BS.

Re: How not to run a CA

#167

Post by mead5432 »

tetha wrote: post #135
mkhalil wrote: post #61

In related news, Trustico's site is down apparently due to users being able to run commands as root on their webserver. I wonder if this was used to extract some private keys? https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/Manawyrm/status/969230542578348033

I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?

On the plus side, a notebook doesn't have connection to the internet...

Re: How not to run a CA

#168

Post by 0x0 »

cesarb wrote: post #156
0x0 wrote: post #154

Earlier quoted context omitted.

Should count as probable cause for revoking the remaining 27k certificates then, no? It's not unreasonable to think someone has been exploiting this for years, siphoning any private key passing through?

The remaining 27k certificates are probably the ones which were generated on and which never left the customer's premises. The only thing which could be siphoned in these cases is the CSR, which is harmless (it contains essentially the same info as the certificate, which is public).

If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be none the wiser (except for perhaps looking at CT logs)?

Re: How not to run a CA

#169

Post by hetspookjee »

tetha wrote: post #166
blattimwind wrote: post #165

Earlier quoted context omitted.

"As a security company." Well, their CEO's linked-in profile doesn't really sound like a security company. > Email Marketing Digital Marketing Google Analytics Google Webmaster Tools Market Analysis Marketing PPC SEM SEO Sales Security Social Media Marketing Web Analytics Affiliate Marketing Google Adwords Management E-commerce Lead Generation Online Marketing Online Advertising SaaS Marketing Strategy Strategic Part…

If you sell certs, you're a company in a security-related context. I don't care who you are, I care if you do your job. Saying that, that quote sounds way too long to not be BS.

The quote sounds like SEO.

Re: How not to run a CA

#170

Post by Xylakant »

0x0 wrote: post #168
cesarb wrote: post #156

Earlier quoted context omitted.

The remaining 27k certificates are probably the ones which were generated on and which never left the customer's premises. The only thing which could be siphoned in these cases is the CSR, which is harmless (it contains essentially the same info as the certificate, which is public).

If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be no…

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.
Post reply on HN