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

231–240 of 255 posts

Re: How not to run a CA

#231

Post by eequah9L »

technion wrote: post #227
benmmurphy wrote: post #213

Earlier quoted context omitted.

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

I suspect that these languages just end up deferring to the system() library function in libc. LD_PRELOAD or other linker trick would then let you override it with a do-nothing or complain-loudly replacement.

Re: How not to run a CA

#232

Post by pas »

makecheck wrote: post #125

This shows that you need a lot more than a fancy web site to convince you that a CA is professional. It’s kind of crazy how little we know about these important institutions. Credit reporting agencies are another example of complete incompetence in a presumed-sensible organization. Especially once money changes hands, there ought to be a lot more terms in the contract to specify good behavior. You need backup when yo…

This was a "reseller", and they don't have to be audited, and the browser CA inclusion policy probably doesn't mandate anything from CAs regarding their resellers. Well, it should.

Re: How not to run a CA

#233

Post by HelloNurse »

jis wrote: post #186
recursive wrote: post #97

Earlier quoted context omitted.

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…

On the other hand, a customer who doesn't realize that their private key should never leave their premises has no business asking for a certificate. It's like not selling guns to children.

Re: How not to run a CA

#234

Post by MertsA »

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.

In fairness, all of those private keys were already compromised from the start. I have no clue why the CEO decided to take such harmful action to his own company, but one way or another all of those certificates needed to be reissued.

Re: How not to run a CA

#235

Post by tetha »

technion wrote: post #227
benmmurphy wrote: post #213

Earlier quoted context omitted.

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

You can do so with SELinux btw. You can remove the right for a program to run the exec syscall.

It's just sad that there is no really good tutorial how to write your own SELinux modules for your own applications. It's easier than it seems and allows some really powerful security measures.

Re: How not to run a CA

#236

Post by Ajedi32 »

johnhenry wrote: post #193

I'm wondering if anyone could explain what the "right" thing for Trustico to do?

They should not have offered a web form for generating private keys, and instead should have educated their customers on how to generate their private keys and CSRs on their own servers.

If they had done that they wouldn't have had access to any private keys in the first place, so all their subsequent mistakes in mishandling those keys would have been impossible to make.

As for the whole "arbitrary Remote Code Execution as root" on their web server, that's got a pretty obvious solution: sanitize your data inputs, and don't run your web application server as root.

Re: How not to run a CA

#237

Post by u801e »

HelloNurse wrote: post #233
jis wrote: post #186

Earlier quoted context omitted.

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…

On the other hand, a customer who doesn't realize that their private key should never leave their premises has no business asking for a certificate. It's like not selling guns to children.

While that may be true, that doesn't mean the rest of us shouldn't have the option of using certificate based authentication.

Re: How not to run a CA

#238

Post by inetknght »

kerkeslager wrote: post #217
inetknght wrote: post #160

Earlier quoted context omitted.

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.

You can't have encryption without authentication, because a man in the middle can snoop your connection. You can have authentication without encryption. This is what PGP signed messages are. I'll admit it's weird to call a cryptographic signature a "trusted hash", which makes it seem like the author of the post you're responding to doesn't know what they're talking about. But it's totally possible to to have trust wi…

> You can have authentication without encryption. This is what PGP signed messages are.

Yes, but you must install the authorization certificate using a secure method.

Honestly I think far too many CAs are "trusted" by default, especially for executing things (such as javascript) on my computer.

Re: How not to run a CA

#239

Post by tialaramex »

blattimwind wrote: post #162
tialaramex wrote: post #143

Earlier quoted context omitted.

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

Hmm. I think I agree with you that it isn't practical in HTTPS. I can see clearly why you can't do anything like this in TLS 1.3 because it has this nice simple ordering - the client and server do DH key agreement - we now both have encryption but no certainty of who we're talking to - then the server sends a certificate and uses the key from that certificate to sign their DH transcript, the client optionally also sends a certificate, they too use the key from that certificate to sign the transcript. Since I don't know Alice's Private Key I cannot sign transcripts while presenting the (Bob,A) certificate, and if I let Alice do the key exchange so that she'll sign, I'm cut out of the loop entirely. That's easy to follow.

But in TLS 1.2 and earlier it's murkier to me because there are cases with and without DH, and what gets signed, by who, and when varies. I think you're right, but I started doodling the possible cases out and I filled two A4 pages before I gave up. Certainly even if you're right as to how the protocol is designed it will not astonish me if somebody implements it wrong and doesn't check a signature somewhere given the many cases.

Re: How not to run a CA

#240

Post by __david__ »

technion wrote: post #227
benmmurphy wrote: post #213

Earlier quoted context omitted.

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

All of those languages have an option to pass in arguments as an array and bypass the shell completely. PHP does not. It's much safer with no shell (though not perfect).
Post reply on HN