On Wed, 20 Nov 2002 19:58:50 -0700, Bear Giles wrote:
>David Schwartz wrote:
>>>On Wed, 20 Nov 2002 11:29:26 +0100 (MET), Andreas Jusek wrote:
>>>>I am developing an SSL-secured client/server application. In one special
>>>>case, the client machine isn't trusted to be secure. Therefore I can not
>>>>put a CA's certificate into the filesystem, because otherwise an attacker
>>>>could exchange it and redirect the next connection to the server to his
>>>>own
>>>>machine being certified by the fakeed CA's cert.
>>We don't know what the OP's actual problem was, but odds are the solution
>>has little to do with embedding a private key. Though this might solve the
>>problem, it's not likely to be optimal.
>That's the original question quoted.
Right, but the answer depends upon *who* you are trying to stop from
replacing the key.
>As I read it, he's trying to
>prevent the CA cert from being replaced with a bogus one, allowing
>authentication of an impersonator.
Right, but here's the problem. The authentication is being done by the
client, and the cert is held by the client. If he's trying to prevent an
attacker with access to the client from changing the cert, what stops the
attacker from disabling the check alltogether? It would take access to
precisely the same thing.
If you can protect the executable, you can protect the key by the same
mechanism. If, as the OP suggests, you can't trust a key file, then you can't
trust the executable file either.
>I don't know where the private key came from, unless it's a distortion
>of my comment that you can embedded anything, including encrypted
>private keys, if you encode the cert as a string. Or as Christian
>pointed out, you can create an object file directly with ld(1).
How does this help if you can't trust files stored on the client? What do
you do with the file that contains the embedded key?
>N.B., I never said embedding private keys was a Good Thing. I only use
>this approach to embed fallback values that allow me make certain
>assumptions in my code. E.g., I'll always have DSAparams available -
>ideally user-defined ones, but embedded ones if necessary.
No, embedding private keys is a perfectly good thing. It's useful for many
things, including protecting clients against malicious servers or impostor
servers. It just won't work to protect the client from itself. There are
other techniques to do that.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
