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

181–190 of 255 posts

Re: How not to run a CA

#181

Post by 0x0 »

Xylakant wrote: post #178
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…

Like I said: If you compromise the Trustico servers which are a reseller, you could trick the CA into believing that a CSR is valid for a domain. This would get you a certificate with a key under your control. But revoking the certificate with the key under the owners control won’t fix this. The illegitimate certificate would still be under the attackers control and remain valid.

Unless you revoke all the certs issued through that channel/reseller - the legitimates would be collateral damage but you'd also get rid of any illegitimate ones?

Re: How not to run a CA

#182

Post by williamscales »

taylorexpander wrote: post #176
mead5432 wrote: post #167

Earlier quoted context omitted.

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

In some languages (German for one) the common word for laptop is translated to notebook in English.

The term notebook computer is used in English as well, however its usage has declined significantly over time compared to the term laptop:

https://trends.google.com/trends/explore?date=all&q=laptop%2...

Re: How not to run a CA

#183

Post by hug »

williamscales wrote: post #182
taylorexpander wrote: post #176

Earlier quoted context omitted.

In some languages (German for one) the common word for laptop is translated to notebook in English.

The term notebook computer is used in English as well, however its usage has declined significantly over time compared to the term laptop: https://trends.google.com/trends/explore?date=all&q=laptop%2...

It is declining, but I highly suspect the MacBook will remain the MacBook, and not the MacTop.

Re: How not to run a CA

#184

Post by icedchai »

walrus01 wrote: post #149
snuxoll wrote: post #106

Earlier quoted context omitted.

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

This is why ISPs use tools like RPKI validation of received routes, and things like the ARIN, RADB and RIPE route-servers.

Almost nobody uses RPKI: https://rpki-monitor.antd.nist.gov/

Re: How not to run a CA

#185

Post by chopin »

jiggliemon wrote: post #55
dx034 wrote: post #26

Earlier quoted context omitted.

This probably happened because they allowed users to execute root commands on their server. Either they quickly shut down the site or someone else did it by shutting down some servers. > https://twitter.com/svblxyz/status/969220402768736258

Oh my. There must be some sort of hall of fame for security vulnerabilities. And this belongs in it. Perhaps they’re passing this command to a secured container? I shouldn’t make excuses for them, but passing root commands to the shell seems too far out there.

This seems more to warrant a business Darwin Award.

Re: How not to run a CA

#186

Post by jis »

recursive wrote: post #97
u801e wrote: post #77

Earlier quoted context omitted.

> Maybe they decided preparing CSR is too hard for their clients :/ It seems that a lot of businesses and people feel that making things "easier and more convenient" takes priority over best security practices. For example, we can't support client side TLS cert authentication (in addition to a username and password) because customers won't be able to generate the CSR or know how to import the certificate into their c…

And they're probably not wrong. In other words, I suspect that if there were two identical competing services, the convenient one would win. If one only supported client certs, and one only supported 2FA, I have a (unsupported) feeling that the client cert company would not survive long.

Yep. The problem is that most customers cannot judge the level of security offered by a company. So Company "A" says they are "secure," but has a cumbersome process to follow to get a certificate. Company "B" says they are "secure" and has a convenient process. Guess which one gets the business (all else being equal).

In reality Company "B" may well be much less secure then "A", but the customer has no way of knowing that or making a judgement on which company is more secure.

Re: How not to run a CA

#187

Post by shruubi »

> So the CEO of Trustico, Zane Lucas, mailed the private keys of 23000 Trustico customers to Digicert

How is it that these guys have managed to stay in business for this long?

Re: How not to run a CA

#188

Post by edaemon »

wcoenen wrote: post #180
edaemon wrote: post #127

Earlier quoted context omitted.

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.

The Trustico CEO intentionally compromised the private keys to force DigiCert to revoke the certificates. DigiCert wouldn't do this otherwise on his request; it's the actual owner of the certificate who needs to request revocation.

I meant I don't get why he would want to do that. Why insist that all of his customers' keys be revoked? Why intentionally compromise the keys to make that happen?

After reading more about it, though, I think it's less that it doesn't make sense and more that the person making these decisions is incompetent.

Re: How not to run a CA

#189

Post by Xylakant »

0x0 wrote: post #181
Xylakant wrote: post #178

Earlier quoted context omitted.

Like I said: If you compromise the Trustico servers which are a reseller, you could trick the CA into believing that a CSR is valid for a domain. This would get you a certificate with a key under your control. But revoking the certificate with the key under the owners control won’t fix this. The illegitimate certificate would still be under the attackers control and remain valid.

Unless you revoke all the certs issued through that channel/reseller - the legitimates would be collateral damage but you'd also get rid of any illegitimate ones?

If you compromised the reseller, would you have the reseller keep a list of illegitimate certificates that you issued via that channel?

Re: How not to run a CA

#190

Post by 0x0 »

Xylakant wrote: post #189
0x0 wrote: post #181

Earlier quoted context omitted.

Unless you revoke all the certs issued through that channel/reseller - the legitimates would be collateral damage but you'd also get rid of any illegitimate ones?

If you compromised the reseller, would you have the reseller keep a list of illegitimate certificates that you issued via that channel?

Surely the actual CA has a database of certificates it has issued and by which reseller?
Post reply on HN