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

191–200 of 255 posts

Re: How not to run a CA

#191

Post by nailer »

dcuthbertson wrote: post #134
nailer wrote: post #60

> TL;DR: Forget your EV or other certs. Just run “Let’s Encrypt”. The author has a fundamental misunderstanding of the situation [1]. Trustico's awful decisions regarding a) storing customers private keys and b) improperly handling key material Have no bearing whatsoever on EV certs, which verify the legal entities that run websites. This is like saying Trustico is bad, therefore HTTPS is bad. [1] Assuming this is wh…

So is a fair summary, "In a weak attempt to force Digicert to revoke 23,000 certs, Trustico proved they had the private keys for those certs. In the process, Trustico also proved they are completely untrustable as a CA."?

Yes, with the addition that Trustico also don't know how to transmit key material as well. Basically DigiCert's summary nails it.

Re: How not to run a CA

#192

Post by fgonzag »

majewsky wrote: post #72
Ajedi32 wrote: post #57

Earlier quoted context omitted.

Why would they not try to transition their customers to new certs _before_ getting all the old certs revoked though? Seems like suddenly revoking 23k of their customer's certs with only 24 hours notice is just shooting themselves in the foot.

We're using the Symantec/Digicert API for getting certs at work. I'm not directly involved in that, but I think when you want to issue a new cert you have to revoke the old one first. The API will just return an error if there is an existing cert for the same domain name. I recall vividly that when we moved from manually-issued certs (using their website) to automatic issuing (using their API), we had to revoke all c…

I use digicert and I can get as many certificates as I want with my wildcard cert. In fact I run different certificates in different contexts.

Re: How not to run a CA

#194

Post by TheDong »

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?

What they actually had was probably more like:

    system('openssl req -config /prod/prod-config.cnf -subj "/CN={$DOMAIN}" ....'
And whoever wrote that function assumed someone else had sanitized DOMAIN.

It looks like a lot more understandable of a mistake when framed like that.

Re: How not to run a CA

#195

Post by prdonahue »

Bombthecat wrote: post #119
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?

The question is: why does cloadflrare even use them? There are like ten thousand other options...

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 it's the third-party that's down—they expect fast and reliable issuance from us (Cloudflare).

Re: How not to run a CA

#196

Post by techmonster »

0XAFFE wrote: post #148
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 would pay for an acme endpoint that is not rate limited.

You don't have to pay; you just have to ask. :-)

https://letsencrypt.org/docs/rate-limits/#overrides

Re: How not to run a CA

#198

Post by diamondo25 »

inetknght wrote: post #160
dredmorbius wrote: post #126

Earlier quoted context omitted.

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 cannot have a "trusted hash" if you cannot trust the delivery mechanism (unencrypted and unauthenticated TCP). The content of the delivered payload (your blog and your "trusted hash") can be altered by anyone in transit. When you take unencrypted and unauthenticated TCP and upgrade to encrypted and authenticated TLS, only then can you begin to have trust.

Except when a party also has the certificate information and private key and does a man in the middle attack without you knowing, because of resigning the data with the exact same key :)

Re: How not to run a CA

#199

Post by u801e »

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.

Could a company offer both options? That is, a customer could choose whether to use a client certificate or SMS message/email based 2FA.

Re: How not to run a CA

#200

Post by pixl97 »

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…

Certificate transparency logs would out that pretty quickly.
Post reply on HN